Conducting In-Process Quality Assessments

How do you determine if your product development is on track to satisfy its quality objectives? How do you ferret out the current and upcoming risks to your product's quality? Will the product meet customers' quality expectations? Development teams , project managers, and especially the quality professional(s) on the project team need to ask these questions routinely while their product is under development and timely actions can be applied.

In this chapter [1] , we present a four-step process of in-process quality assessment: preparation, evaluation, summarization, and recommendations. A distinction between a quality assessment and a quality audit should be noted. A quality audit, as recognized in current industry literature (e.g., an ISO 9000 registration audit), compares actual practices to the defined process or standard. A quality assessment is concerned with what is occurring, what will be the likely results, and what needs to occur to correct discrepancies between the expected results and the desired results. A quality assessment is concerned with the quality status of the project rather than the state of process practices although there is likely correlation among the two. To achieve an effective quality assessment, the development process, the environment, and the project plan must be well understood .

[1] This chapter is a revision of the paper "A Quality Assessment Process for Products Under Development" by Diane Manlove and Stephen H. Kan, which was presented at the Ninth International Conference on Practical Software Quality Techniques (PSQT 2001 North), St. Paul, Minnesota, October 9 “10, 2001.

A quality assessment can be conducted by an independent team or by the quality professionals who are part of the project team. In-process quality assessment should be an integral part of project management. It should be conducted several times during the development cycle for medium and large projects. Figure 15.1 shows a combination of a simplified software project schedule, a high-level view of a development process, and a set of project management checkpoint reviews. The project checkpoint reviews, denoted PR1 through PR4, are the top row in the figure. For software projects with a development cycle time of one year or longer, it is not unusual to have four or five project checkpoint reviews. For rapid development projects that involve multiple teams and have a development cycle time of six months or shorter, it is preferable to have two or three checkpoint reviews. For small-team projects, formal project checkpoint reviews may not be necessary because the normal project management activities would be adequate to evaluate the overall health of the project. Project checkpoint reviews cover all aspects of the project such as schedule, function, quality, cost, and the overall readiness of the plans to support the delivery of the product. A candid assessment of the in-process quality status of the project should be an integral part of these checkpoint reviews; the following discussions of quality assessment are based on this scenario.

Figure 15.1. A Sample Schedule Showing Project Checkpoints