Plan and Optimize Quality of Products and Deliverables

Introduction

This lesson covers task 7 of the Process domain in the July 2026 PMP Examination Content Outline (Process carries 41% of the exam): determine quality standards and requirements for the project and its deliverables, plan quality management, execute the plan, comply with regulations, and keep improving. Quality questions on the exam are rarely about memorizing tools. They ask what a project manager does when a defect appears, when a customer is unhappy, when a regulator is involved, or when the team must choose between speed and rework. Quality applies to predictive, agile, and hybrid projects alike.

After this lesson you will be able to separate quality from grade, define quality requirements and acceptance criteria, plan quality with the right standards and metrics, apply quality tools and the cost of quality, run assurance and control activities, and optimize quality continuously, including with sustainability in mind.

Learning objectives

• Distinguish quality from grade, and prevention from inspection.
• Gather quality requirements and write measurable quality metrics and acceptance criteria.
• Build a quality management plan and plan the right level of review for each deliverable.
• Use the seven basic quality tools and statistical sampling concepts.
• Apply cost of quality, including the cost of conformance and nonconformance.
• Differentiate quality assurance from quality control, and run reviews, audits, and inspections.
• Meet regulatory and organizational standards and handle nonconformance.
• Improve quality continuously in agile and predictive projects, and consider sustainability.

1. What quality means on a project

Quality is the degree to which a set of inherent characteristics of a product, service, or result fulfils requirements. Grade is a category assigned to products with the same functional use but different technical characteristics. A budget hotel and a luxury hotel are different grades; both can be high quality if they deliver what they promise. Low grade is not a quality problem; low quality is always a problem.

Three ideas anchor the exam's view of quality:

• Prevention over inspection. It is cheaper to design quality in than to inspect defects out. A review of requirements costs a few hours; a defect found by a customer can cost the contract.
• Customer satisfaction. Quality is judged against requirements and fitness for use. Conformance to requirements means the work matches what was agreed; fitness for use means it works for its purpose.
• Continuous improvement. Plan-do-check-act (PDCA), kaizen, and agile retrospectives all treat quality as something you keep improving.

Example: grade versus quality

A startup builds a basic mobile app for a local bakery: 5 screens, no analytics, basic styling. A bank builds a mobile app with biometric login, accessibility certification, and 99.95% availability. They differ in grade. If the bakery app crashes twice a day, it has a quality problem; if the bank app is delivered on spec, it does not, even though it is far more expensive. The project manager's job is to deliver the agreed grade without defects.

2. Determine quality requirements and standards

Quality planning starts with understanding what "good" means for each stakeholder. Sources of quality requirements:

Requirements must be turned into measurable statements. A requirement such as "the system must be fast" cannot be verified. A quality metric specifies an attribute and how to measure it: "95% of search requests return within 800 ms under 500 concurrent users, measured by the load test in the staging environment". Acceptance criteria then define the conditions a deliverable must meet to be accepted. In agile projects, these appear in user stories and in the team's definition of done (DoD): for example, code reviewed, unit tests passing at 80% coverage, accessibility checks run, documentation updated.

Worked example: from vague wish to testable criteria

Scenario. A hospital wants a patient portal. The sponsor says, "It has to be reliable and easy to use." The project manager must make this measurable.

Step 1: ask what reliable and easy mean to the stakeholders. Nurses want to see results without calling IT; patients want to book appointments without help; the security officer wants access traced.

Step 2: define metrics.

• Availability of 99.9% during working hours, measured monthly by the monitoring tool (maximum about 44 minutes of downtime per month if measured over 24 x 30 hours).
• 90% of first-time patients complete an appointment booking in under 3 minutes in usability testing with 20 participants.
• 100% of record accesses are written to an audit log.

Step 3: attach verification methods. Monitoring reports, usability tests, and an audit-log inspection before go-live.

Step 4: add them to the quality management plan and the acceptance criteria/DoD.

Why other approaches are weaker. Accepting the vague wish and waiting for the final demo shifts the discovery of disagreement to the end, when rework is most expensive. Copying a generic checklist ignores the specific needs of this hospital. Asking the vendor to define quality alone omits the customer's view.

3. Plan quality management

