CHAPTER 5

Project Quality Control

Quality control is defined in the PMBOK© Guide as “monitoring specific project results to determine if they comply with relevant standards and identifying ways to eliminate causes of unsatisfactory performance.”1 Control is the activity of ensuring conformance to standards and taking corrective action when necessary to correct problems. Long-term improvements to a process cannot be made until the process is first brought under control.

We define quality control activities to start when processes are qualified in quality assurance. This is an ongoing activity, so quality control activities start repeatedly during a typical project. Quality control activities should continue until the customer accepts the final project deliverables. Quality control is the fourth stage in the five-stage project quality process model, as shown in Figure 5-1.

The project quality control and project quality assurance stages have a large degree of concurrent interaction. For example, if test results are excellent in the project quality control stage, the project deliverables could be accepted rapidly and the project would move to the quality closure stage. On the other hand, if test results are not excellent, more process work in the quality assurance stage may be necessary or some replanning may need to occur back in the quality planning stage.

As is true for all the process stages, the level of detail needed during the project quality control stage can vary significantly from one project to another. Typical project quality control activities are shown in Figure 5-2. The flow of information to the project quality planning stage is shown. The flows of information both to and from the project quality assurance stage are also depicted in this flowchart.

Many tools and checklists can be used to accomplish the tasks during this process stage. Table 5-1 shows the project quality pillars, activities, and tools to be used during the project quality control stage.

This chapter is structured to follow the order of project quality pillars and their sequenced activities shown in Table 5-1. The first number of the listed activities corresponds to the appropriate quality pillar, e.g., Activity 1.1 is associated with the first pillar and Activity 2.1 is associated with the second pillar. The second number of the listed activity refers to the typical approximate chronological sequence of its execution within the pillar’s domain, although this sequential order may vary with different projects, organizations, or industries. For example, 3.1 Use Quality Tools to Test Deliverables normally comes before 3.3 Collect and Share Project Quality Control Lessons Learned.

FIGURE 5-1 Project Quality Process Model

FIGURE 5-2 Project Quality Control Flowchart

TABLE 5-1 Project Quality Control Factors Table

Pillar Activities Tools
1. Customer Satisfaction 1.1 Control Project Inputs
1.2 Control Project Processes
1.3 Control Project Outputs
Control Charts
2. Process Improvement 2.1 Classify and Correct Process Improvement Problems
2.2 Approximate Six Sigma Standards
 
3. Fact-Based Management 3.1 Use Quality Tools to Test Deliverables
3.2 Use Test Results to Correct Any Defects
3.3 Collect and Share Project Quality Control Lessons Learned
Flowcharts, Run Charts, Pareto Diagrams
Plus Delta Model
4. Empowered Performance 4.1 Project Team Endorses Deliverables
4.2 Customer Accepts Deliverables
 

FIRST PROJECT QUALITY PILLAR: CUSTOMER SATISFACTION

The range of quality control includes both product results, such as deliverables, and project management results, such as budgeted cost and schedule deadlines. To ensure customer satisfaction, the project quality control stage entails prevention, inspection, and testing at three points:

  1. At the receipt of incoming project resources

  2. During the project creating/delivery process

  3. Upon completion of project production.

1.1 Control Project Inputs

To ensure customer satisfaction and adherence to the project quality policy, several steps need to be taken. These steps include implementing procedures for project specification and design control, preventing purchasing errors, and applying inspection and sampling techniques. If incoming project resources (human and non-human) are of poor quality, the quality of the final product and the project outcome will be in jeopardy. Clarifying project specifications and design control standards is crucial for controlling the project input structure. Preventing project purchasing errors is important since proper evaluation and selection of suppliers means that initial inputs are likely to conform to requirements.

In addition, inspection and sampling techniques ensure that substandard input does not enter the processing stage. Spot-check procedures select a fixed percentage of a lot for inspection prior to acceptance determination. One hundred percent inspection is theoretically possible but usually impractical. Acceptance sampling takes a statistically calculated random portion, and uses a decision to determine lot acceptance or rejection based on the number of nonconforming items.

1.2 Control Project Processes

Since unwanted variation can occur during the process of product manufacturing or service delivery in a project, controlling in-process attributes and variables is important. An attribute is a performance characteristic that is either present or absent, e.g., the number of tasks completed by the project team or the number of customer complaints about the project. A variable is a performance characteristic that occurs in degrees, e.g., degree of conformance to standards by means of averages or standard deviations, customer time waiting for project completion, or time for a project team to move from conception to completion.

