Quality management: a source-based guide for 2027

Quality problems almost never announce themselves as quality problems. They arrive as a customer complaint, a late shipment, an argument about whether something was in scope, or a rise in support volume that nobody can explain. By the time anyone calls it a quality issue, the interesting part, the point where it was cheap to prevent, is months behind you.

This page is about the reasoning, not the certification. If you need to meet a formal standard, read the current text of that standard rather than any summary; the requirements are revised periodically and the details matter.

What to take away

• A specification is useful when a person who was not in the conversation can decide, without asking, whether the thing passes.
• The standard exercise, ask why repeatedly until you reach a cause, is useful and easy to perform badly.
• Customer complaints have one enormous advantage: they are free and they arrive without being asked for.
• Where checking every item is impractical, you check some of them.

Quality is a definition problem before it is an inspection problem

"Is this good?" is unanswerable. "Does this meet what we said it would do?" is answerable, and the difference between those two questions is where most quality arguments actually live.

Conformance quality asks whether the output matches its specification. Fitness for purpose asks whether the specification was the right one. Both are real, and confusing them wastes enormous effort: teams inspect harder and harder against a specification that does not describe what the customer needs, and the defect rate improves while the complaints do not.

A test you can apply today. Take your last five customer complaints and sort them:

• The output did not meet the spec. That is a conformance problem: look at the process.
• The output met the spec and the customer was still unhappy. That is a specification problem: the process is working fine and is aimed at the wrong target.
• Nobody can tell, because there is no spec precise enough to judge against. That is the most common answer and the most important one.

If most of your complaints land in the third bucket, no amount of process improvement will help until you fix the definitions. You cannot control what you have not defined.

Writing a specification someone can actually check

A specification is useful when a person who was not in the conversation can decide, without asking, whether the thing passes.

That means avoiding the words that feel like requirements and are not: quickly, reliable, user-friendly, professional, high quality, as needed, where appropriate. Each of these transfers the judgment to whoever is inspecting, which means the answer changes depending on who looks.

Three properties to check:

Observable. Stated in terms of something you can see, measure, count, or test. "Responsive support" becomes a stated response time. "Clean" becomes a defined condition with a way of assessing it.

Bounded. Says what is out of scope as well as in. Most scope disputes are about something nobody thought to exclude.

Agreed by both sides of the handoff. A specification written by the requester and never read by the producer is a wish. One written by the producer and never seen by the requester is a description of what they were going to do anyway.

Where genuine judgment is unavoidable (design work, writing, anything aesthetic), do not fake precision. Name the person whose judgment decides, and say so in the specification. "Approved by the design lead" is a real acceptance criterion. A list of adjectives is not.

Where defects are cheapest to catch

The general shape of this is uncontroversial and worth taking seriously: a problem caught at its origin costs less to fix than the same problem caught downstream, and the cost rises the further it travels. A misunderstanding caught in a requirements conversation is a five-minute discussion. The same misunderstanding caught after delivery involves rework, an unhappy customer, possibly a credit, and the time of several people who had moved on to other things.

You do not need anyone's published multiplier to act on this. You can work out your own approximation: take three recent defects that reached a customer, and add up the hours actually spent on each, investigation, fix, retest, communication, and the management attention. Compare with what it would have cost to catch each at the point it was introduced. The exercise is more persuasive to your own organization than any external figure, because the numbers are yours.

What follows from it: inspection at the end is the most expensive place to find things, and it is where most organizations concentrate their quality effort, because it is the easiest place to add a step. The cheaper interventions are further upstream and less visible, clearer specifications, better handoff information, a check by the person who created the work before it moves.

Inspection has limits worth knowing about

Two things are true about checking work at the end, and both are inconvenient.

Inspection is not fully reliable. People miss defects, especially in repetitive checking, especially when the defect rate is low and attention drifts. Doubling the number of inspectors does not double detection; some of the misses are systematic: the check does not look for that failure mode at all.

Inspection does not improve anything by itself. It sorts good from bad. If the process producing the work is unchanged, you get the same defect rate forever and pay for the sorting indefinitely.

This is not an argument against checking things. It is an argument against treating a final check as your quality system. Use inspection to find out what your process is doing, then act on what you find. If you inspect and never feed anything back upstream, you have built a filter, not a quality function.