The quality management plan describes how policies, procedures, and guidelines will be applied to meet quality objectives. It typically covers:

• Quality standards and the quality policy of the organization.
• Quality objectives and metrics.
• Roles and responsibilities for quality (who reviews, who audits, who approves).
• Deliverables and processes subject to quality review, and how often.
• Quality tools, tests, and the planned test environment.
• Procedures for reporting and handling defects and nonconformance.
• Links to risk, scope, schedule, and cost.

It is part of the integrated project management plan. In an adaptive project, the same content may be lighter: the DoD, working agreements, test strategy, and the team's practices for continuous integration and test automation.

Planning for the right level of quality

More quality is not always better. Each deliverable needs the level that matches its risk and use. A safety-critical medical function needs formal inspection and traceability; a throwaway internal report may need only a peer check. The project manager compares the cost of the planned quality activities with the risk they reduce, and agrees the level with the sponsor.

Cost of quality (COQ)

COQ is the total cost of all efforts related to quality over the life of the product.

Rule of thumb for the exam: investing in prevention usually lowers the total cost because external failures are the most expensive. The cost of quality curve has an optimum, not a minimum for everything; spending endlessly on prevention for a trivial feature is also waste.

Worked example: choosing between inspection and prevention

Scenario. A manufacturing project produces 10,000 sensor housings. Currently 4% are defective. Each defect found at final inspection costs 12 to rework; a defect found by a customer costs 180 (replacement, shipping, goodwill). Inspection catches 90% of defects. A proposed prevention measure, a new mould with tighter tolerances, costs 15,000 and cuts the defect rate to 1%.

Step 1: current expected cost. Defects: 10,000 x 4% = 400. Caught internally: 360 x 12 = 4,320. Escaped to customers: 40 x 180 = 7,200. Total failure cost = 11,520.

Step 2: with the new mould. Defects: 10,000 x 1% = 100. Internal: 90 x 12 = 1,080. External: 10 x 180 = 1,800. Total failure cost = 2,880.

Step 3: net effect. Savings = 11,520 - 2,880 = 8,640. The mould costs 15,000, so it does not pay back on this order alone.

Step 4: decide. If the product line continues for two more similar orders, savings reach about 25,920 and the investment pays back. The project manager presents both facts and a recommendation tied to the expected volume, rather than assuming prevention always wins.

Why other choices are weaker. Rejecting the mould by looking only at the 15,000 ignores multi-order value. Approving it without calculation ignores the cost. Doing more inspection only reduces escapes but does not remove rework cost.

4. Quality tools and techniques

The seven basic quality tools

Control charts and the rule of seven

A control chart plots data over time around a mean with upper and lower control limits (commonly 3 standard deviations). The process is in control if points are random within limits. A run of seven consecutive points on one side of the mean, even within limits, signals a non-random pattern and needs investigation (the rule of seven). Control limits are not the same as specification limits: control limits describe what the process actually does; specification limits describe what the customer requires. A process can be in control and still fail the specification.

Other techniques

• Statistical sampling. Choose a part of a population for inspection when testing everything is impractical or destructive. The sample size and the acceptance rule are set in the plan.
• Benchmarking. Compare practices with those of other organizations or projects.
• Design of experiments (DOE). Test combinations of variables to find the best settings without trying every combination.
• Cost-benefit analysis. Compare the cost of a quality action with its benefits.
• Checklists and templates. Prevent omissions and make reviews repeatable.
• Five whys and root cause analysis. Keep asking why until the underlying cause is found, then fix the cause, not the symptom.
• Test-driven development, continuous integration, automated regression tests. Agile and DevOps practices that build quality into the daily work.
• Matrix diagrams, affinity diagrams, and prioritization matrices. Help group and rank quality issues and options.

Example: Pareto analysis in action

A call center records 200 complaints in a month: 84 about billing errors, 52 about long waits, 30 about wrong information, 20 about rude agents, 14 other. Cumulatively, billing errors are 42%, plus long waits 68%, plus wrong information 83%. The first three categories explain more than 80% of the complaints, so the project manager targets billing and wait times first. Working on "rude agents" first, though it is emotionally salient, would address only 10%.

5. Quality assurance and quality control

