What Is Quality Management?

Six weeks into building an appointment-booking system for a clinic, the project was late and over budget, and the retrospective had already found its villain: the testers. "We need more QA," someone said, and the room nodded. It felt right. Bugs had reached production, so the people who check for bugs must have missed something.

They were looking at the wrong end of the process.

The defect that blew the timeline was not a missed test. It was a decision nobody made. When a patient selects the 9:00 slot and spends ninety seconds entering a card, is that slot held for them, or is it still open for the next person who lands on the page? Nobody had asked. One engineer built the checkout flow assuming the slot was locked the moment it was selected. Another built the calendar view assuming a slot stayed available until payment cleared. Both were reasonable. Both passed their own tests. Together they sold the same 9:00 appointment to two different patients, and the first anyone heard of it was two people in the same waiting room.

The quality failure happened before a line of code was written, inside a question no one thought to ask. That is the thing most teams get wrong about quality management: they treat it as the inspection at the end, when it is really the discipline that runs from the first conversation to the last release.

(Developed example — composite scenario. The clinic is a realistic composite, not a specific named client; it runs through the whole article.)

Quality is fitness for purpose, not perfection

Start with what "quality" even means, because the common definition quietly sabotages everything downstream. Most people, asked to define a high-quality product, reach for words like flawless, polished, or most features. None of those is quality. Quality is fitness for purpose — how well a thing does the specific job it exists to do, for the people who depend on it.

A rugged field tool and a luxury watch are both high quality, for opposite purposes. Drop the watch on a job site and it is junk; wear the field tool to a black-tie dinner and it is wrong. Neither is "better." Each fits its purpose. The same logic separates a throwaway data-migration script from a payment system: the script can be scrappy and undocumented because it runs once and dies, while the payment system cannot, and holding both to one abstract standard of "excellence" wastes effort on one and under-protects the other.

For the clinic, fitness for purpose had a sharp, specific meaning: never sell the same slot twice. That was the standard that mattered most, more than load speed or visual polish or the number of appointment types supported. And it was never written down anywhere. It lived in everyone's head as an obvious assumption, which is to say it lived nowhere at all.

This is the first job of quality management, and it sounds almost too simple: make the purpose, and the standard it implies, explicit. Not "make it good" — good is a feeling. Name the specific properties the thing must have to do its job, in language two engineers cannot interpret in opposite directions. If you want the deeper version of this argument, we make the case in what we mean by "shift quality": quality is a property you design in, not a coat of paint you inspect on at the end.

Run this now: write down the single sentence that completes "this product has failed, no matter what else it does, if it ever ______." If you cannot finish that sentence, or two people on the team finish it differently, you have found your clinic's 9:00 slot — a purpose nobody has made explicit yet.

The four activities that make up quality management

Quality management is not one activity. It is four, and they run as a continuous loop rather than a checklist you complete once. Most teams that say "we do QA" are really doing one of the four — usually the last one — and wondering why defects keep reaching production.

Activity	The question it answers	When it acts	What the clinic skipped
Quality planning	What does "good" mean here, and what has nobody asked?	Before the work starts	Never defined "good"; never asked whether a selected slot was locked
Quality assurance	Is our process built so this class of defect can't form?	While the work happens	No shared spec, no design review of the concurrency rule
Quality control	Does the finished output meet the standard?	After the work is done	The one thing they did — but with no standard to check against
Quality improvement	What did this teach us to change upstream?	After release, continuously	No feedback loop; the lesson never reached planning

Read the last column top to bottom. That is the clinic's whole story: three empty rows and one row doing work it was never equipped to do alone. Now walk each activity, carrying the clinic with us.

1. Quality planning — decide what "good" means

Planning is where you answer the question the rest of the loop depends on: what does "good" mean here, and what has nobody asked? It is also the step almost everyone skips, because it produces no demo and feels like talking instead of building.

This is the discovery move, and it is where quality is won or lost. The double-booking bug did not live in the code — it lived in an unasked question. Good planning surfaces exactly that question before anyone commits to an implementation. A single line in a spec would have done it: "When a patient selects a slot, the slot is held for them for up to N minutes while they complete payment; if payment does not complete, the hold expires and the slot returns to the pool." Write that sentence and the two engineers cannot diverge, because the ambiguity they each resolved privately is now resolved in public, once.

Notice what planning is not. It is not writing every requirement in exhaustive detail, and it is not a document that predicts the whole project. It is the deliberate act of finding the decisions that will otherwise get made silently, by whoever touches the code first. The clinic's team was not lazy or unskilled. They simply never ran the step whose entire job is to ask "what has nobody decided yet?" This is the heart of shifting quality earlier, which we develop in shifting left: quality before code ships, and it is why the acceptance criteria you write matter so much — a well-formed criterion, as we show in acceptance criteria done right, is a planning artifact that makes "good" testable.

Run this now: take the feature you are about to build and list the decisions two competent engineers could make in opposite directions — timeouts, concurrency, what happens on failure, who wins a conflict. Each one you find is a double-booking you just prevented. Write the answer into the spec before you write the code.

2. Quality assurance — build the process so defects can't form

Assurance is about the process, not the product. Its question is: is the way we work built so this class of defect cannot form in the first place? Where planning decides what "good" means, assurance builds the guardrails that keep the team producing "good" without having to be heroic about it.

