8

PROJECT QUALITY MANAGEMENT

Project Quality Management includes the processes for incorporating the organization's quality policy regarding planning, managing, and controlling project and product quality requirements in order to meet stakeholders’ objectives. Project Quality Management also supports continuous process improvement activities as undertaken on behalf of the performing organization.

The Project Quality Management processes are:

8.1 Plan Quality Management—The process of identifying quality requirements and/or standards for the project and its deliverables, and documenting how the project will demonstrate compliance with quality requirements and/or standards.

8.2 Manage Quality—The process of translating the quality management plan into executable quality activities that incorporate the organization's quality policies into the project.

8.3 Control Quality—The process of monitoring and recording the results of executing the quality management activities to assess performance and ensure the project outputs are complete, correct, and meet customer expectations.

Figure 8-1 provides an overview of the Project Quality Management processes. The Project Quality Management processes are presented as discrete processes with defined interfaces while, in practice, they overlap and interact in ways that cannot be completely detailed in the PMBOK® Guide. In addition, these quality processes may differ within industries and companies.

Figure 8-2 provides an overview of the major inputs and outputs of the Project Quality Management processes and the interrelations of these processes in the Project Quality Management Knowledge Area. The Plan Quality Management process is concerned with the quality that the work needs to have. Manage Quality is concerned with managing the quality processes throughout the project. During the Manage Quality process, quality requirements identified during the Plan Quality Management process are turned into test and evaluation instruments, which are then applied during the Control Quality process to verify these quality requirements are met by the project. Control Quality is concerned with comparing the work results with the quality requirements to ensure the result is acceptable. There are two outputs specific to the Project Quality Management Knowledge Area that are used by other Knowledge Areas: verified deliverables and quality reports.

KEY CONCEPTS FOR PROJECT QUALITY MANAGEMENT

Project Quality Management addresses the management of the project and the deliverables of the project. It applies to all projects, regardless of the nature of their deliverables. Quality measures and techniques are specific to the type of deliverables being produced by the project. For example, the project quality management of software deliverables may use different approaches and measures from those used when building a nuclear power plant. In either case, failure to meet the quality requirements can have serious negative consequences for any or all of the project's stakeholders. For example:

• Meeting customer requirements by overworking the project team may result in decreased profits and increased levels of overall project risks, employee attrition, errors, or rework.
• Meeting project schedule objectives by rushing planned quality inspections may result in undetected errors, decreased profits, and increased post-implementation risks.

Quality and grade are not the same concepts. Quality as a delivered performance or result is “the degree to which a set of inherent characteristics fulfill requirements” (ISO 9000 [18].). Grade as a design intent is a category assigned to deliverables having the same functional use but different technical characteristics. The project manager and the project management team are responsible for managing the trade-offs associated with delivering the required levels of both quality and grade. While a quality level that fails to meet quality requirements is always a problem, a low-grade product may not be a problem. For example:

• It may not be a problem if a suitable low-grade product (one with a limited number of features) is of high quality (no obvious defects). In this example, the product would be appropriate for its general purpose of use.
• It may be a problem if a high-grade product (one with numerous features) is of low quality (many defects). In essence, a high-grade feature set would prove ineffective and/or inefficient due to low quality.

Prevention is preferred over inspection. It is better to design quality into deliverables, rather than to find quality issues during inspection. The cost of preventing mistakes is generally much less than the cost of correcting mistakes when they are found by inspection or during usage.

Depending on the project and the industry area, the project team may need a working knowledge of statistical control processes to evaluate data contained in the Control Quality outputs. The team should know the differences between the following pairs of terms:

• Prevention (keeping errors out of the process) and inspection (keeping errors out of the hands of the customer);
• Attribute sampling (the result either conforms or does not conform) and variable sampling (the result is rated on a continuous scale that measures the degree of conformity); and
• Tolerances (specified range of acceptable results) and control limits (that identify the boundaries of common variation in a statistically stable process or process performance).

The cost of quality (COQ) includes all costs incurred over the life of the product by investment in preventing nonconformance to requirements, appraising the product or service for conformance to requirements, and failing to meet requirements (rework). Failure costs are often categorized into internal (found by the project team) and external (found by the customer). Failure costs are also called the cost of poor quality. Section 8.1.2.3 provides some examples to consider in each area. Organizations choose to invest in defect prevention because of the benefits over the life of the product. Because projects are temporary, decisions about the COQ over a product's life cycle are often the concern of program management, portfolio management, the PMO, or operations.

There are five levels of increasingly effective quality management as follows:

• Usually, the most expensive approach is to let the customer find the defects. This approach can lead to warranty issues, recalls, loss of reputation, and rework costs.
• Detect and correct the defects before the deliverables are sent to the customer as part of the quality control process. The control quality process has related costs, which are mainly the appraisal costs and internal failure costs.
• Use quality assurance to examine and correct the process itself and not just special defects.
• Incorporate quality into the planning and designing of the project and product.
• Create a culture throughout the organization that is aware and committed to quality in processes and products.

TRENDS AND EMERGING PRACTICES IN PROJECT QUALITY MANAGEMENT

Modern quality management approaches seek to minimize variation and to deliver results that meet defined stakeholder requirements. Trends in Project Quality Management include but are not limited to:

