Quality Management in PMP Terms, Minus the Jargon
The most useful thing PMP study did for my understanding of quality was drawing one line: quality is not the same as grade. Grade is how many features something has. Quality is whether it conforms to its requirements. A simple integration that never drops an order is high quality. A feature-rich one that loses data under load is low quality, no matter how impressive the demo. Once that line is drawn, a lot of arguments in delivery rooms turn out to be grade arguments wearing quality costumes.
PMBOK organizes quality work into three processes, and they map cleanly onto how real projects live or die.
Plan quality: decide what good means before building
Quality planning is answering, in writing, what standards this deliverable must meet and how we will know. For an integration project that means concrete statements: no order lost between systems, sync latency under a threshold, reconciliation matching to the cent. Vague quality bars ("stable", "user-friendly") are not standards, they are wishes; you cannot test a wish. I keep this planning output short, a page of measurable statements, because a quality plan nobody rereads protects nobody. There is a separate walkthrough of how I build that page.
Manage quality: audit the process, not just the output
The middle process, often labeled QA, is about whether the way you work produces quality by default. Code review coverage, test automation, definition of done actually enforced, deployment checklists actually followed. The tell is what happens under deadline pressure: a team whose quality lives in the process keeps reviewing code in a crunch week; a team whose quality lives in heroics stops, and you find out at go-live.
Control quality: inspect the deliverable itself
QC is the concrete verification: test runs, defect counts, acceptance criteria checked against the built thing. The classic PMP phrase is that QA is prevention and QC is inspection, and the classic PMP warning is not to rely on the second. Inspection finds defects after they are built, at the price of rework. Prevention makes them not exist, at the price of discipline.
Cost of quality: the argument that actually convinces sponsors
The concept I use most in real conversations is cost of quality. Money spent on quality splits into conformance costs (reviews, tests, automation, training) and non-conformance costs (rework, incidents, emergency patches, reputation). Sponsors see the first category in the budget and the second category nowhere, until an incident queue makes it visible.
The most convincing quality argument I ever made was not a methodology slide. It was arithmetic from our own history: hours engineering spent on emergency fixes and root cause analysis for one recurring class of defect, priced against the automation that would have prevented it. The prevention cost roughly a sprint. The failures had already cost several. RCA and CAPA work taught me this pattern repeats everywhere: every recurring incident is the non-conformance budget announcing itself, one outage at a time.
Where I see quality management fail
Two patterns cover most of it. First, quality as a phase: "we'll stabilize at the end." The end is when rework is most expensive and the calendar has the least room, so this plan amounts to scheduling the crisis. Second, quality as someone else's department: QC owned by testers while everyone upstream optimizes for speed. Quality survives exactly as far upstream as it is owned.
The PMP framing, for all its exam-speak, gets the essentials right: define good measurably, build a process that produces it by default, verify the output anyway, and know your cost of quality well enough to defend prevention money before the incidents defend it for you, at a much worse rate.
Nguyễn Hải Nam
Project Management Lead. 16+ years from code to delivery. PMP®. Writing here about project management and engineering.