Planning and managing quality

PMP-130 planned what Project Compass would deliver, when and for how much. This course covers the parts of the plan that decide whether those deliverables will be good enough, what could go wrong or unexpectedly right, what will be bought from others and how the whole plan is held together as things change: quality, risk, procurement and integration, ending with closing the project. This first lesson is about quality: what it means on a project, how to plan for it, what it costs to get right and to get wrong, and how quality management differs from inspection. The next lesson turns to the tools used to control quality and improve processes.

Where this course sits in the exam and the PMBOK Guide

At the time of writing (October 2026), the PMP exam follows the examination content outline that took effect on 9 July 2026, with three domains: People (about 33 % of scored questions), Process (about 41 %) and Business Environment (about 26 %). PMP-101 mapped the tasks. This course covers the Process tasks on quality, procurement and closure, finishes the integrated plan begun in PMP-130, and covers two tasks that the 2026 outline places in Business Environment: planning and managing risk, and managing and controlling changes. It also touches the task of removing impediments and managing issues, where issues meet risks.

The PMBOK Guide, eighth edition, released digitally in late 2025, organizes guidance into seven performance domains (governance, scope, schedule, finance, stakeholders, resources and risk) and five focus areas (initiating, planning, executing, monitoring and controlling, and closing). Risk is a domain in its own right. Quality and procurement are not domain names in that structure; their guidance runs across domains, with quality closely tied to scope (requirements and acceptance) and governance, and procurement tied to resources, finance and governance. For the exam, the names of processes matter less than knowing what each activity is for, what it produces and which tool fits a given situation.

What quality means on a project

Quality is the degree to which a set of characteristics fulfils requirements. That definition sounds dry, but it has a sharp consequence: quality is judged against what was agreed, not against what the team thinks would be best. A kiosk that meets every requirement is a quality kiosk, even if a more expensive model exists. A beautiful app feature nobody asked for is not higher quality; it is unapproved scope, and PMP-130 called it gold plating.

Two related ideas are easy to confuse. Grade is a category assigned to deliverables with the same functional use but different technical characteristics: a basic kiosk and a premium kiosk with a larger screen and a coin acceptor are different grades. Low grade is not a problem if it is what the customer chose; low quality, meaning failure to meet the agreed requirements, always is. A low-grade, high-quality kiosk is simple and works reliably. A high-grade, low-quality kiosk has every feature and keeps freezing.

Tolerances and control limits are another favourite distinction. A tolerance is set by the customer or the specification: it says what results are acceptable. Control limits are calculated from the process's own data: they say what variation is normal for the process as it currently runs. A process can be in control but produce results outside tolerance (it is stable but not capable), or be out of control while all results so far happen to be within tolerance (it is unpredictable). Lesson 2 shows control limits in action.

Principles of modern quality management

Project quality management draws on the work of quality pioneers such as Deming, Juran and Crosby, and on international standards such as the ISO 9000 family. Several principles appear repeatedly in exam questions.

Customer satisfaction comes first: understanding, evaluating, defining and managing requirements so that the customer's needs are met. Juran called this fitness for use. On Project Compass, the customers include the library board, branch staff and patrons, and their needs are captured in the requirements and acceptance criteria from PMP-130.

Prevention over inspection is the most important principle for exam purposes. Quality should be planned, designed and built in, not inspected in afterwards. Inspection finds defects that already exist; prevention stops them from occurring. The cost of preventing a mistake is generally much lower than the cost of finding and correcting it, and much lower again than the cost of a defect found by the customer. Crosby summed this up as "quality is free": the money spent on prevention is repaid by avoided failures.

Continuous improvement means that processes are measured and improved in cycles, such as Deming's plan-do-check-act, rather than fixed once. Management responsibility means that the people who control resources and processes are accountable for quality; Deming argued that most quality problems are caused by the system, not by individual workers. Finally, mutually beneficial partnerships with suppliers recognize that a project's quality depends heavily on what it buys, a theme that returns in the procurement lessons.

The quality management plan

In a predictive or hybrid project, the quality management plan is a component of the project management plan. It describes how quality requirements and standards will be identified and how the project will demonstrate compliance with them. It answers who is responsible for quality, which standards apply, which deliverables and processes will be reviewed, which quality control and assurance activities will be performed and when, which tools will be used, and how nonconformities and corrective actions will be handled. It should be proportionate: a small internal project may need a page; a regulated facility may need a detailed plan tied to a formal quality system.

Quality metrics translate requirements into measurable attributes and the way they will be measured. A metric needs a definition, a target and a measurement method; without the method, people will argue later about whether the target was met. Good metrics are few, relevant to what stakeholders care about and measurable at reasonable cost.

Some quality requirements come from law and standards, not from preference. For the Eastgate branch, the provincial building code's accessibility (barrier-free design) requirements apply to the fit-out, and the library has adopted CSA B651 as its design standard for accessible spaces and the Web Content Accessibility Guidelines (WCAG) 2.1 at level AA for its app. Requirements like these are non-negotiable: the quality management plan names them, assigns reviewers with the right competence and schedules reviews early, when correcting a problem is cheap.

The cost of quality