• Customer satisfaction. Understand, evaluate, define, and manage requirements so that customer expectations are met. This requires a combination of conformance to requirements (to ensure the project produces what it was created to produce) and fitness for use (the product or service needs to satisfy the real needs). In agile environments, stakeholder engagement with the team ensures customer satisfaction is maintained throughout the project.
• Continual improvement. The plan-do-check-act (PDCA) cycle is the basis for quality improvement as defined by Shewhart and modified by Deming. In addition, quality improvement initiatives such as total quality management (TQM), Six Sigma, and Lean Six Sigma may improve both the quality of project management, as well as the quality of the end product, service, or result.
• Management responsibility. Success requires the participation of all members of the project team. Management retains, within its responsibility for quality, a related responsibility to provide suitable resources at adequate capacities.
• Mutually beneficial partnership with suppliers. An organization and its suppliers are interdependent. Relationships based on partnership and cooperation with the supplier are more beneficial to the organization and to the suppliers than traditional supplier management. The organization should prefer long-term relationships over short-term gains. A mutually beneficial relationship enhances the ability for both the organization and the suppliers to create value for each other, enhances the joint responses to customer needs and expectations, and optimizes costs and resources.

TAILORING CONSIDERATIONS

Each project is unique; therefore, the project manager will need to tailor the way Project Quality Management processes are applied. Considerations for tailoring include but are not limited to:

• Policy compliance and auditing. What quality policies and procedures exist in the organization? What quality tools, techniques, and templates are used in the organization?
• Standards and regulatory compliance. Are there any specific quality standards in the industry that need to be applied? Are there any specific governmental, legal, or regulatory constraints that need to be taken into consideration?
• Continuous improvement. How will quality improvement be managed in the project? Is it managed at the organizational level or at the level of each project?
• Stakeholder engagement. Is there a collaborative environment for stakeholders and suppliers?

CONSIDERATIONS FOR AGILE/ADAPTIVE ENVIRONMENTS

In order to navigate changes, agile methods call for frequent quality and review steps built in throughout the project rather than toward the end of the project.

Recurring retrospectives regularly check on the effectiveness of the quality processes. They look for the root cause of issues then suggest trials of new approaches to improve quality. Subsequent retrospectives evaluate any trial processes to determine if they are working and should be continued or new adjusting or should be dropped from use.

In order to facilitate frequent, incremental delivery, agile methods focus on small batches of work, incorporating as many elements of project deliverables as possible. Small batch systems aim to uncover inconsistencies and quality issues earlier in the project life cycle when the overall costs of change are lower.

8.1 PLAN QUALITY MANAGEMENT

Plan Quality Management is the process of identifying quality requirements and/or standards for the project and its deliverables, and documenting how the project will demonstrate compliance with quality requirements and/or standards. The key benefit of this process is that it provides guidance and direction on how quality will be managed and verified throughout the project. This process is performed once or at predefined points in the project. The inputs and outputs of this process are depicted in Figure 8.3. Figure 8.4 depicts the data flow diagram for the process.

Quality planning should be performed in parallel with the other planning processes. For example, changes proposed in the deliverables in order to meet identified quality standards may require cost or schedule adjustments and a detailed risk analysis of the impact to plans.

The quality planning techniques discussed here are those used most frequently on projects. There are many others that may be useful on certain projects or in specific application areas.

8.1.1 PLAN QUALITY MANAGEMENT: INPUTS

8.1.1.1 PROJECT CHARTER

Described in Section 4.1.3.1. The project charter provides the high-level project description and product characteristics. It also contains the project approval requirements, measurable project objectives, and related success criteria that will influence the quality management of the project.

8.1.1.2 PROJECT MANAGEMENT PLAN

Described in Section 4.2.3.1. Project management plan components include but are not limited to:

• Requirements management plan. Described in Section 5.1.3.2. The requirements management plan provides the approach for identifying, analyzing, and managing the requirements that the quality management plan and quality metrics will reference.
• Risk management plan. Described in Section 11.1.3.1. The risk management plan provides the approach for identifying, analyzing, and monitoring risks. The information in the risk management plan and quality management plan work together to successfully deliver product and project success.
• Stakeholder engagement plan. Described in Section 13.2.3.1. The stakeholder engagement plan provides the method for documenting the stakeholders’ needs and expectations that provide the foundation for quality management.
• Scope baseline. Described in Section 5.4.3.1. The WBS along with the deliverables documented in the project scope statement are considered while determining which quality standards and objectives are suitable for the project, and which project deliverables and processes will be subjected to quality review. The scope statement includes the acceptance criteria for the deliverables. The definition of acceptance criteria may significantly increase or decrease quality costs and, therefore, project costs. Satisfying all acceptance criteria implies the needs of the stakeholders have been met.

8.1.1.3 PROJECT DOCUMENTS

Project documents that can be considered as inputs for this process include but are not limited to:

