How to Manage a Technical Document Review Process

Review Process is an Unspoken Problem…

One of the most problematic aspects of a technical writing project is the review process.

Usually, the reviewers are less responsive than a technical writer hopes them to be.

Why is that the case? Because reviewers in a typical IT project team are either managers, engineers, or SME technicians, and all are busy trying to get things done. Usually reading a document and trying to make sure that everything in it is okay is left to the very end.

Another practical reason why a document is not reviewed and finalized quickly is that an IT project is a living and evolving entity. It’s not static. Yes there are specs of all kinds and that blueprint is supposed to be guiding every step of the project.

The Reality

But that’s the ideal. The real picture is a more blurred, more dynamic one. There are always additions, changes, deletions, compromises, all kinds of last-hour management decisions. That’s another good reason why an on-time review is the exception and not the rule.

All this means that, at some point every technical writer must take hold of the initiative and DRIVE the review process, gently and with tact, but firmly and intelligently all the same. If you do not declare yourself responsible for the review cycle and do not take it onto yourself to make sure that the reviews are done on time, your document will never be finished and the chances are you’ll get blamed at the end — perhaps for a valid reason as well if you have neglected to drive the process.

Practical Steps to Manage the Review Process

So here are some time-tested practical steps to help you establish CONTROL over this basically unstable and dynamic process:

(1) Determine who is on your REVIEW TEAM. Get it approved by the client or both the Project Manager and the Product Manager. Then communicate the list to everyone involved. Request for acknowledgment of your email to make sure everyone really did get the list.

(2) Determine at least 3 review cycles: First Draft, Second Draft, and Release.

(3) Separate each cycle into two: Writing & Editing phase, and, Review and Feedback Phase.

(4) Prepare a TIME TABLE for all these separate phases.

For example:

FIRST DRAFT: Start Jan 3, End Jan 10.

FIRST DRAFT REVIEW: Start Jan 12, End Jan 23.

SECOND DRAFT: Start Jan 25, End Feb 10.

SECOND DRAFT REVIEW: Start Feb 12, End Feb 21.

RELEASE: Feb 26.

You can use a Word table, an Excel spreadsheet, a MS Project chart, or anything else to keep track of these dates. Formatting is totally up to you and it really does not matter that much. What matters is you develop a system through which you can keep track of these dates.

(5) On the above dates, send appropriate emails to your Review Team, making clear what the DEADLINE is; otherwise some team members may say “I had no idea when I had to finish and return the review.” As I said earlier, people are busy. Don’t assume that they know when to finish a review. Help them with your gentle reminders.

The above simple process will create an environment of team cooperation, transparency, and accountability due to the paper trail it establishes. It can be a shorter or longer process with X-number of phases, depending on the project. But you should definitely develop a similar system of your own to make sure your document is the best possible under the circumstances.