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.
Now, I ask you: Think of documentation projects that really did not turn-out
too well. Next, ask yourself, what were the major culprits. Were they a
lack of writing, editing, or grammar skills? Lack of knowledge of the
latest DTP technology?
Or was it that:
1.) No (or little) effective end-user task analysis was performed.
2.) Estimating was either done poorly or not at all. This includes firm due
date projects.
3.) While the grammar was good, there was no standard use of terminology:
one chapter called something an apple, another called it a banana, another
an orange.
4.) No flow-charts were created to plan the organization of the
documentation. I'm sorry folks, software systems, especially larger ones,are
notoriously non-linear - task lists just don't do the job!
From what I have been exposed to, and other TWs that I know personally, it
has always been the latter category.
Andrew Plato responds:
I can't say I have seen all the possible failure points for tech writing
projects, but if Tony gets to guess about what causes tech pubs failure then
so do I...
Tony Markatos responds:
I'm not guessing. The problems were VERY evident - and known by all
involved.
Tony Markatos
(tonymar -at- hotmail -dot- com)
______________________________________________________
Get Your Private, Free Email at http://www.hotmail.com