• Assumption log. Described in Section 4.1.3.2. The assumption log has all the assumptions and constraints regarding quality requirements and standard compliance.
• Requirements documentation. Described in Section 5.2.3.1. Requirements documentation captures the requirements that the project and product should attain to meet stakeholder expectations. The components of the requirements documentation include but are not limited to project and product quality requirements. Requirements are used by the project team to help plan how quality control will be implemented on the project.
• Requirements traceability matrix. Described in Section 5.2.3.2. The requirements traceability matrix links product requirements to deliverables and helps to ensure each requirement in the requirements documentation is tested. The matrix provides an overview of the tests required to verify the requirements.
• Risk register. Described in Section 11.2.3.1. The risk register contains information on threats and opportunities that may impact quality requirements.
• Stakeholder register. Described in Section 13.1.3.1. The stakeholder register helps to identify stakeholders who have a particular interest in or impact on quality, with the emphasis on the customer and project sponsor needs and expectations.

8.1.1.4 ENTERPRISE ENVIRONMENTAL FACTORS

The enterprise environmental factors that can influence the Plan Quality Management process include but are not limited to:

• Governmental agency regulations;
• Rules, standards, and guidelines specific to the application area;
• Geographic distribution;
• Organizational structure;
• Marketplace conditions;
• Working or operating conditions of the project or its deliverables; and
• Cultural perceptions.

8.1.1.5 ORGANIZATIONAL PROCESS ASSETS

The organizational process assets that can influence the Plan Quality Management process include but are not limited to:

• Organizational quality management system including policies, procedures, and guidelines;
• Quality templates such as check sheets, traceability matrix, and others; and
• Historical databases and lessons learned repository.

8.1.2 PLAN QUALITY MANAGEMENT: TOOLS AND TECHNIQUES

8.1.2.1 EXPERT JUDGMENT

Described in Section 4.1.2.1. Expertise should be considered from individuals or groups with specialized knowledge or training in the following topics:

• Quality assurance,
• Quality control,
• Quality measurements,
• Quality improvements, and
• Quality systems.

8.1.2.2 DATA GATHERING

Data-gathering techniques that can be used for this process include but are not limited to:

• Benchmarking. Benchmarking involves comparing actual or planned project practices or the project's quality standards to those of comparable projects to identify best practices, generate ideas for improvement, and provide a basis for measuring performance. Benchmarked projects may exist within the performing organization or outside of it, or can be within the same application area or other application area. Benchmarking allows for analogies from projects in a different application area or different industries to be made.
• Brainstorming. Described in Section 4.1.2.2. Brainstorming can be used to gather data creatively from a group of team members or subject matter experts to develop the quality management plan that best fits the upcoming project.
• Interviews. Described in Section 5.2.2.2. Project and product quality needs and expectations, implicit and explicit, formal and informal, can be identified by interviewing experienced project participants, stakeholders, and subject matter experts. Interviews should be conducted in an environment of trust and confidentiality to encourage honest and unbiased contributions.

8.1.2.3 DATA ANALYSIS

Data analysis techniques that can be used for this process include but are not limited to:

• Cost-benefit analysis. A cost-benefit analysis is a financial analysis tool used to estimate the strengths and weaknesses of alternatives in order to determine the best alternative in terms of benefits provided. A cost-benefit analysis will help the project manager determine if the planned quality activities are cost effective. The primary benefits of meeting quality requirements include less rework, higher productivity, lower costs, increased stakeholder satisfaction, and increased profitability. A cost-benefit analysis for each quality activity compares the cost of the quality step to the expected benefit.
• Cost of quality. The cost of quality (COQ) associated with a project consists of one or more of the following costs (Figure 8-5 lists examples for each cost group):

• Prevention costs. Costs related to the prevention of poor quality in the products, deliverables, or services of the specific project.
• Appraisal costs. Costs related to evaluating, measuring, auditing, and testing the products, deliverables, or services of the specific project.
• Failure costs (internal/external). Costs related to nonconformance of the products, deliverables, or services to the needs or expectations of the stakeholders.

The optimal COQ is one that reflects the appropriate balance for investing in the cost of prevention and appraisal to avoid failure costs. Models show that there is an optimal quality cost for projects, where investing in additional prevention/appraisal costs is neither beneficial nor cost effective.

8.1.2.4 DECISION MAKING

A decision-making technique that can be used for this process includes but is not limited to multicriteria decision analysis. Multicriteria decision analysis tools (e.g., prioritization matrix) can be used to identify the key issues and suitable alternatives to be prioritized as a set of decisions for implementation. Criteria are prioritized and weighted before being applied to all available alternatives to obtain a mathematical score for each alternative. The alternatives are then ranked by score. As used in this process, it can help prioritize quality metrics.

8.1.2.5 DATA REPRESENTATION

Data representation techniques that can be used for this process include but are not limited to:

