RE: methods of reviewing documentation

[<Daniel_Hall -at- trendmicro -dot- com>]

To add to Dick's response:

Provide a _specific_ list of items to review in the email that accompanies the draft you send out. Remember that the SMEs have a lot of other things on their plates and you shouldn't be asking them to wade through a 300 page document to verify the two processes they are responsible for.

If at all possible, (it should be for a writer collecting info from SMEs) point the appropriate reviewer to the relevant content. For instance, if a draft of my document needs to be reviewed, I'll ask the "policy SME" to review the policy chapter and the "database SME" to review the sections where the UI touches the db. 

This has several benefits, not the least of which is that the SMEs know where to target their attention, and can review only the parts they have knowledge about. It helps prevent folks who are SMEs about one area making (incorrect) corrections to areas in which they... have less expertise. Ask me how I know that's a problem :-)

Targeting reviews is (IMO) key to getting feedback

Dan.

-----Original Message-----
From: bounce-techwr-l-129804 -at- lists -dot- raycomm -dot- com
[mailto:bounce-techwr-l-129804 -at- lists -dot- raycomm -dot- com]On Behalf Of Melissa
Clark
Sent: Wednesday, March 03, 2004 5:21 PM
To: TECHWR-L
Subject: methods of reviewing documentation



Hi,
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
articles). ;)

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. 

Thanks,
Melissa

_