Where you do inspect, a few things help: have someone other than the producer do it where practical, since people are poor at seeing their own errors; give the checker a specific list rather than asking them to look for problems generally; and check the checking occasionally, by seeding a known defect or reviewing what got through.

Root cause analysis that is not theater

The standard exercise, ask why repeatedly until you reach a cause, is useful and easy to perform badly. It is usually taught as five whys, and the failure mode is a chain that terminates at "human error" or "insufficient training," which are places to stop rather than answers.

Some discipline that helps:

Stop at something you can change. If the cause is "the operator was distracted," keep going: why was distraction possible at that step, and what would make the error impossible or immediately visible instead?

Distinguish the cause of the defect from the cause of the escape. Two separate questions, two separate fixes. Why did it happen, and why did nobody catch it before it reached the customer? Organizations routinely fix the first and are surprised when a different defect escapes the same way.

Prefer changes that do not depend on vigilance. "Be more careful" is not a countermeasure. Making the wrong action difficult, making the right one the default, or making the error visible immediately are countermeasures, because they keep working on a bad day. Designing the work so the mistake cannot be made is old practice with a name: poka-yoke.

Check whether the cause explains the pattern. If your cause is correct, it should also explain why this did not happen last month, and why it happens on some units and not others. A cause that would predict constant failure, applied to an intermittent problem, is not the cause.

Write down what you expect the fix to do. Then look. A large share of corrective actions are never verified, and some of them made things worse. Writing the condition that would send you back before anyone is attached to the outcome is the same habit that keeps a plan honest, and it is in strategic planning.

Complaints are your cheapest source of data, and the most distorted

Customer complaints have one enormous advantage: they are free and they arrive without being asked for. They also have a specific bias that will mislead you if you ignore it. Only a fraction of dissatisfied customers complain, and the ones who do are not a random sample, they are disproportionately the engaged, the confident, and those with a big enough problem to justify the effort. Silence is not satisfaction; it frequently means the customer has quietly gone elsewhere.

Some practical handling:

Separate the incident from the pattern. Every complaint needs a response for that customer. Only patterns justify changing the process. Reacting to single incidents with process changes produces an accumulating pile of controls, each added for a reason nobody remembers.

Categorize by cause, not by symptom. "Late delivery" is a symptom with several distinct causes; grouping them together hides all of them.

Count the ones that were resolved easily too. A problem that support fixes in two minutes, forty times a week, is invisible in escalation reporting and is a real defect.

Look for the complaints that did not come. Ask a few customers who have not complained. The gap between that and your complaint log is a measure of how much you are not seeing.

Checking a sample instead of everything

Where checking every item is impractical, you check some of them. The reasoning that makes this useful, rather than reassuring, is worth being clear about.

A sample tells you about the population it was drawn from, and only if it was drawn without bias. The most common mistake is not sample size, it is sampling whatever is convenient: the first items of the batch, the ones from the accessible machine, the work of whoever is around. Convenient samples systematically miss the conditions that produce defects, which are frequently the unusual conditions.

Some practical guidance:

Decide what the sample is for. Estimating an overall rate, catching a shift in the process, or screening out bad units are three different purposes with different designs. Screening in particular is poorly served by sampling, because a sample that passes says nothing definite about the units you did not check.

Sample across the sources of variation. Different shifts, machines, people, suppliers, times of day. If you only sample one, you learn about one.

Rarer problems need more looking. A defect occurring in a small fraction of items will simply be absent from a small sample most of the time, and its absence is not evidence.

Record what you checked, not only what you found. Zero defects in a sample of ten and zero in a sample of a thousand are very different results and look identical if you only write down the finding.

Where the consequence of a defect is severe, sampling is usually the wrong instrument entirely, and the answer is prevention or full inspection. If a regulation or contract specifies how sampling must be done in your context, follow that rather than any general guidance.

Quality in work you do not control

Where part of your output comes from a supplier, a subcontractor, or an outsourced function, your quality problems become partly theirs, and the usual response, checking their work harder on arrival, has all the limits of inspection plus a delay.

Things that work better:

Agree what "acceptable" means in writing, in their terms. Most supplier quality disputes are specification disputes discovered late. If the spec cannot be checked without the supplier's cooperation, that is worth knowing before you sign.

