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.
> One of the main problems we have with the reviews is
> 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
> Besides that potential problem...we also are not sure
> if our METHOD of reviewing is the most successful.
It is not unlikely that your method of reviewing is related to your lack of
response. Unfortunately, most of the advice given on this subject does tend
to treat the two issues as separate. Advice on how to get people to actually
do the reviews tends to focus on various methods of persuasion, when it
might better focus on process.
The trouble with document reviews is that there is fundamentally no good way
to do them. There are bad ways and there are worse ways, but none that
really do a good job of producing a thorough and timely review of the
information you have produced.
The problem is that a document review is what is called, in queuing theory,
a large batch transfer. A large amount of work (an entire document) arrives
at a single server (a reviewer) all at once. The server is overwhelmed and
service is poor, especially if the work arrives at a time when the server is
already busy with other requests. Because it is one large job, the work
cannot be distributed to other servers, and because it arrives all at once,
usually near the end of a project when every server is busy, it cannot be
No matter how you attempt to bribe, cajole, intimidate, or blackmail the
reviewer, and no matter whether you use electronic distribution, paper, or
stone tablets, the heart of the review problem is the use of a large batch
transfer late in the process.
The solution is to switch to incremental reviews. Have each piece of
information reviewed individually as soon as it is created. This means that
the reviewers receive information a bit at a time, over the entire length of
the project. They have ample time to respond, and the quality of the
reviews, and the percentage of compliance with the review requests, goes up
Compared to the beneficial effects of switching from monolithic document
reviews late in the cycle to incremental information reviews throughout the
project, everything else you can do pales into insignificance.
Try it. It works.