4.7. Plan and Optimize Quality of Products/Deliverables
💡 First Principle: Quality is designed and verified continuously, not inspected in once at the end — "conduct ongoing quality reviews" and "implement continuous improvement" are both explicit, separate enablers precisely because PMI tests whether quality is a running discipline, not a final gate.
Enablers: gather quality requirements for deliverables, plan quality processes and tools, execute the quality management plan, help ensure regulatory compliance, manage cost of quality (CoQ) and sustainability, conduct ongoing quality reviews, and implement continuous improvement.
Cost of Quality (CoQ) frames quality economically: prevention and appraisal costs (planning, training, testing) are "costs of conformance," while internal and external failure costs (rework, warranty claims, reputational damage) are "costs of nonconformance" — and nonconformance costs are reliably larger than the prevention spend that would have avoided them.
The quality cycle
The ECO enablers describe a loop, and the PMBOK Guide 8th edition principle Embed Quality Into Processes and Deliverables is why it is a loop: a single QA gate just before release violates it.
Requirements include regulatory ones, and those are not negotiable against the calendar. If a critical security vulnerability surfaces a week before a regulator-driven launch and the requirements say vulnerabilities must be fixed before go-live, you fix it and renegotiate the date with the regulator or stakeholders.
Cost of quality in practice
| Category | Family | Example |
|---|---|---|
| Prevention | Conformance | Training the team on quality standards, process documentation |
| Appraisal | Conformance | Testing, inspections, peer reviews of scripts, pilot tests |
| Internal failure | Nonconformance | Rework on a defect found before the customer receives it, scrap |
| External failure | Nonconformance | Warranty claims, customer complaints after delivery |
⚠️ Exam Trap: Internal versus external turns on who has the deliverable, not on who found the problem. Rework on defects testers found late — but still before release — is internal failure, however late it was.
Sustainability sits alongside CoQ in the same enabler: a quality plan should account for environmental and social requirements the deliverable must meet, not treat them as a separate concern.
Quality assurance versus quality control
Quality assurance (QA) is proactive and process-oriented: are our processes adequate to produce quality deliverables? A quality audit is a QA tool — it identifies non-conformances in the project's processes and recommends corrective actions. Quality control (QC) is reactive and product-oriented: inspecting deliverables to find defects. QA prevents; QC detects.
Testing levels are QC, and each catches a different class of defect. Unit testing checks individual pieces; integration testing combines modules and tests them as a group; user acceptance testing (UAT) confirms the product meets the business requirements and is acceptable to end users in their operational environment. A defect rate that stays low during sprints but spikes every final integration sprint points to thorough unit testing and inadequate integration testing. When a senior user worries that dependencies will cause release errors, review the test plan with them.
Reading the data
A control chart shows how a process changes over time. Control limits come from the process's own data, typically ±3 sigma, and show what the process normally does; specification limits come from the customer and show what is acceptable. Common cause variation is the normal noise of the process; special cause variation comes from a unique, identifiable condition.
⚠️ Exam Trap: Points inside the control limits are not automatically fine. Seven consecutive points on one side of the mean — the rule of seven — signal a non-random shift and call for a special cause investigation.
A Pareto chart orders defect types from most to least frequent, isolating the "vital few" causes worth fixing first.
Quality in adaptive delivery
Agile teams build quality in through fast feedback loops:
- Definition of Done (DoD) — a shared checklist of criteria every backlog item must meet to be complete.
- Continuous integration (CI) — merging and automatically building and testing changes frequently, at least daily, so defects are detected quickly and the time between finding and fixing one shrinks. Continuous delivery extends CI by automatically releasing passing changes to staging; continuous deployment releases them to production.
- Test-driven development (TDD) — Red-Green-Refactor: write a failing test, write code to pass it, then streamline the code. Refactoring restructures code without changing external behavior.
- The triad — involving a developer, tester, and customer during requirements and design cuts defect costs most, because it prevents defects rather than finding them.
When a customer keeps rejecting completed work for defects, add feedback loops — shoulder checks, peer review, unit and system testing — rather than a bigger end gate. Technical debt, the implied cost of rework from choosing an easy solution now, shows up as story points creeping upward for similar features and as slowing flow; check the cycle time chart to confirm it. Two quality metrics to know: defect cycle time (time from a defect being found to being fixed) and escaped defects (defects that got past testing into production).
⚠️ Exam Trap: Treating additional testing/inspection budget as pure overhead to cut when a project is over budget. PMI's expected reasoning is that cutting prevention/appraisal spend increases downstream failure costs — usually the more expensive outcome.