This is where it becomes essential to set tolerances (the result is acceptable to customers if it falls within the range specified by the tolerance) and control limits (the process is in control if the result falls within the control limits) properly. All project processes will demonstrate some variation. Therefore, it is important to determine what type of variation is occurring. Recall from Chapter 1 that random or normal variation occurs when many small things happen. Looking at the entire process systematically reduces random variation.

The other type of variation is called assignable cause or special variation. It occurs when a particular event that is unusual happens. Quickly identifying the unusual occurrence and making a change in the process so it cannot happen again is the best way to reduce this assignable cause variation.

The proper use of quality control charts will assist the manager in distinguishing between random and assignable causes of variation. Control charts can be used to monitor:

  • Project cost variances

  • Project schedule variances

  • Volume and frequency of scope changes

  • Errors in project documents

  • Other process results.

1.3 Control Project Outputs

Final inspection of product and project outputs consists of (1) testing, and (2) taking corrective action based upon the test results. If, for example, a project product is the correct assembly of a computer, one functional test is to turn the computer on and make sure it operates properly.

Another obvious test is visual inspection. Visual inspection can be enhanced by:

  • Limiting the number of quality inspection factors to five or six

  • Minimizing distracting influences or time pressures

  • Providing detailed instructions and checklists for inspection tasks

  • Providing suitable working conditions for the final inspection activity.

Taking necessary corrective action in a timely fashion prior to delivering the product/service to the customer is expected. Any rework based on data regarding feedback changes, process improvements, and/or minor adjustments all impact customer satisfaction.

SECOND PROJECT QUALITY PILLAR: PROCESS IMPROVEMENT

In the project quality control stage, process improvement begins with the final, careful classification of process quality problems and the application of Six Sigma approaches.

2.1 Classify and Correct Process Quality Problems

Project quality process problems can normally be classified as structured, semistructured, and unstructured with respect to the volume and accuracy of information about them. Process improvement of structured problems requires that simple adjustments to the size or volume of an object can be addressed in a straightforward manner to ensure conformance with specifications. In other words, the original system of structured processes was fine but deviations needed to be corrected so that the system could be restored to its intended mode of functioning.

Semistructured and unstructured project process problems, however, require more creativity. The four general types of these problems are:2

  1. Unstructured performance problems

  2. Efficiency problems

  3. Project product design problems

  4. Project process design problems.

An example of an unstructured performance problem is that sales to project customers may be lagging, but there is no one standard way of selling. It is difficult to correct selling performance by referral to a nonexistent standard. Sophisticated diagnosis and creative solutions are required.

An example of an efficiency process problem is slow and cumbersome development of a needed part. Internal organizational stakeholders are adversely impacted by project processes and require coordinated operational streamlining solutions.

In the third type of process problem—project product design—the design does not mesh with customer expectations. A more detailed application of the house of quality approach may be warranted.

Finally, in the fourth type of problem—project process design—radical redesign of the process may be necessary to be competitive. Benchmarking and reengineering can be used to address this process improvement challenge.

2.2 Approximate Six Sigma Standards

Managers of project processes should strive for excellence. The most demanding current method of striving for process excellence is called Six Sigma. Six Sigma represents a quality process level of at most 3.4 defects per million opportunities (3.4 dpmo). While many projects would not have anywhere near this volume of defect opportunities, striving toward this level of process capability can and should be the aim of project process improvement during the project quality control stage.

To move toward Six Sigma level quality, every opportunity for a failure to meet customer expectations needs to be identified and tracked. The aim is to analyze its root cause, take corrective action, and reduce the defects as much as possible. This approach also entails extensive statistical process control and Six Sigma training to create in-house experts who can lead teams and apply the appropriate tools/metrics that focus on bottom line business results. Once critical-to-quality elements are identified in the final process improvement, they are analyzed, improved, and brought under control as rapidly as possible.

THIRD PROJECT QUALITY PILLAR: FACT-BASED MANAGEMENT

Project managers should ensure that several fact-based management activities occur during project quality control. These activities include ensuring that quality tools are used to test deliverables, that test results are used to correct any final defects, and that project quality control lessons are shared to enhance future organizational learning.