• Flowcharts. Flowcharts are also referred to as process maps because they display the sequence of steps and the branching possibilities that exist for a process that transforms one or more inputs into one or more outputs. Flowcharts show the activities, decision points, branching loops, parallel paths, and the overall order of processing by mapping the operational details of procedures that exist within a horizontal value chain. One version of a value chain, known as a SIPOC (suppliers, inputs, process, outputs, and customers) model, is shown in Figure 8-6. Flowcharts may prove useful in understanding and estimating the cost of quality for a process. Information is obtained by using the workflow branching logic and associated relative frequencies to estimate the expected monetary value for the conformance and nonconformance work required to deliver the expected conforming output. When flowcharts are used to represent the steps in a process, they are sometimes called process flows or process flow diagrams and they can be used for process improvement as well as identifying where quality defects can occur or where to incorporate quality checks.
• Logical data model. Logical data models are a visual representation of an organization's data, described in business language and independent of any specific technology. The logical data model can be used to identify where data integrity or other quality issues can arise.
• Matrix diagrams. Matrix diagrams help find the strength of relationships among different factors, causes, and objectives that exist between the rows and columns that form the matrix. Depending on how many factors may be compared, the project manager can use different shapes of matrix diagrams; for example, L, T, Y, X, C, and roof–shaped. In this process they facilitate identifying the key quality metrics that are important for the success of the project.
• Mind mapping. Described in Section 5.2.2.3. Mind mapping is a diagrammatic method used to visually organizing information. A mind map in quality is often created around a single quality concept, drawn as an image in the center of a blank landscape page, to which associated representations of ideas such as images, words, and parts of words are added. The mind-mapping technique may help in the rapid gathering of project quality requirements, constraints, dependencies, and relationships.

8.1.2.6 TEST AND INSPECTION PLANNING

During the planning phase, the project manager and the project team determine how to test or inspect the product, deliverable, or service to meet the stakeholders’ needs and expectations, as well as how to meet the goal for the product's performance and reliability. The tests and inspections are industry dependent and can include, for example, alpha and beta tests in software projects, strength tests in construction projects, inspection in manufacturing, and field tests and nondestructive tests in engineering.

8.1.2.7 MEETINGS

Project teams may hold planning meetings to develop the quality management plan. Attendees can include the project manager, the project sponsor, selected project team members, selected stakeholders, anyone with responsibility for project quality management activities, and others as needed.

8.1.3 PLAN QUALITY MANAGEMENT: OUTPUTS

8.1.3.1 QUALITY MANAGEMENT PLAN

The quality management plan is a component of the project management plan that describes how applicable policies, procedures, and guidelines will be implemented to achieve the quality objectives. It describes the activities and resources necessary for the project management team to achieve the quality objectives set for the project. The quality management plan may be formal or informal, detailed, or broadly framed. The style and detail of the quality management plan are determined by the requirements of the project. The quality management plan should be reviewed early in the project to ensure that decisions are based on accurate information. The benefits of this review can include a sharper focus on the project's value proposition, reductions in costs, and less frequent schedule overruns that are caused by rework.

The quality management plan may include but is not limited to the following components:

• Quality standards that will be used by the project;
• Quality objectives of the project;
• Quality roles and responsibilities;
• Project deliverables and processes subject to quality review;
• Quality control and quality management activities planned for the project;
• Quality tools that will be used for the project; and
• Major procedures relevant for the project, such as dealing with nonconformance, corrective actions procedures, and continuous improvement procedures.

8.1.3.2 QUALITY METRICS

A quality metric specifically describes a project or product attribute and how the Control Quality process will verify compliance to it. Some examples of quality metrics include percentage of tasks completed on time, cost performance measured by CPI, failure rate, number of defects identified per day, total downtime per month, errors found per line of code, customer satisfaction scores, and percentage of requirements covered by the test plan as a measure of test coverage.

8.1.3.3 PROJECT MANAGEMENT PLAN UPDATES

Any change to the project management plan goes through the organization's change control process via a change request. Components that may require a change request for the project management plan include but are not limited to:

• Risk management plan. Described in Section 11.1.3.1. Decisions on the quality management approach may require changes to the agreed-upon approach to managing risk on the project, and these will be recorded in the risk management plan.
• Scope baseline. Described in Section 5.4.3.1. The scope baseline may change as a result of this process if specific quality management activities need to be added. The WBS dictionary also records quality requirements, which may need updating.

8.1.3.4 PROJECT DOCUMENTS UPDATES

Project documents that may be updated as a result of carrying out this process include but are not limited to:

• Lessons learned register. Described in Section 4.4.3.1. The lessons learned register is updated with information on challenges encountered in the quality planning process.
• Requirements traceability matrix. Described in Section 5.2.3.2. Where quality requirements are specified by this process, they are recorded in the requirements traceability matrix.
• Risk register. Described in Section 11.2.3.1. New risks identified during this process are recorded in the risk register and managed using the risk management processes.
• Stakeholder register. Described in Section 13.1.3.1. Where additional information on existing or new stakeholders is gathered as a result of this process, it is recorded in the stakeholder register.

8.2 MANAGE QUALITY

Manage Quality is the process of translating the quality management plan into executable quality activities that incorporate the organization's quality policies into the project. The key benefits of this process are that it increases the probability of meeting the quality objectives as well as identifying ineffective processes and causes of poor quality. Manage Quality uses the data and results from the control quality process to reflect the overall quality status of the project to the stakeholders. This process is performed throughout the project.

The inputs, tools and techniques, and outputs of this process are depicted in Figure 8-7. Figure 8-8 depicts the data flow diagram of the process.

Manage Quality is sometimes called quality assurance, although Manage Quality has a broader definition than quality assurance as it is used in nonproject work. In project management, the focus of quality assurance is on the processes used in the project. Quality assurance is about using project processes effectively. It involves following and meeting standards to assure stakeholders that the final product will meet their needs, expectations, and requirements. Manage Quality includes all the quality assurance activities, and is also concerned with the product design aspects and process improvements. Manage Quality work will fall under the conformance work category in the cost of quality framework.

