How to Manage a Technical Document Review Process

Document Review Cycle
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.

4 Comments

  1. Kay on December 15, 2010 at 10:43 pm

    Great ideas! the review schedule is a must….I also send out review guidelines on type of review (e.g. content comments v. copyedit), how to provide feedback, and if they need to work as a team with other reviewers. I also find that w new SMEs, I give an overall project plan so that they can see the other work that happens to meet the deliverable. I will also highlight key ideas tomreview/validate.



    • admin on December 15, 2010 at 11:17 pm

      Kay, thanks! Appreciate your input. One thing I forgot to mention is the necessity of inviting the reviewers to nominate a possible replacement in case they leave office for vacation or go out on on assignment during the review period. If a reviewer leaves office without such arrangements, the review will again not get done. Can’t be too analytical or too prepared when it comes to finding a foolproof way to get the review cycle completed. Ugur



      • Kay on December 16, 2010 at 12:09 pm

        That’s an excellent idea. I will add it to my arsenal of review preparation! My goal is always No Surprises for anyone. Reviewers should always know when a review is coming and what they need to do. They should also know roughly what is in the document (since we have discussed content already….I hope!). On a side note, I find that reviewers who are busy are often better focussed in their reviews, as long as I make it as clear and easy as possible. It’s the ones who have too much time on their hands who can be harder to manage….



      • admin on December 16, 2010 at 1:45 pm

        Kay, thanks for your comment. For me the bottom line is to make the review process as transparent and comprehensive as possible. As long as there are “dark corners,” the Murphy’s Law takes over and every single possible thing that can go wrong starts to go wrong! So all that preparatory leg work is good and necessary.