Quality Is Designed In, Not Inspected In

Most projects that hand over disappointing work do not skip their checks. The test cycles run, the review meetings happen, the inspection is signed off, and the deliverable still arrives needing weeks of correction. The checking was real enough. It simply took place at the point where the quality of the work had already been settled, and an inspection at that stage can only report what you have.

Embedding quality into processes and deliverables means moving the decisive work earlier: agreeing what an acceptable result looks like while the work is still being shaped, choosing methods and standards capable of producing it, and designing feedback into the workflow so that problems surface while they remain cheap to put right. Inspection still matters. The question is whether it confirms something you had good reason to expect, or discovers it.

Quality is decided before anyone looks at the result

By the time a deliverable reaches a formal check, its quality is already fixed. The check observes; it does not create. The decisions that set the outcome came earlier and were usually less visible: how clearly the underlying need was understood and written down, what acceptance criteria were agreed and with whom, which standards or regulatory requirements apply and whether the team knows how to meet them, how the work was sequenced so that later activity does not build on unverified foundations, who had the competence to do it, and what review points sat inside the work rather than at its end.

That list is where a project manager has real leverage, and it is also where attention tends to be thinnest, because none of it produces a visible deliverable. Cost of quality thinking makes the trade clearer. Money spent on prevention and on appraisal sits on one side; money spent putting failures right sits on the other, and failures found after handover cost far more than rework caught during the work. A team that consistently finds a large number of defects in final testing is producing information about its own process as much as about its product.

This is the substance of Section 3.5 of The Standard for Project Management, which treats quality as something built into the way work is performed as well as into what is delivered. The practical translation is that the quality plan is a statement about how the team will work, not a schedule of checkpoints.

Assurance and control answer different questions

One question is whether the way we are working is capable of producing an acceptable result. The other is whether this particular output is acceptable. Assurance addresses the first, control the second, and neither can stand in for the other. Where assurance is treated as paperwork, the project ends up relying entirely on final inspection to catch everything. Where control is neglected in favour of confidence in the process, output can drift for a long time before anyone notices.

The practical consequence is that a failed check deserves two responses rather than one. Fix the output, then ask what allowed it to travel that far unchallenged. Sometimes the honest answer is that this was genuinely a one-off and the process is sound. The problem is not reaching that conclusion, it is never asking the question.

For a PMP candidate, the useful habit is to work out which of those two questions a scenario is asking before selecting an action. Preparation material can reduce this to a pair of definitions, which is enough for a terminology question and thin for a situational one. The Process domain of the current Examination Content Outline includes a task on planning and optimising the quality of products and deliverables, with enablers running from gathering quality requirements through executing the quality plan, managing cost of quality and conducting quality reviews to continuous improvement. The span of that task is the point. A candidate is expected to reason across the whole of it rather than recall where inspection belongs.

A migration that passed every test

A financial services firm is replacing a legacy policy administration system. The migration team builds a careful set of checks: record counts reconcile between source and target, mandatory fields are populated, no rows are rejected. Three rehearsal runs pass cleanly. On the Friday of the switchover weekend, the reconciliation report is green across the board.

On the Monday, the servicing team cannot work a case properly. Addresses have loaded with the second line sitting in the county field, which the checks accepted because the field contained data. Historical premium adjustments arrived without the free-text notes explaining why they were made, because notes were never in the mandatory set. Nothing failed. Every test measured whether the migration had run as designed, and the design had been specified and approved by the people building it.

The decision that produced that Monday was taken months earlier, when acceptance criteria were written as technical completion rather than as the ability of a servicing colleague to handle a live case. Embedding quality here would not have meant more tests. It would have meant someone from servicing sitting with a sample of migrated records early enough to say that a populated field is not the same as a correct one, and one rehearsal in which a handful of real cases were worked through from start to finish rather than counted.

Designing it in when requirements are still moving

Predictive delivery has well-established mechanisms for this, and they work when they are used as intended rather than as evidence. Requirements are specified to a standard the team can actually build against, review points are placed inside the schedule where they can still change something, quality expectations are written into supplier agreements before award rather than argued afterwards, and configuration control keeps the thing being inspected the same as the thing that was approved.

Adaptive delivery relies on different mechanisms towards the same end. A definition of done pins acceptance before the work starts rather than after it. Automated checks and peer review pull defect discovery into the iteration. Refinement conversations are where ambiguity gets removed, and retrospectives are the place where the process itself is adjusted. An iterative team without an agreed definition of done is still inspecting at the end, just more often and with less time to react.

Hybrid work usually has to satisfy a regulator or an assurance function with evidence while building the solution iteratively. That is workable when the evidence requirement is understood at the start and produced as the work proceeds. It becomes painful when the team builds for months and then tries to reconstruct a quality record from memory and commit messages. Deciding which question a live situation is asking, and which of the upstream decisions you can still influence, is the sort of judgement that structured PMP® Exam Preparation develops through realistic project situations rather than through definitions.

On a real project the payoff is not philosophical. Acceptance criteria written with the people who will live with the result cut the volume of late change requests. Feedback designed into the workflow moves rework to the point where it costs days instead of quarters. A governance conversation supported by evidence from the work itself is a different conversation from one supported by an assurance that testing is scheduled for next month. None of that removes the final check. It changes what the final check is for.

Andre Malowney

Interested in going further?

Quality questions on the exam and on live projects both turn on the same thing: recognising, in a specific situation, whether the process or the output is what needs attention. Omega's PMP® Exam Preparation works through that judgement using realistic delivery situations across predictive, adaptive and hybrid contexts.

The principle behind designing quality into the work, rather than inspecting for it afterwards, is set out in the PMBOK® Guide Eighth Edition and The Standard for Project Management.

Ad · Amazon affiliate link.

References

A065: Choose the Approach Around the Deliverable
A081: Tailoring Processes Without Losing Discipline
A018: Policies, Processes and Procedures: When Each Matters
A007: The Standard for Project Management vs the PMBOK Guide
A008: Why Processes Came Back in PMBOK 8

PMP and PMBOK are registered marks of the Project Management Institute, Inc.