The Manage Quality process implements a set of planned and systematic acts and processes defined within the project's quality management plan that helps to:

• Design an optimal and mature product by implementing specific design guidelines that address specific aspects of the product,
• Build confidence that a future output will be completed in a manner that meets the specified requirements and expectations through quality assurance tools and techniques such as quality audits and failure analysis,
• Confirm that the quality processes are used and that their use meets the quality objectives of the project, and
• Improve the efficiency and effectiveness of processes and activities to achieve better results and performance and enhance stakeholders’ satisfaction.

The project manager and project team may use the organization's quality assurance department, or other organizational functions, to execute some of the Manage Quality activities such as failure analysis, design of experiments, and quality improvement. Quality assurance departments usually have cross-organizational experience in using quality tools and techniques and are a good resource for the project.

Manage Quality is considered the work of everybody—the project manager, the project team, the project sponsor, the management of the performing organization, and even the customer. All of these have roles in managing quality in the project, though the roles differ in size and effort. The level of participation in the quality management effort may differ between industries and project management styles. In agile projects, quality management is performed by all team members throughout the project, but in traditional projects, quality management is often the responsibility of specific team members.

8.2.1 MANAGE QUALITY: INPUTS

8.2.1.1 PROJECT MANAGEMENT PLAN

Described in Section 4.2.3.1. Project management plan components include but are not limited to the quality management plan. Described in Section 8.1.3.1, the quality management plan defines the acceptable level of project and product quality and describes how to ensure this level of quality in its deliverables and processes. The quality management plan also describes what to do with nonconforming products and what corrective action to implement.

8.2.1.2 PROJECT DOCUMENTS

Project documents that can be considered as inputs for this process include but are not limited to:

• Lessons learned register. Described in Section 4.4.3.1. Lessons learned earlier in the project with regard to managing quality can be applied to later phases in the project to improve the efficiency and effectiveness of managing quality.
• Quality control measurements. Described in Section 8.3.3.1. Quality control measurements are used to analyze and evaluate the quality of the processes and deliverables of the project against the standards of the performing organization or the requirements specified. Quality control measurements can also compare the processes used to create the measurements and validate actual measurements to determine their level of correctness.
• Quality metrics. Described in Section 8.1.3.2. Quality metrics are verified as part of the Control Quality process. The Manage Quality process uses these quality metrics as a basis for the development of test scenarios for the project and its deliverables and as a basis for improvement initiatives.
• Risk report. Described in Section 11.2.3.2. Risk report is used in the Manage Quality process to identify sources of overall project risk and the most important drivers of overall risk exposure that can impact the quality objectives of the project.

8.2.1.3 ORGANIZATIONAL PROCESS ASSETS

The organizational process assets that can influence the Manage Quality process include but are not limited to:

• Organizational quality management system that includes policies, procedures, and guidelines;
• Quality templates such as check sheets, traceability matrix, test plans, test documents, and others;
• Results from previous audits; and
• Lessons learned repository with information from similar projects.

8.2.2 MANAGE QUALITY: TOOLS AND TECHNIQUES

8.2.2.1 DATA GATHERING

A data-gathering technique that can be used for this process includes but is not limited to checklists (see Section 11.2.2.2). A checklist is a structured tool, usually component-specific, used to verify that a set of required steps has been performed or to check if a list of requirements has been satisfied. Based on the project's requirements and practices, checklists may be simple or complex. Many organizations have standardized checklists available to ensure consistency in frequently performed tasks. In some application areas, checklists are also available from professional associations or commercial service providers. Quality checklists should incorporate the acceptance criteria included in the scope baseline.

8.2.2.2 DATA ANALYSIS

Data analysis techniques that can be used for this process include but are not limited to:

• Alternatives analysis. Described in Section 9.2.2.5. This technique is used to evaluate identified options in order to select which different quality options or approaches are most appropriate to use.
• Document analysis. Described in Section 5.2.2.3. The analysis of different documents produced as part of the output of project control processes, such as quality reports, test reports, performance reports, and variance analysis, can point to and focus on processes that may be out of control and may jeopardize meeting the specified requirements or stakeholders’ expectations.
• Process analysis. Process analysis identifies opportunities for process improvements. This analysis also examines problems, constraints, and non-value-added activities that occur during a process.
• Root cause analysis (RCA). Root cause analysis is an analytical technique used to determine the basic underlying reason that causes a variance, defect, or risk. A root cause may underlie more than one variance, defect, or risk. It may also be used as a technique for identifying root causes of a problem and solving them. When all root causes for a problem are removed, the problem does not recur.

8.2.2.3 DECISION MAKING

A decision-making technique that can be used for this process includes but is not limited to multicriteria decision analysis. Described in Section 8.1.2.4. Multicriteria decision making is used to evaluate several criteria when discussing alternatives that impact project or product quality. Project decisions can include choosing among different implementation scenarios or suppliers. Product decisions can include evaluating the life cycle cost, schedule, stakeholder satisfaction, and risks associated with resolving product defects.

8.2.2.4 DATA REPRESENTATION

Data representation techniques that can be used for this process include but are not limited to:

