TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
> ....many folks don't understand why it takes so long
> to get ...simple,
> clear documentation.......
>
> Let me quantify "many" -- 99.99%
>
> For complex systems, the level of analysis required
Sorry...gotta disagree.
I think that "many folks don't understand why..." is
not their fault. It is ours.
In the time that I've been a tech writer, it has
amazed me how poorly we communicate, to each other
(this list is a prime example) and to those that deal
with us.
To be honest...I've never had anyone tell me that they
don't understand why it took as long as it does to do
what we do. OTOH, I make it a priority to "educate"
those that may need it on the issues of why something
will take as long as I say it will.
The only time they cannot understand the time needed
is if they are basing their understandand on what they
know (or think they know). Spend the time to "learn
them" about what/why we do and the majority of the
misconception will go away. It has for me.
Example: I came to this contract and one of the
projects I was assigned to was to rewrite a help
application for V2 of an application...the V1 was done
by an outside company and the department thought they
were happy with it. My job was to replaced the old
screens with the new screens and redefine the meaning
of some of the functions. Project was thought to be a
2-3 week effort.
I'm now on it for 6 weeks, I'm 75% finished, and the
client is thrilled with the progress. Why? Within 10
days after I started, I met with the manager and told
him why I was rewriting the whole help file (768
topics) and what a sample of the pages would look
like.
He's been getting progress reports every two days and
as groups of topics are finished, he's getting
compiled versions of the program to proof the parts
that are ready.
He KNOWS what's going on, why it is, and what he's
getting "for his money".
We don't work in a vaccum, we cannot have our way all
the time, we don't have the luxury to produce
"perfect" work and we cannot ignore the impact we have
on those around us.
My constand question to the client is "Is this good
enough and fast enough?"
=====
John Posada, Merck Research Laboratories
Sr Technical Writer, WinHelp and html
(work) john_posada -at- merck -dot- com - 732-594-0873
(pers) jposada01 -at- yahoo -dot- com - 732-291-7811
"The art of creating software that is usable by individuals is a communication skill. It is not a programming skill."
--Bill Atkinson, creator of MacPaint and HyperCard
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
