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.
Subject:methods of reviewing documentation From:Melissa Clark <liss_clark -at- yahoo -dot- com> To:techwr-l -at- lists -dot- raycomm -dot- com Date:Wed, 3 Mar 2004 17:20:44 -0800 (PST)
I need some help with technical review METHODS.
At the company I work for, we currently don't have a
great system for conducting reviews of technical
documentation...we work primarily in both FrameMaker
and Mic Word and produce LOCKED PDFs for reviews. (On
occasion, some people have given them out to
customers, so we never know whether a "review" copy is
going to end up in the hands of customers or if it
will stay internal.) Reviewers then submit their
changes to us either via email or in hard copy with
marked up changes. We used to use an "approval"
document that all reviewers had to sign off on, but we
do not use that anymore. We also do not use the
reviewing tools in Acrobat because not all of our
reviewers have the full version of Reader.
One of the main problems we have with the reviews is
probably mostly due to management buy-in
problems--Sometimes NO ONE on the team responds OR
none of the reviewers respond within our given
timeframe....then all of a sudden the project is a
fire. But that's not what I'm emailing about here
(there's plenty of help on that topic in the TECHWR-L
Besides that potential problem...we also are not sure
if our METHOD of reviewing is the most successful. We
would like to know what method of reviewing
documentation other companies use and what is
successful. There must be better ways (or
improvements to our current process we can make) to be
conducting formal reviews of our documentation.
I already briefly checked the articles on TECHWR-L and
the archives. One person suggested a bug be opened
each time there was an error in documentation. We
don't currently do this nor do we have an avenue in
which to do this.
Please respond to me directly (as well as the listserv
if you want) at liss_clark -at- yahoo -dot- com -dot-
Thanks in advance to anyone who helps.
Do you Yahoo!?
Yahoo! Search - Find what you?re looking for faster http://search.yahoo.com