Use walkthroughs to enhance the quality of your deliverables

Large projects should have a Quality Plan that describes the steps you will take to ensure that you understand the level of quality that your client expects, and how you will go about meeting that quality expectation. One quality control technique is a deliverable walkthrough (sometimes called a deliverable review). Here's how to do one.

One quality control technique is a deliverable walkthrough (sometimes called a deliverable review). The deliverable walkthrough is a formal review process in which project stakeholders are "walked through" a project deliverable, and given the opportunity to ask questions, raise concerns, or make suggestions. Generally speaking, deliverables that require human knowledge and creativity can apply the walkthrough technique. For example, your business requirements report can be reviewed in a walkthrough. The same is true for program code, marketing campaigns, and research papers. However, you can't 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 simple process can be used to plan and conduct a formal deliverable review.

  1. Determine the appropriate review participants. Try to include only those people that can meaningfully contribute to the review.
  2. Send out the review material prior to the meeting, if possible. The formal review will proceed more quickly if the team has a chance to review the deliverable ahead of time.
  3. Conduct the review. The person(s) that created the deliverable walks through the work in a logical order and answers questions as they arise from the participants. Take into account the following points.
  • Try to complete the review in one hour or less to maintain focus.
  • During the review, the participants should raise questions, voice concerns and offer suggestions.
  • If any topics become complicated, they should be taken offline.
  • When feedback is given, the person conducting the review should validate whether the comment reflects an error that should be addressed or is a suggestion that might be followed.
  • The person conducting the review should also make sure that the review comments don't become personal. The review is of the product, not the person who developed the product. For example, instead of saying that the creator made a mistake, the reviewer can point out an error in the deliverable.
  • Keep a list of action items during the review.
  • 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 more substantial rework and should be reviewed again once the necessary changes have been made.
  • Communicate the results of the review. Make sure that all interested parties are given the results of the review.
  • The value in a walkthrough is that you get outside opinions on the overall quality of the deliverable before it is completed, and ensure the deliverable is created using organization standards, guidelines, and accepted practices. This input allows the creator to have a much better chance of delivering an acceptable deliverable the first time. Although it takes time to do the deliverable walkthrough, this time is usually more than made up for by reducing the overall time it would have taken to complete the deliverable and get it approved.