For the clinic, assurance was almost entirely absent. There was no shared specification the two engineers worked from, so each wrote to a private mental model. There was no design review at the point where the slot-holding rule got decided — the decision was never surfaced as a decision, so it was never reviewed. A lightweight QA process would have caught it structurally: a fifteen-minute design conversation about "how do we handle two people wanting the same slot?" attended by both engineers, producing one agreed rule. That conversation is cheap. The production incident that replaced it was not.

The important distinction here is that assurance prevents whole categories of defect, while control catches individual instances. A design-review step does not catch "this specific double-booking"; it catches "any place where two components share an assumption about shared state and never reconcile it." That is a far better return, because you stop paying for the same mistake in new disguises. If the boundary between these terms is still fuzzy, QA vs QC vs QE draws the lines carefully — assurance is the process, control is the check, and quality engineering is building both into how the team works.

Run this now: pick your last three production incidents and ask, for each, "what step in how we work would have made this defect impossible to form?" If the honest answer for all three is "someone would have had to catch it at the end," you have no assurance layer — you have control wearing assurance's name tag.

3. Quality control — check the output against the standard

Control is the activity everyone already recognizes as "quality." Its question is narrow and honest: does the finished output meet the standard? Testing, inspection, review of the actual thing that was built — that is control, and it is genuinely necessary. The clinic's mistake was not doing control. It was doing only control, and doing it without the standard that control exists to check against.

Here is the structural reason control could never have saved the clinic, and it is worth sitting with. Control checks output against a standard. The clinic had no explicit standard — no written rule that said "the same slot must never be sold twice." So even a diligent tester, exercising the booking flow, would have had nothing to check for. Worse, the double-booking only appears under concurrency: two sessions racing for the same slot in the same ninety-second window. A tester clicking through the flow alone, one session at a time, sees a system that works perfectly. The defect is invisible to exactly the kind of end-of-line inspection the retrospective demanded more of.

This is the trap in "we need more QA." More control cannot compensate for absent planning and assurance, because control can only find deviations from a standard that planning was supposed to set. Pile more testers onto an undefined standard and they will test more thoroughly against nothing. Control is a gate, and a gate is only as good as the rule it enforces — a point we push on in quality gates that actually gate.

Run this now: for each check in your test suite or QA pass, name the explicit standard it verifies. Any check you cannot trace back to a written standard is a check testing the tester's intuition — and intuition does not survive concurrency, edge cases, or the next person to touch the code.

4. Quality improvement — feed what you learn back into planning

Improvement is what turns the four activities from a line into a loop. Its question: what did this teach us to change upstream? When a defect escapes — and some always will — improvement asks not "who missed it?" but "what in our planning or process let this class of defect form, and how do we close that gap for good?"

The clinic never ran this step, which is why the story has no happy second act in the original telling. The double-booking got hot-fixed, the team moved on, and nothing upstream changed. The far more valuable move would have been to trace the incident back to its origin — an unasked planning question about shared state — and add exactly that to how the team plans the next feature: a standing prompt in every design kickoff that asks "where do two components share state, and who wins when they disagree?" That is improvement feeding planning. The specific bug becomes a permanent question, and the question prevents a family of future bugs the team hasn't even imagined yet.

This is why the four activities are a loop and not a pipeline. Control finds a defect, improvement diagnoses why the process allowed it, and planning absorbs the lesson so the next cycle starts smarter. A team that skips improvement pays full price for every incident and learns nothing; a team that runs it buys a permanent upgrade with each failure. The distinction between reacting to defects and engineering them out of existence is exactly the shift from quality control to quality engineering.

Run this now: take your most recent escaped defect and write the one sentence you would add to your planning checklist so that entire class of defect gets surfaced next time. If you can write it, add it today. That sentence is the difference between fixing a bug and improving a process.

What this changes about how you work

The retrospective that opened this article asked for more QA and meant more testing. Now you can see why that instinct, however reasonable, points at the wrong end of the loop. Testing is control, control is one of four activities, and control was the only one the clinic ever ran. The defect was born in planning, could have been prevented by assurance, was structurally invisible to control, and would have been permanently closed by improvement. Adding testers touches exactly none of the three activities that actually failed.

So the practical shift is this. When quality is slipping, resist the pull to inspect harder at the end, and instead ask which of the four activities your team is actually running. Most teams find they run one — control — and call it quality management. The leverage is almost always upstream, in the planning question nobody asked and the assurance step nobody built. Fitness for purpose is decided long before anyone opens the test plan.

The clinic's real lesson fits in a sentence: they did not need more people checking the output. They needed one person, at the start, to ask what "good" meant and write down the answer.

Sources

• The clinic appointment-booking scenario is a composite illustration built from common patterns in software delivery, not an account of a specific named organization or client. The mechanism it demonstrates — a concurrency assumption left undecided in planning and therefore invisible to end-of-line testing — is a widely recognized class of defect.

• The four-activity model of quality management (planning, assurance, control, improvement) reflects the long-standing structure used across quality-management practice and standards bodies; this article presents it in software-delivery terms rather than reproducing any single framework's wording.

Keep learning. This article is part of the Quality Management Fundamentals path in the ShiftQuality Learning Center.