• Affinity diagrams. Described in Section 5.2.2.5. Affinity diagrams can organize potential causes of defects into groups showing areas that should be focused on the most.
• Cause-and-effect diagrams. Cause-and-effect diagrams are also known as fishbone diagrams, why-why diagrams, or Ishikawa diagrams. This type of diagram breaks down the causes of the problem statement identified into discrete branches, helping to identify the main or root cause of the problem. Figure 8-9 is an example of a cause-and-effect diagram.
• Flowcharts. Described in Section 8.1.2.5. Flowcharts show a series of steps that lead to a defect.
• Histograms. Histograms show a graphical representation of numerical data. Histograms can show the number of defects per deliverable, a ranking of the cause of defects, the number of times each process is noncompliant, or other representations of project or product defects.
• Matrix diagrams. Described in Section 8.1.2.5. The matrix diagram seeks to show the strength of relationships among factors, causes, and objectives that exist between the rows and columns that form the matrix.
• Scatter diagrams. A scatter diagram is a graph that shows the relationship between two variables. Scatter diagrams can demonstrate a relationship between any element of a process, environment, or activity on one axis and a quality defect on the other axis.

8.2.2.5 AUDITS

An audit is a structured, independent process used to determine if project activities comply with organizational and project policies, processes, and procedures. A quality audit is usually conducted by a team external to the project, such as the organization's internal audit department, PMO, or by an auditor external to the organization. Quality audit objectives may include but are not limited to:

• Identifying all good and best practices being implemented;
• Identifying all nonconformity, gaps, and shortcomings;
• Sharing good practices introduced or implemented in similar projects in the organization and/or industry;
• Proactively offering assistance in a positive manner to improve the implementation of processes to help raise team productivity; and
• Highlighting contributions of each audit in the lessons learned repository of the organization.

The subsequent effort to correct any deficiencies should result in a reduced cost of quality and an increase in sponsor or customer acceptance of the project's product. Quality audits may be scheduled or random, and may be conducted by internal or external auditors.

Quality audits can confirm the implementation of approved change requests including updates, corrective actions, defect repairs, and preventive actions.

8.2.2.6 DESIGN FOR X

Design for X (DfX) is a set of technical guidelines that may be applied during the design of a product for the optimization of a specific aspect of the design. DfX can control or even improve the product's final characteristics. The X in DfX can be different aspects of product development, such as reliability, deployment, assembly, manufacturing, cost, service, usability, safety, and quality. Using the DfX may result in cost reduction, quality improvement, better performance, and customer satisfaction.

8.2.2.7 PROBLEM SOLVING

Problem solving entails finding solutions for issues or challenges. It can include gathering additional information, critical thinking, creative, quantitative and/or logical approaches. Effective and systematic problem solving is a fundamental element in quality assurance and quality improvement. Problems can arise as a result of the Control Quality process or from quality audits and can be associated with a process or deliverable. Using a structured problem-solving method will help eliminate the problem and develop a long-lasting solution. Problem-solving methods generally include the following elements:

• Defining the problem,
• Identifying the root-cause,
• Generating possible solutions,
• Choosing the best solution,
• Implementing the solution, and
• Verifying solution effectiveness.

8.2.2.8 QUALITY IMPROVEMENT METHODS

Quality improvements can occur based on findings and recommendations from quality control processes, the findings of the quality audits, or problem solving in the Manage Quality process. Plan-do-check-act and Six Sigma are two of the most common quality improvement tools used to analyze and evaluate opportunities for improvement.

8.2.3 MANAGE QUALITY: OUTPUTS

8.2.3.1 QUALITY REPORTS

The quality reports can be graphical, numerical, or qualitative. The information provided can be used by other processes and departments to take corrective actions in order to achieve the project quality expectations. The information presented in the quality reports may include all quality management issues escalated by the team; recommendations for process, project, and product improvements; corrective actions recommendations (including rework, defect/bugs repair, 100% inspection, and more); and the summary of findings from the Control Quality process.

8.2.3.2 TEST AND EVALUATION DOCUMENTS

Test and evaluation documents can be created based on industry needs and the organization's templates. They are inputs to the Control Quality process and are used to evaluate the achievement of quality objectives. These documents may include dedicated checklists and detailed requirements traceability matrices as part of the document.

8.2.3.3 CHANGE REQUESTS

Described in Section 4.3.3.4. If changes occur during the Manage Quality process that impact any of the components of the project management plan, project documents, or project or product management processes, the project manager should submit a change request and follow the Perform Integrated Change Control process as defined in Section 4.6.

8.2.3.4 PROJECT MANAGEMENT PLAN UPDATES

Any change to the project management plan goes through the organization's change control process via a change request. Components that may require a change request for the project management plan include but are not limited to:

• Quality management plan. Described in Section 8.1.3.1. The agreed-upon approach to managing quality may need to be modified due to the actual results.
• Scope baseline. Described in Section 5.4.3.1. The scope baseline may change as a result of specific quality management activities.
• Schedule baseline. Described in Section 6.5.3.1. The schedule baseline may change as a result of specific quality management activities.
• Cost baseline. Described in Section 7.3.3.1. The cost baseline may change as a result of specific quality management activities.

8.2.3.5 PROJECT DOCUMENTS UPDATES

Project documents that may be updated as a result of carrying out this process include but are not limited to:

