Principle 8: Build Quality into Processes and Deliverables
PMBOK 7 Statement: "Build quality into processes and deliverables by continuously improving the processes used to manage the project and produce the deliverables, and by verifying that the deliverables meet the acceptance criteria defined by the stakeholders."
Quality in project management has evolved dramatically. In the past, quality was often viewed as a final inspection gate — a team would build something, then a separate quality department would check it, and defects would be caught at the end (or worse, after delivery). PMBOK 7 rejects this approach entirely. Principle 8 asserts that quality must be built into every process and every deliverable, from project initiation through closure. It is not inspected in; it is designed in.
Prevention Over Inspection
The single most important concept in Principle 8 — and one of the most heavily tested quality concepts on the PMP exam — is the idea that preventing defects is always better than finding and fixing them. This principle originates from quality management pioneers such as W. Edwards Deming, Joseph Juran, and Philip Crosby, whose work forms the philosophical foundation of PMBOK 7's quality approach.
Prevention means designing processes that produce quality outputs by default. It includes activities such as:
- Clear requirements definition — Investing time upfront to understand stakeholder needs precisely, using techniques like prototyping, user stories, acceptance criteria, and traceability matrices.
- Process design — Structuring workflows so that errors are impossible or immediately visible. Examples include checklists, peer review gates, automated testing, and standardized templates.
- Training and competency development — Ensuring that everyone performing project work has the skills and knowledge to do it correctly the first time.
- Root cause analysis — When defects occur, investigating and fixing the underlying process issue rather than just the symptom.
Inspection, by contrast, occurs after the work is done. While inspection is still necessary (quality control activities like reviews, testing, and audits serve a purpose), it is inherently less efficient than prevention. Each defect found during inspection represents wasted time, materials, and effort — resources that could have been saved if the defect had been prevented in the first place.
On the PMP exam, whenever you see a question about quality planning or process improvement, look for the answer that emphasizes prevention. If the scenario describes a project that is finding defects during testing, the correct response is almost always to investigate and improve the process that produced the defects, not to add more testing. The PMI mindset consistently favors fixing the root cause over adding more inspection.
The Cost of Quality (COQ)
The Cost of Quality is a critical concept in PMBOK 7. It encompasses all costs incurred to ensure quality — both the costs of achieving quality and the costs of failing to achieve it. PMP candidates must understand the full COQ framework because it frequently appears in exam questions and because it provides the business case for quality investment.
Costs of Conformance (Money Spent to Avoid Defects)
- Prevention costs — Training, process documentation, equipment calibration, quality planning, design reviews, and supplier qualification. These are proactive investments that reduce the likelihood of defects.
- Appraisal costs — Testing, inspections, audits, peer reviews, and quality checks. These are costs of verifying that deliverables meet requirements. While necessary, PMBOK 7 emphasizes that the goal is to shift more investment to prevention (where it prevents waste) and minimize reliance on appraisal (which only catches defects after they occur).
Costs of Non-Conformance (Costs Incurred Due to Defects)
- Internal failure costs — Defects found before delivery: rework, scrap, retesting, downtime, and material waste. These costs are borne entirely by the project.
- External failure costs — Defects found after delivery: warranty claims, liability, recalls, lost customer goodwill, damage to reputation, and corrective maintenance. These are the most expensive because they affect the customer directly and can have long-term business consequences.
| Category | Examples | PMBOK 7 Emphasis |
|---|---|---|
| Prevention | Training, quality planning, process design, supplier qualification | Highest priority — Invest here to minimize all other costs |
| Appraisal | Testing, inspections, audits, peer reviews | Necessary but minimize — Only what is needed to verify quality |
| Internal Failure | Rework, scrap, retesting, material waste | Minimize — Indicates prevention and appraisal are insufficient |
| External Failure | Warranty claims, recalls, lost customers, reputation damage | Eliminate — The most damaging and expensive category |
The earlier in the project lifecycle that quality is addressed, the cheaper it is to ensure it. Fixing a requirements error during the design phase costs a fraction of what it costs during testing, and a tiny fraction of what it costs after deployment. PMBOK 7's emphasis on prevention is rooted in this fundamental economic reality. Every dollar spent on prevention saves many dollars that would otherwise be spent on failure.
Quality Assurance vs. Quality Control
PMBOK 7 maintains the traditional distinction between Quality Assurance (QA) and Quality Control (QC), but contextualizes them within the principle-based framework.
Quality Assurance (QA)
QA is the process of auditing the quality requirements and the results from quality control measurements to ensure that appropriate quality standards and operational definitions are used. In PMBOK 7 terms, QA is about the processes — ensuring that the way the project is being managed and executed is capable of producing quality deliverables. QA activities include process audits, quality management system reviews, process capability assessments, and continuous improvement initiatives. QA is proactive and process-focused. It asks: "Are we using the right processes to build quality in?"
Quality Control (QC)
QC is the process of monitoring and recording results of executing the quality activities to assess performance and recommend necessary changes. QC is about the deliverables — verifying that specific work products meet their acceptance criteria. QC activities include inspections, testing, measurements, statistical sampling, and control charts. QC is reactive and product-focused. It asks: "Does this deliverable meet the specified requirements?"
Both QA and QC are necessary, but PMBOK 7 emphasizes that QA (process improvement) should drive the quality strategy, with QC (product verification) serving as a check rather than the primary quality mechanism. A project that relies on QC alone will always be reactive, expensive, and prone to delivering defects that slip through.
| Dimension | Quality Assurance (QA) | Quality Control (QC) |
|---|---|---|
| Focus | Processes and procedures | Deliverables and products |
| Timing | Throughout the project (continuous) | At specific checkpoints (during and after production) |
| Objective | Prevent defects by improving processes | Identify defects by inspecting deliverables |
| Methods | Process audits, capability analysis, continuous improvement | Inspections, testing, statistical sampling, control charts |
| PMBOK 7 Emphasis | Primary — Build quality into processes | Supporting — Verify quality of deliverables |
Continuous Improvement
Continuous improvement is embedded in PMBOK 7's quality principle through the Plan-Do-Check-Act (PDCA) cycle, popularized by Deming. This iterative four-step model provides a structured approach to improving processes over time.
- Plan — Define the problem, analyze the current state, identify root causes, and develop a change hypothesis. In project management, this might mean analyzing why defects are occurring in a particular work package and planning process changes.
- Do — Implement the planned change on a small scale. Test the new process with one team, one work package, or one iteration before rolling it out broadly.
- Check — Measure the results of the change. Did defect rates decrease? Did productivity improve? Did the change introduce new problems? Use data to evaluate the hypothesis.
- Act — If the change was successful, standardize it across the project. If not, analyze what went wrong and begin a new PDCA cycle. In either case, capture the learning.
The PDCA cycle aligns naturally with agile retrospectives (where teams inspect their process and adapt for the next sprint) and is equally applicable in predictive environments (where lessons learned reviews and phase-end assessments serve a similar function).
Quality Metrics
"What gets measured gets managed" applies directly to quality. PMBOK 7 emphasizes the use of quality metrics to objectively assess whether processes and deliverables meet the defined standards. Key quality metrics include:
- Defect density — Number of defects per unit of output (e.g., defects per 100 lines of code, defects per 100 square meters of construction).
- Defect arrival rate — How quickly defects are being found over time. A rising defect arrival rate may indicate a process problem.
- Rework effort — Hours or cost spent reworking deliverables. Indicates whether prevention is adequate.
- Cost of quality — Total cost of conformance plus non-conformance, tracked over time to evaluate the efficiency of quality investments.
- Customer satisfaction — Direct feedback from stakeholders and end users on whether deliverables meet their needs.
- Process capability (Cp, Cpk) — Statistical measures of whether a process is capable of producing outputs within specification limits.
- First-pass yield — Percentage of deliverables that meet acceptance criteria without rework.
PMBOK 7 references several quality management and control tools that PMP candidates should know: control charts (monitor process stability over time with upper and lower specification limits), cause-and-effect diagrams (fishbone/Ishikawa diagrams for root cause analysis), flowcharts (map processes to identify quality risk points), histograms (visualize defect distribution), Pareto charts (80/20 rule — identify the few defect types causing most of the problems), and scatter diagrams (analyze relationships between variables). These tools are tested on the PMP exam as part of quality management questions.
Quality Built-In, Not Bolted-On
The phrase "quality is built in, not bolted on" captures the essence of Principle 8. Quality cannot be added at the end of a project through inspection alone. It must be designed into the project's processes, embedded in the team's culture, and verified continuously.
This philosophy has several practical implications for project managers:
- Quality planning starts at project initiation — Define quality standards, acceptance criteria, and quality management approach in the project charter and project management plan, not as an afterthought.
- Quality is everyone's responsibility — Not just the quality manager or QA team. Every team member, stakeholder, and supplier contributes to quality. The project manager creates the culture and systems that enable this.
- Quality and speed are not in conflict — A common misconception is that quality takes more time. In reality, building quality in reduces rework, which accelerates delivery. The "slow down to speed up" paradox is central to PMBOK 7's quality philosophy.
- Quality requires data, not opinions — Quality decisions should be based on objective metrics, measurements, and analysis, not on subjective impressions. Use the quality tools and metrics described above to make informed decisions.
- Quality is aligned with value — Principle 4 (Focus on Value) and Principle 8 (Quality) work together. A deliverable that meets specifications but does not deliver stakeholder value is not truly quality. Quality is defined by the stakeholder's acceptance criteria.
In agile environments, quality is built in through practices like test-driven development (writing tests before code), continuous integration (automated testing on every commit), pair programming (real-time peer review), and definition of done (a shared standard that every increment must meet). In predictive environments, quality is built in through rigorous requirements definition, structured design reviews, standardized processes, and phase-gate quality checkpoints. In both cases, the principle is the same: quality is not a separate activity performed at the end — it is integral to every step of the work.
Quality connects strongly to Principle 4: Focus on Value (quality is defined by stakeholder value), Principle 7: Tailoring (quality processes should be tailored to project context), Principle 10: Optimize Risk Responses (quality failures are risks to be managed), and Principle 11: Adaptability and Resiliency (continuous improvement builds resilient processes).
← Previous: Principle 7 — Tailoring | Back to PMBOK 7 Principles | Next: Principle 9 — Complexity →