The cost of quality (COQ) is the total cost of all efforts related to quality over a product's life cycle. It has two halves. The cost of conformance is money spent to avoid failures: prevention costs, such as training, design reviews and better processes, and appraisal costs, such as testing, inspection and audits. The cost of nonconformance is money spent because of failures: internal failure costs found by the project, such as rework and scrap, and external failure costs found by the customer, such as warranty work, complaints and lost reputation. External failures are usually the most expensive and the most damaging, because they reach users and are hard to contain.

# Cost of quality for Project Compass ($000, invented planning estimates)
coq = {
    "Prevention": [("Accessibility design review", 12), ("Staff training on tag encoding", 9),
                   ("Kiosk vendor demo and pilot", 14)],
    "Appraisal": [("Tag read-rate testing", 22), ("Building inspections and walk-throughs", 15),
                  ("App test automation and device lab", 18)],
    "Internal failure": [("Re-encoding faulty tags", 16), ("Fixing punch-list items before opening", 24)],
    "External failure": [("Post-opening kiosk fixes and call-outs", 21), ("App fixes after release", 17),
                         ("Patron complaints and goodwill", 8)],
}
total = sum(v for items in coq.values() for _, v in items)
print(f"{'Category':18s}{'$000':>7s}{'Share':>8s}")
for cat, items in coq.items():
    s = sum(v for _, v in items)
    print(f"{cat:18s}{s:7d}{s / total:8.0%}")
conf = sum(v for c in ("Prevention", "Appraisal") for _, v in coq[c])
nonconf = total - conf
print(f"{'Total':18s}{total:7d}")
print(f"\nCost of conformance {conf}, cost of nonconformance {nonconf}")

# Option: add a second encoding station and pre-shipment tag audit (+11 prevention/appraisal)
# Expected effect from the pilot: re-encoding falls by half, kiosk call-outs fall by a third
new_conf = conf + 11
new_nonconf = nonconf - 16 / 2 - 21 / 3
print(f"With the extra prevention and appraisal: conformance {new_conf}, "
      f"nonconformance {new_nonconf:.0f}, total {new_conf + new_nonconf:.0f} (was {total})")

Category             $000   Share
Prevention             35     20%
Appraisal              55     31%
Internal failure       40     23%
External failure       46     26%
Total                 176

Cost of conformance 90, cost of nonconformance 86
With the extra prevention and appraisal: conformance 101, nonconformance 71, total 172 (was 176)

The estimate shows almost as much expected spending on failure ($86,000) as on conformance ($90,000), and more than a quarter of the total on failures found after opening. The quality lead proposes adding a second pre-shipment audit of tag batches and moving the kiosk acceptance test earlier, for $11,000 more in prevention and appraisal. Pilot evidence suggests this would halve tag re-encoding and cut kiosk call-outs by a third. The model predicts a lower total cost of quality and, more importantly, fewer failures that patrons see in the first weeks of the branch's life. This is the economic argument behind prevention over inspection.

Cost of quality has limits. Some costs are hard to estimate, especially reputational damage, and spending on prevention shows diminishing returns: beyond some point, extra inspection costs more than the failures it prevents. Product life cycle matters too. A project that cuts quality costs to stay within budget may hand operations a product that is expensive to support. Life-cycle thinking, which PMP-130 introduced for cost estimating, applies equally to quality decisions.

Managing quality and controlling quality

Two activities are often confused. Managing quality, often called quality assurance, is about the processes: are we following the planned quality processes, and are they effective? It is executed throughout the project, typically through audits, process analysis and design for quality, and it builds stakeholder confidence that the deliverables will meet requirements. Controlling quality is about the products: do the deliverables meet the specified requirements? It involves measuring and testing outputs and comparing results with the metrics.

A quality audit is a structured, independent review of whether project activities comply with organizational and project policies, processes and procedures. Audits identify good practices to share, gaps and shortcomings, and lessons that can improve the process on this and future projects. They are not punitive inspections of people; when they feel like that, people hide problems. On Project Compass, the library's facilities manager audits the contractor's own quality control records monthly, and the technology lead audits whether the app team's definition of done is actually applied to every story.

Two terms from PMP-130 connect here. Control quality produces verified deliverables: outputs that have been checked for correctness. Validate scope then obtains formal acceptance of those verified deliverables from the customer or sponsor. Order matters: you verify internally first, then ask the customer to accept. A deliverable that has not passed quality control should not be presented for acceptance.

Quality in adaptive and hybrid projects

Adaptive approaches build quality in through short feedback loops rather than relying on late inspection. Each user story has acceptance criteria. A team-wide definition of done lists the conditions every increment must meet, such as code reviewed, automated tests passing, accessibility checked and documentation updated. Practices such as test-driven development, continuous integration and frequent demonstrations catch defects close to where they are created. Retrospectives are a continuous improvement mechanism for the team's process. PMP-140 covers these practices in depth.

In a hybrid project like Project Compass, the quality management plan should say how quality is managed in each part and how the parts meet. The fit-out uses inspections, test reports and a formal punch list. The app team uses its definition of done and automated testing. Integration points, such as the app's connection to the library's catalogue system and the kiosks' connection to the same system, get joint test plans with clear owners, because defects at interfaces are the ones nobody feels responsible for.