4.5.1T Deliverable Review

(4.5.1T.P1)

Deliverable reviews, or walkthroughs, can be applied to many of the deliverables produced by the project. For example, the project schedule could go through a deliverable review. Project business requirements can be reviewed. You can walkthrough program code, marketing campaigns and research papers. Deliverables that require human knowledge and creativity can be reviewed. However, you cannot hold a walkthrough for tangible deliverables such as a new computer, aircraft components, automobiles or clothing. There are other techniques, like inspections, to validate these types of deliverables. The following process can be used to plan and conduct a formal deliverable review.

 

Role

Formal Deliverable Review

1

Project Manager

Determine the appropriate review participants

Try to include only those people that can meaningfully contribute to the review. The more people involved in a review, the longer the review is likely to take. Deliverable reviews are quality control activities since they are focused on the deliverable itself. Therefore, the meeting participants must have subject matter expertise in the deliverable being reviewed. The participants are typically peers with the person that created the deliverable.

Multiple reviews may be needed to ensure that large deliverables are created correctly.

2

Review team

(Optional) Define completeness and correctness criteria

The review team can define interim completeness and correctness criteria for the deliverable being reviewed. The interim criteria are helpful because the review team knows ahead of time that the full completeness and correctness criteria will not be met and they can be prepared for multiple reviews before the deliverable is completed.

3

Reviewee

Send out the review material prior to the meeting

There are situations where this is not feasible. However, where possible, the formal review will proceed more quickly if the team has a chance to review the deliverable ahead of time.

4

Reviewee, review team

Conduct the review

The person(s) that created the deliverable walks through the work in a logical manner and answers questions as they arise from the participants. The participants should keep the following meeting principles in mind for the review meeting:

  • Try and hold the review in one hour or less. If the product is too big to be reviewed in an hour, consider breaking it down into smaller parts that can be reviewed in an hour.

  • During the review, the participants should raise questions, voice concerns and offer suggestions. If any topics become complicated, they do not need to be resolved at the walkthrough. They should be taken offline. Likewise, no consensus needs to be reached. If necessary, a consensus or confirmation can occur outside of the meeting.

  • In many cases, the review team will find errors in the deliverables. In other cases, the review team may offer opinions or suggestions that may or may not need to be followed. When feedback is given, it should be made clear whether the review member is uncovering an error that should be addressed or offering a suggestion that might be followed.

  • Don't make review comments personal. The review is of the product, not the person who developed the product. For example, instead of saying that the author made a mistake, the reviewer can point out an error in the deliverable. Instead of saying that the author was sloppy, the reviewer can simply point out the areas of the deliverable that the reviewer feels is sloppy.

  • If there are issues with the author or the deliverable creation process, they should be taken up in a separate meeting.

  • Keep a list of action items during the review.

5

Review team

Check for processes as well

The deliverable review should focus on the completeness and correctness of the deliverable. However, the reviewers should also validate that standard processes were used to create the deliverable. This could include validating the proper templates were used, validating the correct approvals are received and making sure that the deliverable was created following organization policies. These types of questions are related to quality assurance, but they are also valid questions to ask during a deliverable review. The review will then validate that the deliverable is acceptable and that the process used to build the deliverable was acceptable. 

6

Review team

Conclude the review

Determine how the product fared by using one of the following ratings:

  • Pass. The product meets all the completion criteria set forth in the review and does not need further review. Some small changes can be requested, but the deliverable does not have to be reviewed again.

  • More work needed. The product needs rework to meet the completion criteria required for the review. Action items from the review should be documented and kept for the follow-up meeting. When a product fails a review, it will typically need to be reviewed again with the same completion criteria once the necessary changes have been made.

7

Reviewee

Communicate the results of the review

Make sure that all interested parties are given the results of the review.