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.
Jack Bonney wrote:
>
> we expected to find a widely used approach to managing the entire process
> in such a way as to integrate the work with the tools and the people who
> use them -- nothing appears to available in this regard.
>
> we believe that this lack of defined publishing process contributes to an
> inability to delivery results of a pre-determined cost and quality.
Don't be silly, Jack. And start using proper English, would you
please? After all, as a proponent of appropriate use of the language
involved with communication, you should be observing the same rules that
are applied to the rest of us - unless, of course, you can make a
compelling case for presenting professional communication in a manner
consistent with lack of knowledge of proper English.
Anyway - back to your point about managing the documentation process.
In a previous email to you, I described the seven-step process that
seems to underly most successful documentation projects, along with
explanations of why things don't always go as scheduled. From the
writers' point of view, there seems to be no way to adequately plan for
the continual "last minute changes" in the product being documented.
Those "last minute changes" (which admittedly sometimes occur well
before the last minute, but frequently manage to wreak havoc with even
the most permissive schedule) are the effect of product people changing
their minds about just what ought to be/not be in the product. Only
when the entire product development/release process is kept on schedule
can the doc team hope to keep their own part of things on schedule.
OK, so what about putting doc people farther up the project planning
ladder? Been there, done that, and most of us have a whole closetful of
the tee shirts. I have yet to see a fool-proof way of defining a
process and associated schedule that (a) realistically allows sufficient
time for product changes and the impact of those changes, and (b)
acknowledges the domino-like effect of changes late in the schedule on
the support activities like documentation, configuration, packaging,
marketing collateral, training, etc. Most of us who've been in this
business for a number of years have up-close and personal experience
with being the voice in the wilderness of product management.
Jack, you may categorize your observation as a lack of management, but
you're targeting your criticism at the wrong people. Pubs management
usually does as much as possible to keep documentation schedules on
target, and usually winds up in management meetings objecting to the
changes that negatively impact schedules and proper planning, but trying
to work things out anyway.
By the way - your message heading implies that you're taking a survey.
Where are the survey questions?
Elna Tymes
Los Trancos Systems
TECHWR-L (Technical Communication) List Information: To send a message
to 2500+ readers, e-mail to TECHWR-L -at- LISTSERV -dot- OKSTATE -dot- EDU -dot- Send commands
to LISTSERV -at- LISTSERV -dot- OKSTATE -dot- EDU (e.g. HELP or SIGNOFF TECHWR-L).
Search the archives at http://www.documentation.com/ or search and
browse the archives at http://listserv.okstate.edu/archives/techwr-l.html