These two are tested often, and they are different.

Audits are structured, independent reviews that check whether the project follows policies and procedures, identify good and bad practices, and share lessons learned. Inspections examine a work product to see if it conforms to standards, and are called reviews, walkthroughs, or peer reviews depending on the formality. Verification checks that a deliverable meets the specified requirements (done right); validation checks that it meets the customer's needs (done the right thing). QC verifies deliverables internally first; the customer then accepts them formally, which is the scope validation activity.

Handling a defect

When quality control finds a defect:

1. Record it in the defect log and classify severity.
2. Find the root cause, not just the instance.
3. Raise a change request for the corrective action, defect repair, or preventive action. Changes follow the change control process.
4. Re-test the repair and update the documents.
5. Share the lesson so the same cause does not repeat, and check whether risk or the schedule is affected.

In agile projects, defects found inside an iteration are normally fixed in the same iteration or added to the backlog and prioritized by the product owner.

Worked example: a defect found late

Scenario. One week before release, testers find that a payment calculation rounds incorrectly in 2% of cases. The team lead proposes releasing and fixing in the next version. The compliance officer says incorrect rounding could violate consumer rules.

Step 1: assess impact. Wrong amounts affect customers financially and bring regulatory risk. This is not cosmetic.

Step 2: involve the right people. Inform the sponsor and product owner; review the issue with compliance.

Step 3: analyze root cause. The rounding rule was not part of the acceptance criteria, and unit tests did not cover the edge case. Fix the code and add the rule to the DoD and regression tests.

Step 4: decide through governance. Propose holding the release for two days, with a documented change request on schedule, rather than releasing with a known compliance defect.

Step 5: learn. Add a review of financial rules at refinement to prevent recurrence.

Why the other choices are weaker. Releasing and patching accepts known harm. Hiding the defect breaks ethics and trust. Waiting for a customer complaint multiplies cost (external failure). Blaming the tester solves nothing.

6. Regulatory compliance and standards

Quality includes complying with applicable laws, regulations, and standards, as well as organizational policies. The project manager:

• Identifies which regulations and standards apply (for example safety, privacy, environmental, accessibility) early, with help from legal or compliance specialists.
• Turns them into requirements, tests, and acceptance criteria, and keeps evidence (test records, certificates, audit reports).
• Plans for approval steps with external bodies in the schedule, since regulator reviews can take weeks.
• Monitors changes in rules during the project, and raises change requests when needed.
• Treats noncompliance as a high-priority issue with escalation paths defined by governance.

Accessibility is a good example: a public website must meet accessibility standards such as WCAG. Planning it from the start by using accessible design patterns and automated checks is far cheaper than retrofitting after launch.

7. Optimizing quality: improvement and sustainability

Quality management does not stop at conformance. Optimization means refining the process and the product using evidence.

• PDCA. Plan a change, do it on a small scale, check the results, act (adopt, adapt, or abandon).
• Retrospectives and lessons learned. Examine what happened and choose one or two improvements to try next.
• Process analysis. Look for non-value-adding steps, bottlenecks, and rework loops. Lean thinking removes waste (waiting, overprocessing, defects, unused talent).
• Metrics review. Defect escape rate, first-pass yield, mean time to repair, customer satisfaction scores, and cycle time show whether quality is improving.
• Sustainability. Treat environmental and social effects as quality attributes: energy use of the delivered product, material choice, packaging waste, repairability, and end-of-life disposal. Include them in requirements, metrics, and COQ analysis when relevant, for instance by comparing the lifecycle cost of two materials rather than only the purchase price.

Quality in adaptive approaches

In hybrid projects, a predictive part such as hardware with formal inspections can coexist with agile software teams that use a DoD. The project manager aligns them with common quality objectives and a shared defect process.

Technical debt

Shortcuts taken for speed create technical debt: code or design that will cost more later. A team that skips automated tests to hit a date will pay with slower changes and more defects. Make debt visible in the backlog or risk register, agree repayment capacity (for example 15% of each iteration), and do not let it grow silently.

8. Common pitfalls and exam tips