• Issue log. Described in Section 4.3.3.3. New issues raised as a result of this process are recorded in the issue log.
• Lessons learned register. Described in Section 4.4.3.1. The lessons learned register is updated with information on challenges encountered and how they could have been avoided as well as approaches that worked well for the managing quality.
• Risk register. Described in Section 11.2.3.1. New risks identified during this process are recorded in the risk register and managed using the risk management processes.

8.3 CONTROL QUALITY

Control Quality is the process of monitoring and recording results of executing the quality management activities in order to assess performance and ensure the project outputs are complete, correct, and meet customer expectations. The key benefit of this process is verifying that project deliverables and work meet the requirements specified by key stakeholders for final acceptance. The Control Quality process determines if the project outputs do what they were intended to do. Those outputs need to comply with all applicable standards, requirements, regulations, and specifications. This process is performed throughout the project.

The inputs, tools and techniques, and outputs of this process are depicted in Figure 8-10. Figure 8-11 depicts the data flow diagram of the process.

The Control Quality process is performed to measure the completeness, compliance, and fitness for use of a product or service prior to user acceptance and final delivery. This is done by measuring all steps, attributes, and variables used to verify conformance or compliance to the specifications stated during the planning stage.

Quality control should be performed throughout the project to formally demonstrate, with reliable data, that the sponsor's and/or customer's acceptance criteria have been met.

The level of effort to control quality and the degree of implementation may differ between industries and project management styles; in pharmaceutical, health, transportation, and nuclear industries, for example, there may be stricter quality control procedures compared to other industries, and the effort needed to meet the standards may be extensive. For example, in agile projects, the Control Quality activities may be performed by all team members throughout the project life cycle. In waterfall model-based projects, the quality control activities are performed at specific times, toward the end of the project or phase, by specified team members.

8.3.1 CONTROL QUALITY: INPUTS

8.3.1.1 PROJECT MANAGEMENT PLAN

Described in Section 4.2.3.1. Project management plan components include but are not limited to the quality management plan. Described in Section 8.1.3.1, the quality management plan defines how quality control will be performed within the project.

8.3.1.2 PROJECT DOCUMENTS

Project documents that can be considered as inputs for this process include but are not limited to:

• Lessons learned register. Described in Section 4.4.3.1. Lessons learned earlier in the project can be applied to later phases in the project to improve quality control.
• Quality metrics. Described in Section 8.1.3.2. A quality metric specifically describes a project or product attribute and how the Control Quality process will verify compliance to it.
• Test and evaluation documents. Described in Section 8.2.3.2. Test and evaluation documents are used to evaluate achievement of the quality objectives.

8.3.1.3 APPROVED CHANGE REQUESTS

Described in Section 4.6.3.1. As part of the Perform Integrated Change Control process, a change log update indicates that some changes are approved and some are not. Approved change requests may include modifications such as defect repairs, revised work methods, and revised schedules. Partial change completion may result in inconsistencies and later delays due to incomplete steps or corrections. The implementation of approved changes should be verified, confirmed for completeness, retested, and certified as correct.

8.3.1.4 DELIVERABLES

A deliverable is any unique and verifiable product, result, or capability to perform a service that is required to be produced to complete a process, phase, or project. Deliverables that are outputs from the Direct and Manage Project Work process are inspected and compared to the acceptance criteria defined in the project scope statement.

8.3.1.5 WORK PERFORMANCE DATA

Described in Section 4.3.3.2. Work performance data contains data on product status such as observations, quality metrics, and measurements for technical performance, as well as project quality information on schedule performance and cost performance.

8.3.1.6 ENTERPRISE ENVIRONMENTAL FACTORS

The enterprise environmental factors that can influence the Control Quality process include but are not limited to:

• Project management information system; quality management software can be used to track errors and variations in processes or deliverables;
• Governmental agency regulations; and
• Rules, standards, and guidelines specific to the application area.

8.3.1.7 ORGANIZATIONAL PROCESS ASSETS

The organizational process assets that can influence the Control Quality process include but are not limited to:

• Quality standards and policies;
• Quality templates, for example, check sheets, checklists, etc. and;
• Issue and defect reporting procedures and communication policies.

8.3.2 CONTROL QUALITY: TOOLS AND TECHNIQUES

8.3.2.1 DATA GATHERING

Data-gathering techniques that can be used for this process include but are not limited to:

• Checklists. Described in Section 11.2.2.2. Checklists help in managing the control quality activities in a structured manner.
• Check sheets. Check sheets are also known as tally sheets and are used to organize facts in a manner that will facilitate the effective collection of useful data about a potential quality problem. They are especially useful for gathering attributes data while performing inspections to identify defects; for example, data about the frequencies or consequences of defects collected. See Figure 8-12.

• Statistical sampling. Statistical sampling involves choosing part of a population of interest for inspection (for example, selecting 10 engineering drawings at random from a list of 75). The sample is taken to measure controls and verify quality. Sample frequency and sizes should be determined during the Plan Quality Management process.
• Questionnaires and Surveys. Surveys may be used to gather data about customer satisfaction after the deployment of the product or service. The cost regarding defects identified in the surveys may be considered external failure costs in the COQ model and can have extensive cost implications for the organization.

8.3.2.2 DATA ANALYSIS

Data analysis techniques that can be used for this process include but are not limited to:

