Writing a Quality Plan People Actually Use
I have inherited quality management plans that ran fifteen pages and governed nothing. Beautifully formatted, referencing every standard, and unopened since the week they were approved, while the actual project shipped whatever survived the deadline. So this is not a post about writing a quality plan. It is about writing one that is still in use in month four. Mine fits on a page and has five parts.
Standards, as numbers, tied to what the project actually is
The first section answers: what must be true of the deliverable for it to be acceptable? Not "high performance" but "checkout completes under two seconds at expected peak." Not "reliable sync" but "zero orders lost between systems, verified by daily reconciliation." Every standard that cannot be phrased with a number or a binary check gets rewritten until it can, or deleted as decoration.
The standards come from three places, in priority order: what the requirements demand, what the platform or regulator imposes, and what past incidents taught. That last source is underrated. If the previous release burned you with a data mismatch, the standard preventing its recurrence belongs in this section by name. My best quality standards are scar tissue with a metric attached.
Measurements with owners and moments
A standard without a measurement plan is a hope. For each standard, one line: how it is checked, by whom, at what moment. "Reconciliation report, generated nightly, reviewed by ops lead each morning." "Load test, run against staging, before each release candidate." The owner matters more than the tool; a check that is everyone's job runs zero times.
The definition of done, wired into daily work
The plan's most load-bearing part is the smallest: what "done" means for a unit of work. Reviewed, tested, documented, deployed to staging, whatever the team commits to, written once and enforced in the tracker. This is where the quality plan stops being a document and becomes behavior, because it executes forty times a sprint without anyone opening a file. If I can only defend one section under pressure, it is this one.
Tools and techniques, chosen for the failure modes you expect
Checklists for release steps that have burned you. Automated tests where regressions are likely and manual checking is soul-destroying. Peer review depth matched to risk: a config change and a payment flow change do not deserve the same scrutiny. The plan names which technique guards which risk, so when someone proposes skipping a step, the conversation is about accepting a named risk, not about whether the step was ever real.
The review rhythm, because plans rot
Quality plans decay the way risk registers do, which I wrote about in Why Projects Fail: filled once, trusted forever. The last section is a standing appointment, fifteen minutes monthly, three questions. Did any check fail silently? Did we learn a new failure mode that deserves a standard? Is any check now theater, run but never acted on? Checks that became theater get deleted in that meeting. A short list that is all real outranks a long list that is half ceremony.
The test of a good quality plan
Same test as for any plan: what happens under pressure. In a crunch week, a working quality plan is the thing the team points to when someone suggests cutting corners, "that's a named standard, cutting it is a decision, who signs it?" A failed one is the thing nobody remembers exists. Keep it to a page, make every line executable, give every check an owner, and prune it monthly, and it has a fighting chance of being the first kind.
Nguyễn Hải Nam
Project Management Lead. 16+ years from code to delivery. PMP®. Writing here about project management and engineering.