16.1 Quality Planning, Indicators and the Business Case
Key Takeaways
- Quality planning decides what "fit for purpose" means for this project, and how conformance will be demonstrated.
- Quality indicators make quality measurable, converting a general aspiration into a testable acceptance threshold.
- Quality requirements must trace back to the business case: over-specification spends money the benefits do not justify.
- Under-specification is equally a business-case failure, because outputs that do not perform cannot deliver the promised benefits.
- Quality planning happens early — it defines what will be built and tested, so it cannot be retrofitted at acceptance.
Why quality management matters on the APM PMQ
Quality management ensures project outputs are fit for the purpose defined by requirements and success criteria — and therefore capable of enabling the benefits assumed in the business case. Learning objective 18 — Quality management expects you to explain quality planning, quality indicators, their relation to the business case, and quality control techniques used to determine whether success criteria are met.
Weak answers reduce quality to "test at the end." Strong answers show quality planned into the work, measured with indicators, controlled with appropriate techniques, and governed because failed quality destroys benefits, reputation, and sometimes safety.
High-yield triad (keep distinctions clean):
- Quality planning — decide what quality means here and how it will be achieved and evidenced.
- Quality control (QC) — check products/outputs against criteria (inspection, test, review, sampling).
- Quality assurance (QA) — provide confidence that processes and systems for quality are appropriate and are being followed (often including independent review of the management system, not only the product).
Quality planning
Quality planning defines the standards, criteria, methods, responsibilities, and resources needed to achieve the required quality. It answers: What does good look like, how will we build it in, and how will we know?
Typical contents of quality planning
| Planning element | What it covers | Why it matters |
|---|---|---|
| Quality standards and policies | Organisational standards, ISO-aligned practices, sector regulations, professional codes | Sets the mandatory bar |
| Requirements-derived criteria | Acceptance criteria traced to baselined requirements | Makes "done" objective |
| Success criteria measures | Project-level definitions of success linked to objectives | Connects delivery to intended outcomes |
| Quality indicators / metrics | Leading and lagging measures of quality performance | Enables monitoring before crisis |
| Methods and techniques | Reviews, tests, inspections, sampling plans, audits | Fits control intensity to risk |
| Roles and responsibilities | Who builds quality in, who checks, who accepts | Prevents "everyone and no one" owns quality |
| Timing in the life cycle | When verification occurs (phase gates, increments, handover) | Avoids end-loaded defect discovery |
| Supplier quality expectations | Specifications, inspection rights, acceptance tests in contracts | Extends quality beyond internal teams |
| Records and evidence | What proof is retained for assurance and handover | Supports audit and transition |
| Continuous improvement | How defects and lessons feed process change | Stops repeating failures |
Quality planning is documented in a quality management plan (standalone or as part of the project management plan). It should be proportionate: a safety-critical medical device project plans denser verification than a simple internal brochure reprint — but both still need a defined "good enough" and a check.
Prevention over pure detection
Mature quality planning emphasises building quality in (clear requirements, competent people, peer review, design standards, defect prevention) rather than relying only on heroic late testing. Detection remains essential, but planning that only funds a final inspection is usually too late and too expensive.
Scenario A — no quality plan
A software integration is declared "complete" because developers said so. There are no acceptance criteria, no test plan, and no agreed defect severity rules. UAT becomes a battlefield of opinions. Quality planning would have defined criteria, environments, test responsibilities, entry/exit rules, and acceptance authority before build intensity peaked.
Quality indicators
Quality indicators are measures that show whether quality performance is on track. They operationalise planning: without indicators, "quality is fine" is a slogan.
| Indicator type | Examples | Use |
|---|---|---|
| Product / output quality | Defect density, % tests passed, inspection failure rate, rework hours, dimensional conformance | Are outputs meeting specifications? |
| Process quality | % deliverables passing first-time review, requirements stability, audit non-conformances | Is the way of working effective? |
| Supplier quality | Incoming inspection rejects, supplier defect rate, NCRs | Is external supply meeting standards? |
| User / operational quality | Escape defects after go-live, complaint rate, mean time between failures | Did quality survive transition? |
| Leading indicators | Review coverage, test preparation progress, training completion before UAT | Early warning before lagging failure |
Good indicators are measurable, timely, owned, and actionable. Vanity metrics ("number of tests written" without pass relevance) mislead. Indicators should connect to acceptance criteria and ultimately to success criteria and benefits (for example error rate reduction assumed in the business case).
Relation to the business case
Quality is not an abstract craft ideal disconnected from investment logic. The business case assumes that outputs will be sufficiently good to enable outcomes and benefits. If quality is inadequate:
- Benefits are delayed or lost (users reject the product; rework consumes funds)
- Costs rise (defect correction, warranty, claims, reputational repair)
- Risks materialise (safety incidents, regulatory breach, service outages)
- The case for continued investment weakens at gates
Conversely, gold-plated quality beyond what the case needs can destroy value through cost and delay. Quality planning should therefore target fitness for purpose aligned to the business case, not perfection for its own sake.
| Business-case element | Quality management link |
|---|---|
| Expected benefits | Quality levels needed for adoption and performance |
| Costs | Cost of conformance (planning, testing, training) vs cost of non-conformance (rework, failures) |
| Risks | Quality-related risks and residual risk after controls |
| Success criteria | Objective quality thresholds for project success |
| Options appraisal | Different options may imply different quality regimes and costs |
Scenario B — business case quality assumption
A logistics business case claims a 20% reduction in picking errors from a new WMS. That assumes scanning accuracy, training quality, and data quality meet defined thresholds. If quality control is cut to save budget and error rates stay flat, the benefits case fails even if the system "goes live." Quality indicators for scan error rates and training competence are not optional extras — they protect the investment logic.
What is the main purpose of quality planning on a project?
Which statement best links quality management to the business case?