• Performance reviews. Performance reviews measure, compare, and analyze the quality metrics defined by the Plan Quality Management process against the actual results.
• Root cause analysis (RCA). Described in Section 8.2.2.2. Root cause analysis is used to identify the source of defects.

8.3.2.3 INSPECTION

An inspection is the examination of a work product to determine if it conforms to documented standards. The results of inspections generally include measurements and may be conducted at any level. The results of a single activity can be inspected, or the final product of the project can be inspected. Inspections may be called reviews, peer reviews, audits, or walkthroughs. In some application areas, these terms have narrow and specific meanings. Inspections also are used to verify defect repairs.

8.3.2.4 TESTING/PRODUCT EVALUATIONS

Testing is an organized and constructed investigation conducted to provide objective information about the quality of the product or service under test in accordance with the project requirements. The intent of testing is to find errors, defects, bugs, or other nonconformance problems in the product or service. The type, amount, and extent of tests needed to evaluate each requirement are part of the project quality plan and depend on the nature of the project, time, budget, and other constraints. Tests can be performed throughout the project, as different components of the project become available, and at the end of the project on the final deliverables. Early testing helps identify nonconformance problems and helps reduce the cost of fixing the nonconforming components.

Different application areas require different tests. For example, software testing may include unit testing, integration testing, black-box, white-box, interface testing, regression testing, Alpha testing, etc. In construction projects, testing may include cement strength, concrete workability test, nondestructive tests at construction sites for testing the quality of hardened concrete structures, and soil tests. In hardware development, testing may include environmental stress screening, burn-in tests, system testing, and more.

8.3.2.5 DATA REPRESENTATION

Data representation techniques that can be used for this process include but are not limited to:

• Cause-and-effect diagrams. Described in Section 8.2.2.4. Cause-and-effect diagrams are used to identify the possible effects of quality defects and errors.
• Control charts. Control charts are used to determine whether or not a process is stable or has predictable performance. Upper and lower specification limits are based on the requirements and reflect the maximum and minimum values allowed. Upper and lower control limits are different from specification limits. The control limits are determined using standard statistical calculations and principles to ultimately establish the natural capability for a stable process. The project manager and appropriate stakeholders may use the statistically calculated control limits to identify the points at which corrective action will be taken to prevent performance that remains outside the control limits. Control charts can be used to monitor various types of output variables. Although used most frequently to track repetitive activities required for producing manufactured lots, control charts may also be used to monitor cost and schedule variances, volume, frequency of scope changes, or other management results to help determine if the project management processes are in control.
• Histograms. Described in Section 8.2.2.4. Histograms can demonstrate the number of defects by source or by component.
• Scatter diagrams. Described in Section 8.2.2.4. Scatter diagrams can show the planned performance on one axis and the actual performance on the second axis.

8.3.2.6 MEETINGS

The following meetings may be used as part of the Control Quality process:

• Approved change requests review. All approved change requests should be reviewed to verify that they were implemented as approved. This review should also check that partial changes are completed and all parts have been properly implemented, tested, completed, and certified.
• Retrospectives/lesson learned. A meeting held by a project team to discuss:

• Successful elements in the project/phase,
• What could be improved,
• What to incorporate in the ongoing project and what in future projects, and
• What to add to the organization process assets.

8.3.3 CONTROL QUALITY: OUTPUTS

8.3.3.1 QUALITY CONTROL MEASUREMENTS

Quality control measurements are the documented results of Control Quality activities. They should be captured in the format that was specified in the quality management plan.

8.3.3.2 VERIFIED DELIVERABLES

A goal of the Control Quality process is to determine the correctness of deliverables. The results of performing the Control Quality process are verified deliverables that become an input to the Validate Scope process (Section 5.5) for formalized acceptance. If there were any change requests or improvements related to the deliverables, they may be changed, inspected, and reverified.

8.3.3.3 WORK PERFORMANCE INFORMATION

Described in Section 4.5.1.3. Work performance information includes information on project requirements fulfillment, causes for rejections, rework required, recommendations for corrective actions, lists of verified deliverables, status of the quality metrics, and the need for process adjustments.

8.3.3.4 CHANGE REQUESTS

Described in Section 4.3.3.4. If changes occur during the Control Quality process that may impact any of the components of the project management plan or project documents, the project manager should submit a change request. Change requests are processed for review and disposition through the Perform Integrated Change Control process (Section 4.6).

8.3.3.5 PROJECT MANAGEMENT PLAN UPDATES

Any change to the project management plan goes through the organization's change control process via a change request. Components that may require a change request for the project management plan include but are not limited to the quality management plan, as described in Section 8.1.3.1.

8.3.3.6 PROJECT DOCUMENTS UPDATES

Project documents that may be updated as a result of carrying out this process include but are not limited to:

• Issue log. Described in Section 4.3.3.3. Many times a deliverable that does not meet the quality requirements is documented as an issue.
• Lessons learned register. Described in Section 4.4.3.1. The lessons learned register is updated with information on the source of quality defects and how they could have been avoided as well as approaches that worked well.
• Risk register. Described in Section 11.2.3.1. New risks identified during this process are recorded in the risk register and managed using the risk management processes.
• Test and evaluation documents. Described in Section 8.2.3.2. Test and evaluation documents may be modified as a result of this process in order to make future tests more effective.