Key Concepts
Quality problems are almost always cheaper to prevent than to fix: a defect caught in testing costs far less than one found after delivery. PMI defines quality as the degree to which deliverables fulfill requirements, and quality management is tailored for each project rather than applied the same way everywhere.
Quality problems are almost always cheaper to prevent than to fix. A defect found during testing costs far less to correct than one discovered after delivery. A compliance failure caught during an audit is manageable; one uncovered by a regulator or a client is not. Project managers who treat quality as an afterthought tend to spend the back half of their projects in firefighting mode, correcting what should have been caught earlier.
PMI defines quality as the degree to which deliverables fulfill requirements. In plain terms, something performs as it is supposed to. Quality management is tailored for each project: the quality attributes for a software product look very different from those for a bridge or a medical device, but at a high level they follow the same three-step pattern.
- Plan Quality Management: Identify quality requirements and standards for the project and its deliverables; document how the project will show compliance.
- Manage Quality: Translate the quality management plan into specific activities and confirm the organization’s quality policies are built into the work.
- Control Quality: Monitor the results of quality activities, assess performance, and verify that outputs are complete, correct, and meet customer expectations.
This section walks through each of those steps, plus the tools and continuous improvement practices that support them.
2.7.1 Gather Quality Requirements for Project Deliverables
Before a team can measure quality, it needs to know what quality means for this project. That starts with gathering quality requirements: the standards, regulations, and acceptance criteria the deliverables must meet.
.
Standards
Standards are benchmarks created either by a recognized authority or by general consent.
An authority-created standard is ISO 4210, which specifies safety and performance requirements for the design, assembly, and testing of bicycles. A manufacturer who wants to demonstrate their bikes are safe can test and certify to this standard.
A general-consent standard might come from inside the organization. An IT and operations team might agree that no software system will be handed over to operations if it carries more than three high-severity defects open. No external body mandated that threshold; the teams agreed to it, and it governs their work.
Both types of standard matter and both need to be identified early, because they drive what the project will measure and how.
Regulations
Regulations are requirements imposed by a government body. They may apply to the product, the process, or both, including how compliance is handled and documented.
De jure regulations are those officially mandated by law. De facto regulations are widely accepted in practice even without legal mandate, but ignoring them carries real reputational or commercial risk.
Identifying which regulations apply is part of gathering quality requirements. Missing a regulatory requirement is not a gap that can be closed with a workaround; it can halt delivery or expose the organization to legal liability.
Acceptance Criteria
Acceptance criteria define the conditions a deliverable must meet before it is accepted by the customer or customer proxy. In predictive projects, acceptance criteria are typically recorded in the WBS dictionary or statement of work. In agile projects, they are captured at the story level, often using a Given-When-Then format that makes them directly testable.
Gathering acceptance criteria means working with the customer, not just writing them internally. A team’s assumption of what “done” means and the customer’s expectation can diverge in ways that only surface at handover, and by then the cost of correction is high.
Quality Management Plan
The Quality Management Plan is a component of the project management plan. It documents how the organization’s quality processes, standards, and policies will be applied on this project. Typical sections include:
- Quality standards that apply to the project
- Quality objectives
- Roles and responsibilities for quality activities
- Deliverables and processes subject to quality review
- Quality control and quality management activities planned
- Quality tools that will be used
- Processes for handling nonconformance, corrective actions, and continuous improvement
The plan is not a formality. It is the agreement among the team, the sponsor, and any relevant governance bodies about what quality means here and how it will be demonstrated.
2.7.2 Plan Quality Processes and Tools
Knowing the quality requirements is the first step; deciding how the project will detect, track, and respond to quality issues throughout execution is the second.
Quality Metrics
Quality metrics define what the project will measure and how. They can apply to any project or product attribute: defect rate, test pass percentage, rework hours, response time, or customer satisfaction scores. Each metric definition should specify what is being measured and the method for measuring it, to keep measurement consistent across the project.
Choosing the right metrics matters. A metric that takes a long time to collect or calculate tends to be ignored. Metrics that are self-generating, straightforward, and directly related to quality outcomes are the ones that get used.
Control Limits and Tolerance
Control limits are upper and lower bounds set around a project or product characteristic. Tolerance is the acceptable variation within those bounds.
For example, if packaging rules require that bananas be between 18 cm and 26 cm in length, a banana below 18 cm or above 26 cm is out of tolerance. The project manager is responsible for managing within the tolerance range. When a result breaches a limit, escalation is typically required.
Setting control limits during planning, rather than discovering them during execution, means the team knows in advance when a quality issue needs escalation versus when it can be handled within the project.
Sampling
When inspecting every unit is not practical or cost-effective, a representative sample can be reviewed instead. The goal is to identify quality issues with acceptable confidence while keeping inspection costs reasonable. The sampling approach, including sample size and selection method, should be defined in the quality management plan.
Quality Assurance Functions
Planning should define how the project will respond when quality activities identify problems. The four standard quality assurance responses are:
- Review: Deliverables are examined to verify they meet functional and non-functional requirements.
Validate: Quality assurance confirms whether deliverables are within tolerance and documents any variances.
Recommend: Where defects or noncompliance are found, potential corrections are identified and proposed.
Escalate: When a quality issue exceeds the tolerance level, it is raised to the appropriate party for decision.
Defining these responses in advance removes ambiguity about who does what when a quality issue is detected.
Quality Tools
Several tools support quality planning and analysis.
Checklists
Structured lists used during inspections to verify that required conditions are met. Checklists translate acceptance criteria and quality standards into a repeatable review format.
Pareto Charts
A type of bar chart that ranks the causes of defects from most frequent to least. The Pareto principle holds that roughly 80% of defects come from 20% of the causes, so the chart immediately shows where corrective effort will have the most impact.
Control Charts
Charts that track a process metric over time against defined control limits. They make process variation visible: a process running consistently within its limits is stable, even if individual readings vary. A reading outside the limits, or a series trending toward a limit, signals a process that needs attention.
Histograms
Bar charts showing the frequency of defect types or other quality data. Useful for identifying patterns across a data set.
Scatter Charts
Diagrams showing the relationship between two variables, used to test hypotheses about what is causing a quality problem.
Flowcharts
Process diagrams that map the steps in a process; useful for identifying where defects are likely to be introduced.
Design for X (DfX)
A set of guidelines to optimize design for a specific outcome. The X can be reliability, cost, usability, safety, quality, or any other relevant variable.
2.7.3 Execute a Quality Management Plan
A quality management plan only delivers value when it is followed. Executing it means carrying out the activities defined during planning, collecting quality data, responding to findings, and keeping the relevant records.
The project manager’s role during execution is to confirm that quality activities are happening as planned, that results are being recorded, and that the team is responding to what those results show. This requires active attention, not passive oversight.
Testing and Validation Activities
Testing and validation activities check that project components meet their specifications and any applicable compliance requirements. These are typically conducted by team members, including quality assurance staff embedded in the project team.
Tests generate data. That data feeds the quality metrics defined during planning, and deviations from expected values trigger the review, validate, recommend, and escalate responses defined in the quality management plan.
Connecting Quality to Scope
Quality and scope are closely linked. A deliverable that passes all its internal quality checks but does not meet the acceptance criteria has a scope problem, not just a quality problem. Running quality checks against acceptance criteria, rather than internal specifications alone, keeps the team focused on the customer’s definition of done.
In agile projects, quality is built into each iteration rather than checked at the end. Every sprint includes development, testing, and a review where the product owner and stakeholders inspect the increment against its acceptance criteria. The Definition of Done formalizes the quality checks every story must pass before being counted as complete. This makes quality continuous rather than episodic.
2.7.4 Help Ensure Regulatory Compliance
Regulations are non-negotiable. Unlike a stakeholder preference or an internal quality target, a regulatory requirement is a hard constraint: the project must meet it, and the project manager must plan for how compliance will be demonstrated.
Compliance Monitoring
Compliance monitoring means tracking project information against applicable regulatory requirements throughout the project, not just at handover. It involves reviewing:
- Product and project quality information against regulatory specifications
- Process adherence to required procedures
- Potential threats to compliance as they emerge
- The consequences of any identified gaps
- Recommendations to address compliance needs before they become failures
Regulatory Requirements and Project Planning
Regulatory requirements should be identified at the outset and reflected in the quality management plan. They drive acceptance criteria, testing requirements, documentation standards, and sometimes the delivery approach. A project delivering a medical device has regulatory constraints that shape nearly every phase of work.
If regulations change during the project, that is a significant event. It should be raised as a change request and assessed for its impact on scope, schedule, cost, and quality before any response is agreed.
In hybrid environments, the predictive workstreams often carry the formal compliance responsibilities, since they generate the documented evidence regulators typically require. The agile workstreams contribute to compliance through their quality practices, but the audit trail and formal sign-offs typically live in the plan-driven side of the delivery.
2.7.5 Manage Cost of Quality (CoQ) and Sustainability
Every quality decision has a cost. The question is not whether the project will spend money on quality, but where that money goes: into prevention, into checking, or into fixing failures after the fact.
Cost of Quality
The cost of quality (CoQ) covers all costs related to quality on a project. They fall into two categories: conformance costs and nonconformance costs.
Conformance costs are what the project spends to prevent and detect quality problems:
- Prevention costs: Costs of activities designed to stop defects from occurring. Training, process design, standards development, and requirements review all fall here. Prevention is generally the least expensive form of quality investment per defect avoided.
- Appraisal costs: Costs of evaluating, measuring, testing, and auditing to find defects before they reach the customer. Inspections, testing cycles, and quality audits are appraisal activities.
Nonconformance costs are the price of failure:
- Internal failure costs: The cost of defects found before delivery, including rework, retesting, and scrapped work.
- External failure costs: The cost of defects found after delivery: warranty claims, customer support, product recalls, and reputational damage. These are typically the most expensive category by a wide margin.
The goal is to invest enough in prevention and appraisal to keep failure costs low. Money spent preventing defects returns more than money spent fixing them. There is an optimal balance point, but most projects are far below it when they treat quality as an afterthought.
Sustainability
Sustainability
The 2026 ECO links cost of quality explicitly to sustainability, reflecting a growing expectation that projects account for their broader impact alongside their financial performance.
Sustainability in this context means factoring the long-term environmental, social, and governance impact of project decisions into quality planning. A project that delivers to specification but generates significant waste, consumes resources unsustainably, or creates downstream risk for communities has not fully met a modern definition of quality.
Practical considerations include:
- Material choices and their environmental footprint
- Waste reduction as a quality metric alongside defect rates
- The social impact of how the product or service will be used
- Any governance requirements related to environmental reporting or applicable sustainability standards
These are not separate from quality management; they are additional dimensions of it, and they belong in the quality management plan when they apply. Treat sustainability criteria the same way other quality criteria are treated. Define measurable standards, identify how conformance will be checked, and plan for the cost of achieving those standards upfront rather than remediating violations later.
The same cost-of-quality logic applies. Prevention, meaning designing for sustainability from the start, costs less than appraisal, meaning testing and measuring compliance mid-delivery. Both cost less than failure: regulatory fines, reputational damage, or rework to meet standards that were not built in.
<To be expanded…>
In agile delivery, sustainability requirements are treated as non-functional requirements and added to the definition of done where applicable. Including a sustainability check in the iteration review is a lightweight way to keep compliance visible without adding a separate audit cycle..
2.7.6 Conduct Ongoing Quality Reviews
Quality monitoring runs throughout the project, comparing actual quality performance to the plan and triggering corrective action when deviations occur. It is not a single milestone activity.
Quality Audit
Quality audits are structured, independent reviews examining whether project activities comply with the project’s quality processes, organizational policies, and applicable standards. They are often performed by specialists from outside the project team, such as an internal audit function or a PMO quality team.
Audits are designed to find both problems and good practices. When audits identify shortcomings, findings feed into corrective actions and lessons learned. When they find things done well, those practices can be shared with other projects and added to organizational process assets.
Pareto Analysis
Pareto diagrams rank the causes of quality problems from most frequent to least. They make it immediately clear where corrective effort will have the greatest impact. If four out of five defects in a software project trace to one component, the rework investment belongs there, not spread evenly across everything.
Pareto analysis works well alongside root cause analysis: Pareto identifies what to focus on; root cause analysis explains why it is happening.
Root Cause Analysis
Root cause analysis identifies the underlying cause of a defect, variance, or recurring quality problem. It uses tools such as Failure Modes and Effects Analysis (FMEA) to classify the type, cause, and effect of each failure and assess its risk level. This prioritization guides corrective action toward where it will matter most.
Fishbone Analysis
A fishbone diagram (also called an Ishikawa or cause-and-effect diagram) makes root cause analysis visual. The problem is written at the head of the fish; the team then identifies contributing factors and adds them to the bones. Working through the diagram as a group surfaces causes that might not emerge in a simple conversation, and it creates a shared view of what is driving the problem.
Escalation
Not every quality deviation needs to be escalated. The quality management plan and the defined control limits determine the threshold. When a deviation is within tolerance, the project manager handles it. When it breaches a limit or is forecast to do so, escalation to the appropriate stakeholder or governance body is required. Acting on that signal promptly is part of ongoing quality control.
2.7.7 Implement Continuous Improvement
Correcting individual defects is necessary but not sufficient. A project that repeatedly finds and fixes the same class of defect has a process problem, not a product problem. Continuous improvement means examining how the team works, identifying what generates waste or poor quality, and changing the process so the problem is less likely to recur.
Plan-Do-Check-Act (PDCA)
The Plan-Do-Check-Act cycle, developed by Walter Shewhart and popularized by W. Edwards Deming, is the foundational model for continuous improvement:
- Plan: Identify the improvement opportunity and plan the change.
- Do: Carry out the change, often on a small scale first.
- Check: Measure the results and compare them to what was expected.
- Act: If the change worked, adopt it broadly; if not, learn from it and cycle again.
PDCA is not a one-time fix. It is a repeating cycle that progressively improves a process over time.
Kaizen
Kaizen is an approach to continuous improvement built on the idea that small, incremental changes, made consistently and involving everyone, produce better long-term results than occasional large-scale overhauls. On projects, this translates to a culture where team members at every level are encouraged to identify and propose improvements to the way they work, not just to the deliverables they are building.
Quality Improvement Frameworks
Several broader frameworks draw on the same underlying principles:
- Total Quality Management (TQM): An organization-wide approach involving every function and person in the pursuit of quality, with customer satisfaction as the primary measure of success.
- Six Sigma: A data-driven methodology for reducing defects and process variation, targeting a defect rate of no more than 3.4 per million opportunities. Its DMAIC framework (Define, Measure, Analyze, Improve, Control) provides a structured approach to process improvement.
- Juran Trilogy: Joseph Juran’s model identifies three management processes: Quality Planning, Quality Control, and Quality Improvement, each with a distinct role in maintaining and raising quality standards over time.
Agile and Lean Continuous Improvement
Agile projects build continuous improvement into their cadence. The retrospective, held at the end of each iteration, is a structured opportunity for the team to inspect how they are working and identify one or two changes to try in the next sprint. The plan-build-demo-retrospective cycle closely mirrors the PDCA cycle.
Lean approaches extend this further. Both agile and lean aim to make waste visible so it can be reduced or eliminated. Value stream mapping is a lean tool that traces the flow of work from start to delivery, identifying steps that add no value to the customer. Removing those steps improves throughput, reduces cost, and often improves quality as a direct result.
Deliverables and Tools
Quality Management Plan – A component of the project management plan documenting how quality standards, processes, and activities will be applied throughout the project.
Quality Metrics – Defined measures for tracking quality attributes of project deliverables and processes.
Acceptance Criteria – The conditions a deliverable must meet before the customer or customer proxy accepts it.
Control Chart – A chart tracking a process metric over time against defined control limits, used to monitor process stability.
Quality Audit – A structured independent review of whether project activities comply with applicable quality processes, policies, and standards.
Fishbone Diagram (Ishikawa Diagram) – A visual tool for identifying and displaying the root causes of a quality problem.
Pareto Chart – A ranked bar chart showing the frequency of defect causes, used to prioritize corrective effort.
Root Cause Analysis – A method for identifying the underlying cause of a defect or quality problem, using tools such as Five Whys or FMEA.
Cost of Quality (CoQ) – All costs related to quality on a project, including prevention, appraisal, and failure costs.
PDCA (Plan-Do-Check-Act) – A continuous improvement cycle for planning, implementing, evaluating, and standardizing process improvements.
Lessons Learned Register – A repository of knowledge from current and past projects, including quality-related findings and recommendations.
Related Topics
- 2.1 Develop an integrated project management plan and plan delivery
- 2.2 Develop and manage project scope
- 2.6 Plan and manage finance
- 3.3 Manage and Control Changes
- 3.4 Remove Impediments and Manage Issues
- 3.1 Plan and manage project compliance
- 3.2 Manage project compliance
- 1.7 Help ensure knowledge transfer
- 2.3 Help ensure value-based delivery
- 2.8 Plan and manage schedule
- Sustainability and the 2026 PMP Exam: What Candidates Need to Know
- PMP Mind Map
FAQ
What is quality?
The degree to which deliverables fulfill requirements (PMI definition); in plain terms, something performs as it is supposed to.
Why prevent rather than fix?
A defect found during testing costs far less than one discovered after delivery, and a compliance failure caught in an audit is manageable where one found by a regulator may not.
Is quality management the same on every project?
No. It is tailored for each project.
How does this task fit into the 2026 PMP exam?
Task 2.7 sits in the Process domain of the 2026 Exam Content Outline. The 2026 PMP Exam page has the domain and task breakdown and what changed in the new exam.
