How to Conduct a Review

All of the recommendations for conducting effective meetings also apply to reviews. To make the best use of participants’ time and have an effective review, there are specific steps that you should follo

1. Decide on the purpose of the review

2. Schedule time with participants

3. Distribute review materials

4. Have participants review materials prior to the session

5. Conduct the review session

6. Record review notes

7. Update material

8. Conduct a second review if necessary

This review process should be incorporated into every project plan and become a regular practice in your organization. It is supported by all of the major quality initiatives (i.e., CMMI, ISO) as the best method for “testing” the requirements for quality.

Step 1. Decide on the Purpose of the Review

Any deliverable can be reviewed in a formal review. The more requirements deliverables for which you conduct reviews, the better the quality of your project solution.

• Reviews can be used for project initiation documents to confirm understanding of project scope and gain approval to move forward.

• Reviews conducted for business requirements are opportunities for the business SMEs to carefully review the results of elicitation sessions and verify that their core business needs are articulated, clearly and correctly.

• Technical requirements and specifications are great candidates for reviews because they lay out the “blueprint” for IT work. Any questions or inconsistencies found in these blueprints help to improve the foundation upon which the software is built.

• IT teams often conduct reviews of programs to ensure standards are met and that software will be easy for other developers to understand and maintain.

• Test plans and test cases are also good candidates for reviews. Reviews can compare the tests against the requirements to make sure that all requirements are covered by the testing plans.

• Implementation requirements should always be reviewed with both the business stakeholders and solution team. A smooth implementation depends on a well-thought-out plan, including the concerns and issues of all stake-holders impacted.

Step 2. Schedule Time with Participants

Determining who will participate in the review is an important step in making the review successful. The author of the material being reviewed must always be present. The author, usually the analyst for requirements reviews, best understands the intent of the material and can answer questions from the reviewers. The author also needs to hear suggestions for improvement so that they can be incorporated into the material.

Some review teams use a recorder to take notes during the session. Other teams have the author take notes. This decision should be made by the author. If the author would feel more secure with another person taking notes to be sure that nothing is missed, then another BA is often a good choice for a recorder.

Some review teams also have a participant act as the facilitator or moderator of the session. This person conducts the session and makes sure that the rules are enforced. The larger the group of reviewers, the more important this role becomes in making sure that each participant is heard and that the group stays focused on the topic of the session.

The mandatory participants are the reviewers. They are people who understand the purpose of the requirements and are interested in making the requirements as accurate as possible. A helpful reviewer for requirements is another BA. A BA peer understands the work that was done by the author and can look for holes or inconsistencies even if he or she is not involved with the particular project or knowledgeable about the business area being analyzed.

The most essential reviewers are the SMEs for the requirements. They have provided the requirements to the author and now need to make sure that the author really understood their needs.

Other important participants are solution team stakeholders. These stakeholders will be using the requirements to design and build solutions and will have good questions as they imagine how they will implement the requirements.

Another great resource for requirements reviews is quality assurance. A quality assurance analyst will look at each requirement and think about how it could be tested. If a requirement is too vague or ambiguous to be tested, it needs to be further defined or described.

One caution when inviting participants to a revie Ideally, managers should not be included. There are a couple of important reasons for their exclusion. Since a review is intended to be a discussion about a deliverable, a participant’s title and position in the organization should not have any importance during the session. The review is not a discussion about the author’s productivity or proficiency. It is a discussion about a product. It is not an employee review. This is why managers should not be invited.

When the author’s manager is a participant in the session, the author will be reluctant to admit any mistakes. As participants point out inconsistencies or ambiguous requirements, the author may become defensive, refusing to acknowledge the criticism or accept any suggestions. This destroys the whole point of the review.

When a reviewer’s manager is a participant, it is possible that the reviewer may, consciously or unconsciously, “show off” for his or her boss by pointing out a lot of errors and giving a lot of suggestions for improvements. Some of these suggestions may be for aesthetic changes to the document with little substance because the reviewer is trying to impress his or her boss. This participant may also monopolize the session, wanting the manager to know how smart and prepared he or she is. Unless the manager is a critical SME, find a better way to keep him or her in the progress loop. Send the manager a copy of the review findings or a summary of the results of the review.