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.
On 6/12/00 12:28 PM, MacDonald, Stephen (Stephen -dot- MacDonald -at- Aspect -dot- com)
wrote:
>If you could track it back in the history of the doc set's development, lack
>of structure was probably the biggest contributor to the "other problems."
>
>Most documentation flaws I have encountered were directly due to poor, or
>more commonly, no specifications, market requirements, and software
>development process.
Sorry, I'm going to have to disagree with you here. Most documentation
flaws I've encountered were directly due to lack of the necessary
information.
On the "bad" projects where I've either worked or been called in to fix,
the writers were often woefully uninformed about the product. Worse yet,
they were uninterested in playing with the product, becoming users,
trying to set it up and make it work as intended, or anything you might
assume they'd need to do. Instead, they were more interested in having
information spoon-fed to them by functional specs, developers, and other
"expert" sources.
Perhaps a good structure or set of processes would have dictated that
they should first learn the product as much as they can before collecting
other info, but I doubt it. Certainly that has frequently been the
managers' response: the doc. sucks because we don't have enough processes
in place. I always pointed out that the doc sucked because it was wrong
and lacking useful information, but that point was usually lost.
As I said before, on any project, get the information and content right,
and then we can talk about having fun with processes.