Review And Approval

Review And Approval

In the project manager's dreams, the client accepts all documents graciously and with appropriate humility and never imagines questioning the wisdom contained therein. In the real world, clients can be contradictory, inconsistent, and stubborn, and have the temerity to insist that they are the experts in their application area. It is in that real world that clients get to review and approve everything you produce.

The review and approval process, more than any other aspect of a project, is the place where project sociologyand politicsarises. If you do not properly manage the process, it can cause your effort to double or triple over your estimates. It is crucial to define, at the start of the project, the procedure by which deliverables will be accepted.

In the worst case, a document is delivered to and reviewed by several members of the client staff. The author revises the document in accordance with the commentsa process that usually involves one or more meetings or phone calls and has ripple effects on other deliverables. In the meantime, those members of the client staff who are less than enthusiastic about the project have had time to erect more obstructions, so that the next iteration attracts a whole new set of comments. And so the cycle continues.

It is best if review and approval is face to face. The author distributes the document and calls a walkthrough, giving people enough time to read and digest it and to prepare comments. At the walkthrough, all changes to the document must be agreed to. When the changes are made, the document will be accepted. After the walkthrough, the author makes the changes and resubmits the document, and, assuming the revisions are as agreed, the process ends.

There will be exceptions that require further iterations. For example, the document may be inadequate and require extensive revisions, or there may be issues that the client cannot resolve on the spot and that need further work. But in the normal case, reviewers get one chance to correct a deliverable.

Whether review will be conducted in a walkthrough or by returning comments to the author, there are several principles that must be followed in setting up a workable review and approval process.

Forgo Perfection

Nothing is perfect. Anything can be improved. Every circle can be made rounder, and even if you think perfection has been achieved, there will be no shortage of dissenters and critics.

The purpose of a deliverable is to come "close enough." This does not sanction sloppiness, it recognizes the law of diminishing returns. Both project and client staff must acknowledge a threshold of acceptable quality.

Minimize the Number of Reviewers

As the number of reviewers increases:

The number of comments increases arithmetically.

The potential for acrimony increases geometrically.

The probability that comments will contradict one another increases exponentially.

The probability that any given sentence will confuse at least one reviewer approaches certainty.

Remember the Three C's

The only acceptable comments are those that correct, complete, or clarify the deliverable. Comments are appropriate only where a business rule is incorrect, not fully elaborated, or not clearly stated. This principle excludes from comment the organization of the document or its grammar and spelling. Of course, reviewers will identify obvious errors, and conscientious authors will want to correct them, but approval of a document should not depend upon such trivia as whether data is singular or plural. (Comments on spelling are appropriate for visible system components such as screens, reports, or forms, where correct spelling is a reasonable expectation.)

The most contentious of the three C's is clarity. A reviewer will often state that a section is not clear when others have no problem with it. For example, a reviewer may insist that "finished goods" be inserted before every occurrence of "inventory" even though the section heading and context of the document make it clear that the text refers to finished goods inventory. The best way to deal with clarity comments is to ask, at the walkthrough, "Who else had problems with this?" If you see hands go up, change it; otherwise, leave it as is.

Limit the Scope of Comments

Reviewers should be restricted to one set of comments only. If the revised document must be submitted for a second review cycle, comments should be confined to that portion of the document that has changed. No new comments on previously reviewed material should be permitted, or the process will never end.

This principle has two consequences. First, it means that the author should identify revised text, either by redlining or by external references. Otherwise the reviewers cannot know what is new and will be forced to re-review the entire document. Second, the author must refrain from making changes where there are no comments. Otherwise, text that has been closed to review will be reopened.

At times this restriction may seem onerous. What do you do, for example, if a user identifies a problem with previously approved material? You cannot ignore it, but if you accept the comment, you have opened the door to an unending cycle of reviews. Your protection is your reasonable assumption that the review team is conscientious, an expectation that you enforce with the change request procedure. If previously approved material, which is closed to revision, needs to be changed, a change request must be submitted. Two or three of these will ensure that even the most casual reviewers will take their responsibilities more seriously.

Review via Walkthroughs

The worst review and approval procedures are those in which written comments are returned to the author. Many reviewers lack tact, and therefore the comments are often insulting, confusing, trivial, or cryptic. As a result, the author usually feels defensive and compelled to lash back at the reviewers.

The best approach is face to face in a walkthrough. Reviewers will be able to place their comments in a context that the author will better understand, and most reviewers will self-censor their sillier reactions. In addition, a walkthrough allows general agreement on revisions, so that there will be fewer follow-on comments.

Minimize Surprises

Never prepare a deliverable in isolation. In the first place, it will probably be wrong or inadequate. In the second place, it will come as a surprise to the reviewers. Surprises generate comments.

Ensure that deliverables are prepared in working groups or information sessions. Circulate draftsclearly marked as such. Discuss tables of contents. Define approaches to the deliverable. In general, make sure that the contents, organization, and conclusions of the deliverable are well known to the reviewers before it is released. The idea should be to make a product as much the property of the client staff as it is of the developers, on the grounds that it is hard to criticize one's own work.

Qualify Reviewers

Reviewers must be the same people who participated in the preparation of the document. Absentee reviewers are intolerable and can, with little effort, destroy a project.

Foster Teamwork

Whether the review and approval process is marked by acrimony or by cooperation will depend upon the attitudes of the project and client staff. If clients have the attitude that perfection is required and that the developers are underhanded technocrats who must be held in check, or if project staff have the attitude that clients are a group of bureaucratic jerks out to make themselves look good, then deliverable review will be unpleasant and confrontative. To build teamwork, find a counterpart on the client side and build bridges so that the attitude is that each group trusts the competence of the other and accepts that both are attempting to create a quality product.

What If?

The Client Refuses To Accept a Limited Review And Approval Process.

Important deliverables, particularly those on which project progress depends, such as design documents, will not be approved without excruciating effort that will polarize the project and client teams.

Actions

Determine why your client rejects a formal process and how the client is likely to deal with the deliverables you present. Some clients do not like a formal process simply because they do not like formality. They are generally prepared to approve deliverables that are reasonable, but they do not want to be restricted in their ability to make comments. Others are more strict in their demands for perfection and view your attempt to impose formality as an attempt to compromise that demand.

If you believe the client will be easygoing, accept the desire for informality, plan for minimal reviews, and be prepared, if you encounter problems during the project, to work with the client to get the approvals you need. If the deliverables are of good quality and you have read the client correctly, the lack of formality should not be an issue. If it becomes one, appeal to the steering committee.

If you believe the client will be difficult, you are faced with a nowin situation. This is an issue that is critical, and you cannot embark on  a project with such a client without a clear agreement on review and approval. This issue is so important that it is reasonable to insist to your management that you will not continue with the project under these circumstances. If, for personal or career reasons, you are not willing to take this strong a stand, ensure that your management understands the problem, recognizes that the project will probably not meet its targets, and acknowledges that the time for review and approval of each deliverable will be at least as long as the time needed to prepare it.

The Client Ignores The Review And Approval Process And Insists on Additional Reviews.

If this behavior continues, you do not have a review and approval process, and the consequence will be the same as if you had not worked to define one. The difference is that in this case, you have a procedure that has been accepted.

Actions

Assuming that the quality of the deliverables is reasonable, invoke the change request procedure for each review beyond those agreed to. These extended review cycles will incur additional costs and extend the schedule.

Inform the steering committee that the process is not being followed and that there will be an impact on the budget and schedule.

When the client objects, point out that your estimates were based on an agreed-upon procedure for review and approval and that if that procedure is to be changed, your estimates will also change.