Ask how they will know before you do. A supplier with their own detection will tell you about a problem. One relying on your incoming inspection will send it, and both of you find out downstream.

Decide what happens when something fails, including who pays for the consequences. Vague arrangements get settled by whoever has more bargaining power at the time.

Look at their process occasionally, not just their output. A supplier whose output is currently fine and whose process is unstable will fail eventually, and you would rather know first.

Give feedback in a form they can act on. "Quality has been poor" changes nothing. Specific defects with dates and quantities does.

Reducing variation between people doing the same job

Where several people perform the same task and produce different results, some of that difference is skill and some is method, and the method part is recoverable at no cost.

The approach is straightforward and rarely done. Find out how each person actually does it, by watching rather than asking, which is the same first move as in any process investigation and is set out in operating processes. Identify where they diverge. For each divergence, work out whether one way is better, whether it depends on circumstances, or whether it genuinely does not matter. Then agree the better way and make it the default.

Two cautions. Do not standardize on the manager's preference or on the loudest person's method; standardize on what produces the better result, and be willing to find out that it is not the way you would have done it. Handling a disagreement between two capable people who both work for you is covered in team management. And leave the judgment parts alone: standardizing something that requires adaptation produces either bad output or a rule everyone ignores.

The people doing the work should agree the standard, not receive it. A method imposed from outside gets followed while observed. Holding a standard once it is agreed, including when that is unpopular, is one of the obligations described in management foundations.

Deciding where to put your quality effort

You cannot prevent everything, and trying produces a control-heavy operation that is slow and still fails in new ways. The allocation question is worth making explicit.

For any given failure mode, three things matter: how often it happens, how bad it is when it does, and whether you would find out. That third one is routinely underweighted. A failure that is rare and severe but immediately visible is often less dangerous than one that is frequent, mild, and undetected, because the undetected one accumulates.

A rough working order:

1. Failures that harm people, breach a legal or regulatory obligation, or destroy data. These get controlled regardless of frequency, and if there is any regulatory dimension, take proper advice on what is required in your jurisdiction rather than deciding internally.
2. Failures you would not detect. Add detection before you add prevention; you cannot manage what you cannot see.
3. Frequent failures with moderate cost. Usually the biggest total drain, and usually normalized into "how it is."
4. Rare, visible, recoverable failures. Often correctly left alone. Accepting a known failure mode deliberately is a legitimate decision, provided it is recorded as a decision rather than an oversight.

Building quality into the work rather than around it

The most durable quality improvements are the ones that change the work itself, not the checking of it. A few patterns that generalize:

Make the defect impossible. A field that will not accept an invalid value, a fitting that only goes in one way, a form that cannot be submitted incomplete. This is always better than a rule telling people to be careful.

Make the defect visible immediately. If the error surfaces at the step where it is created, the person who made it fixes it in seconds with full context. If it surfaces three steps later, it costs an investigation.

Give people the authority to stop. If the person closest to the work can see something is wrong but cannot halt it without permission from someone unavailable, the work continues. This one is a management decision, not a process design, and it is the one most often withheld.

Reduce the number of ways to do it. Variation in method produces variation in output. Where several people do the same task differently and one way is better, the gap between them is free improvement.

Common questions

Do we need a formal quality management system?

Depends on whether a customer, regulator, or contract requires one. Certification proves the existence of a system, not the quality of the output: those are correlated but not the same, and organizations do achieve certification while their customers remain unhappy. If you are pursuing it for commercial reasons, be clear that is the reason, and keep the underlying work honest regardless.

How do we measure quality without gaming it?

Use at least one measure that comes from outside your own process (customer-reported problems, returns, escalations), alongside your internal ones. Internal defect counts fall when reporting defects becomes uncomfortable, and the external measure will not move with them. Diverging internal and external measures is a signal worth investigating rather than explaining away.

Who should own quality?

The work owns quality; a quality function owns the method, the measurement, and the awkward question. Where a separate department owns quality outright, everyone else gradually stops feeling responsible for it, and the department becomes an inspection bottleneck that people route around.

What is the first thing to do in an organization with no quality practice at all?

Start recording what goes wrong, in one place, with enough detail to categorize later. Do not design a system yet. After a couple of months you will have a picture of your actual failure modes, and it will be different from what everyone assumed, which is worth knowing before you spend anything on fixing them.