• Pitfall: confusing grade and quality. A lower grade is acceptable if documented; a defect is not.
• Pitfall: relying on inspection. The best answer usually prevents the defect by improving the process or requirements.
• Pitfall: mixing QA and QC. Process audit means QA; testing a deliverable means QC.
• Pitfall: gold plating. Adding unrequested features is not quality; it adds cost and risk.
• Pitfall: fixing the symptom. Look for the root cause before changing the plan.
• Pitfall: skipping the customer. Deliverables are accepted by the customer, not by the project team alone.

Exam tip: When a question asks what to do first about a quality problem, the answer is often to find the root cause or check the quality management plan and standards, before changing the schedule or budget.

Exam tip: If a regulation applies, compliance is not negotiable. Escalate through governance rather than trading it for schedule.

Exam tip: In an agile scenario, the best answer usually involves the team's definition of done, automation, or a retrospective rather than a formal audit by an outside quality department, unless the scenario describes one.

Exam tip: "Most cost effective" in a quality scenario points to prevention (cost of conformance) over external failure.

9. Mini case study: the late-night support tickets

Context. A project delivers a customer portal for a logistics firm. After the first release, support tickets triple: 60% concern incorrect shipment status, 25% slow page loads, 10% login errors, and 5% other. The sponsor is angry, and the team proposes working weekends to fix everything quickly. The release was planned with a manual test cycle of 3 days, no automated regression tests, and no performance requirements in the acceptance criteria. Defects cost about 400 each to fix after release versus about 60 when found in testing.

Question. What should the project manager do?

Solution (commented).

1. Prioritize with Pareto. Status errors (60%) and slow pages (25%) represent 85% of tickets. Focus there first; do not spend equal effort on all categories.
2. Root cause. A fishbone session with developers, testers, and support finds that status data comes from two systems with different update intervals, and that no performance criteria existed. These are requirement and process gaps, not individual mistakes.
3. Fix through change control. Raise change requests for the integration fix and performance work; assess impact on schedule and cost with the sponsor.
4. Prevent. Add performance and data-consistency metrics to the acceptance criteria, build automated regression tests in the pipeline, and add integration scenarios to the definition of done.
5. Quantify the case. If 300 post-release defects cost 400 each, the failure cost is 120,000. Finding 80% of them earlier at 60 each would cost 14,400 plus 24,000 for the 20% still found late at 400, a saving of about 80,000 before counting automation cost. This supports funding prevention.
6. Communicate. Report the plan and expected effect to stakeholders, with weekly defect metrics.
7. Do not simply add weekend overtime: it treats symptoms, risks new defects through fatigue, and ignores the root cause.

Key terms

• Quality: degree to which characteristics meet requirements.
• Grade: category based on technical characteristics.
• Cost of quality (COQ): conformance (prevention, appraisal) plus nonconformance (internal, external failure).
• Quality assurance: process-focused, preventive activities and audits.
• Quality control: product-focused inspection and testing.
• Pareto chart: ranks causes by frequency.
• Control chart: shows process stability against control limits.
• Rule of seven: seven consecutive points on one side of the mean suggest a non-random cause.
• Definition of done: the shared checklist an item must satisfy to count as complete.
• Technical debt: future cost created by shortcuts taken now.
• Verification / validation: built right / built the right thing.

Summary checklist

• I can state the difference between quality and grade.
• I can turn a vague wish into metrics and acceptance criteria.
• I can list what a quality management plan contains.
• I can classify costs as prevention, appraisal, internal failure, or external failure.
• I can pick the right basic quality tool for a situation.
• I can separate QA from QC and verification from validation.
• I know how to handle a defect: log, root cause, change request, retest, learn.
• I treat regulatory compliance as mandatory and plan evidence for it.
• I know how adaptive teams build quality through the definition of done and automation.
• I can include sustainability and continuous improvement in quality planning.

Official sources

• PMI, PMP Examination Content Outline (July 2026): https://www.pmi.org/-/media/pmi/documents/public/pdf/certifications/new-pmp-examination-content-outline-2026.pdf (opens in a new tab)
• PMI, About the new PMP exam: https://www.pmi.org/certifications/project-management-pmp/new-exam (opens in a new tab)
• PMI, Project Management Professional (PMP): https://www.pmi.org/certifications/project-management-pmp (opens in a new tab)