3.1 Use Quality Tools to Test Deliverables

Project team members can use a wide range of quality control tools to test the final deliverables. Some representative tools include: elementary and advanced statistical tools, quality function deployment tools, process capability tools, process managing, mistake proofing, and organizational quality audits.

Flowcharts, run charts, and Pareto diagrams are three examples of the standard quality control tools that are useful in implementing fact-based management. The flowcharting illustrated throughout this book demonstrates the way that process managing can clarify the “operational mess” that often constitutes quality control efforts. Flowcharting identifies the sequence of activities and their interconnections from start to finish. By looking at a flowchart, all key project stakeholders can graphically grasp “the big picture” and their role in the project’s completion. In addition, flowcharting enables a project team to pinpoint obvious problems, error-proof the processes, streamline the project by eliminating non-value-added steps, and focus variation reduction interventions.

Project run charts are line graphs in which data are plotted over time. The vertical axis represents a measurement; the horizontal axis is the time dimension. Run charts depict the project performance and the variation of the process indicator over time.

Figure 5-3 depicts the run chart of the weekly percentage of on-time task completions of a project team. The run chart indicates a progressively higher percentage of project team on-time task completions while depicting a fluctuating variation from week to week. Further analysis of these fluctuations might well provide opportunities for improving project team performance by controlling for unnecessary fluctuations.

FIGURE 5-3 Project Run Chart

Finally, project Pareto diagrams are used to depict data collected on check sheets. The characteristics observed are ordered from largest frequency to smallest. For example, Figure 5-4 illustrates the relative magnitude of each type of defect. This knowledge can quickly be used to prioritize control and improvement efforts. The stratification of data can also lead to progressive understanding and resolution of semistructured and unstructured control problems.

3.2 Use Test Results to Correct Any Defects

The technical testing and results are used to correct any defects. The number of non-conforming project outputs may warrant extensive rework or immediate project/process adjustments. Rework is action taken to bring a defective or nonconforming item into compliance with specifications. Since this is a major cause of project overruns, the project team should make every reasonable effort to minimize rework. Nevertheless, fact-based management of quality control is not completed until inspected items are accepted.

In addition to these selected quality control tools, a wide variety of commercial software is available that implements the full range of statistical process control tools. Annual software surveys can be found in such professional publications as Quality Progress and Quality Digest. Commercial software to aid in a variety project control tasks can be found in periodic surveys published in PM Network.

FIGURE 5-4 Project Pareto Diagram

3.3 Collect and Share Project Quality Control Lessons Learned

The collection and sharing of project quality control lessons can be facilitated through use of the plus delta tool. The lessons learned can be shared to promote organizational learning and improve future project control activities.

FOURTH PROJECT QUALITY PILLAR: EMPOWERED PEFORMANCE

The two major activities that empower performance during project quality control both deal with the project deliverables. First, the project team must endorse the deliverables and then the customer must accept the deliverables.

4.1 Project Team Endorses Deliverables

An important dimension of project team empowerment is individual and collective accountability for the quality of the final deliverables. One of the surest ways to enhance team empowerment is through justified shared pride in (1) the project processes used to produce the project deliverables, and (2) the quality of the final deliverables themselves. Successful project leaders and their project teams develop a history together and leave a legacy in that they will only hand over to the customer acceptable final deliverables. This acceptability is determined by the project team endorsing the quality of the deliverables prior to asking the customer to accept them. Nurturing this sense of collective honor creates a culture committed to project quality in the future.

4.2 Customer Accepts Deliverables

After the project team endorses the final deliverables, the customer is handed the project deliverables. However, the project quality control stage is not complete until the customer accepts the deliverables. If the customer has reservations about acceptance, these need to be addressed until the customer is satisfied. Prudent project managers and customers will often require written acceptance of the deliverables.

Project quality assurance is complete upon customer acceptance of the final deliverables. The project, however, is not complete. The final stage of project quality closure is important, yet frequently short-changed since many project participants are already working on new projects.

NOTES

1. Project Management Institute Standards Committee, A Guide to the Project Management Body of Knowledge (PMBOK© Guide) (Upper Darby, PA: Project Management Institute, 2000), p. 95.

2. James R. Evans and William M. Lindsay, The Management and Control of Quality, 5th edition (Cincinnati, OH: South-Western Publishing, 2002).

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.220.140.5