Standard Doc Review Cycle-Online/Print Help

Ned Bedinger doc at edwordsmith.com
Tue Jul 4 17:26:34 MDT 2006


Gurpreet Singh wrote:
> Hi Friends,
>
> I have a few questions regarding the reviews of documents and I hope
> that industry peers might be able to provide me few answers/suggestion
> over this.
>
> Are there any industry defined specific review/test cycles that one
> can apply in testing or reviewing documents, for both online and print
> media? Are these different for print and online help?

Reviews are elemental--I can't think of a single project methodology 
that doesn't include documentation review cycles. 

Pick your key words carefully and try searching again, Gurpreet.  For 
example, googling for 'review cycle methodology' got a description of a 
review cycle under the heading Reviews, halfway down the page at :

http://www.dai-sho.com/pgsa2/pgsa03.html

I like dai-sho.com's formal steps for evaluating comments, updating the 
reviewed product to satisfy reviewers, and then putting the revised 
product back in front of the reviewers. 

My organization requires us to iterate similar formal steps as time 
allows, as long as *anything* changes in the reviewed documents. We use 
mature, seasoned reviewers to do this for us.  This iterative review 
requirement would cause undue friction with reviewers who are anything 
less than committed to the process.

A common problem comes with using reviewers who don't have time.  
Incredibly, they will sometimes sign off an unreviewed document.  Avoid 
this by starting reviews of document pieces instead of waiting for 
completed documents.  Assign the pieces to reviewers who know the 
material, AND MAKE SURE THEY HAVE TIME ALLOCATED FOR REVIEWING.

One further note: 

The review iteration requirement also tends to keep tech writers from 
going back to fiddle with the text after reviews.  We're the fiddliest 
people in technology today.  Therefore, it is a good practice to call 
"Freeze" on a document during reviews, if only to keep the tech writer 
focused on real work and not endlessly revising finished documents.  
Tech writers should make note of any late changes they want to make, and 
push them off until the next version is release. The same is true even 
for living documents.

Believe me now, or believe me later.

Ned Bedinger
doc at edwordsmith.com



More information about the TECHWR-L mailing list