Quality management examples: six failures and the fixes that actually held

A quality failure is rarely about the defect. It is about the distance between where the problem was created and where someone noticed it, and why nothing in between caught it.

Six examples follow. Each names the tool or standard that carries the fix, so you can look it up rather than take my word for it.

What to take away

One: invoices wrong once a month

An accounts team issued about four hundred invoices a month and got roughly four back disputed. Each dispute took a couple of hours to unpick. The proposed fix, a second checker on every invoice, would have cost days a month to prevent eight hours of rework.

Sorting the disputes by cause showed all four involved a customer with more than one delivery address, picked from a dropdown where the entries looked nearly identical. Nobody was careless. The interface made two options look the same.

What held was reordering the dropdown so the most recently used address came first, and putting the site name next to the street. The second checker was never hired. This is the poka-yoke pattern: make the error hard to make rather than easy to catch.

Two: the report that was late and always right

A monthly report landed three days late, every month. Nobody treated it as a quality problem because the content was never wrong.

Watching the work showed the analyst spent two days chasing three inputs from other teams, each in a different format, each needing manual reshaping. The report itself took half a day.

Automating the reshaping would have removed one of those two days. Agreeing a fixed format with the three upstream teams removed both, cost one conversation each, and fixed the same problem for two other people reshaping the same data privately.

Value stream mapping lays out the path, handoffs, and waiting so a team can see where inputs stall.

The general point about counting handoffs rather than steps is in operating processes.

Three: the defect that only happened on Mondays

A production step produced an out-of-tolerance result about twice a week with no visible pattern. Each investigation produced a plausible explanation, and none repeated.

Plotting the results in time order instead of reading them as a list changed the picture. Failures clustered at the start of shifts after a break in running. The cause was a warm-up effect nobody had characterized, because the equipment had always been treated as either working or broken.

The fix was a defined warm-up and a first-piece check. Obvious in hindsight, invisible while every case was investigated alone. Telling ordinary noise from a real pattern is the subject of quality management framework.

A run chart is the direct tool for this diagnosis: it plots results in time order to reveal patterns. Where the process and data support calculated limits, statistical process control (SPC) charts can help distinguish routine variation from signals that merit investigation.

Four: the checklist everyone completed and nobody used

A team introduced a pre-release checklist after a bad incident. A year later the checklist was completed on every release, and a very similar incident happened again.

Reading the completed checklists showed the pattern. Items were ticked in a block at the end, after the release, by the person who did the release. It had become a record rather than a control.

Two changes fixed it. The list was cut from twenty-two items to six, keeping only the ones whose wrong answer would stop a release. And it was run by a second person at a defined pause before the release, not after.

This is a do-confirm checklist: the work is done, then the critical items are confirmed at a defined release gate. Keeping it short and tied to a stop decision makes it a control rather than a record.

Neither change added time. The twenty-two item version cost more and did less. The design distinction underneath is in quality management checklist.

Five: the supplier whose quality collapsed without warning

An input arrived acceptable for two years and then did not. The immediate response was to inspect every incoming batch, which caught the bad material and added delay to everything.

The useful question was why the supplier had not known first. They had. Their own measurements drifted for months before anything crossed a rejection threshold, and nothing in the arrangement gave them a reason to mention drift.

What changed was asking for their process data rather than their pass rate, and agreeing that a trend would be reported before it became a failure. Incoming inspection was reduced, not expanded. This is detection lag, the same problem as an internal process with a long feedback loop.

A supplier quality agreement can formalize this approach by specifying which process data the supplier shares and when drift must be reported, rather than relying only on pass-or-fail results.

Six: the improvement that made throughput worse

A team was told one step was the slowest, so they optimized it and doubled its speed. Total output did not move, and the queue in front of the next step grew.

The step they improved was not the constraint. Work arrived faster at a downstream step that was already the limit, so the only visible result was more work in progress and longer waiting. Speeding up a step that is not the constraint converts effort into inventory, which is the argument in productivity systems.

Two habits prevent it. Find the constraint before optimizing anything, which usually means looking for piled-up work rather than asking who is busiest. And when someone reports an improvement, ask what happened to the total, not to the step. The reading discipline for improvement claims is in operations case studies.

This is the Theory of Constraints: identify the system's limiting step before improving local speed, then manage work around that constraint. The example shows how a non-constraint improvement can create inventory rather than throughput.

A worked example: the five whys, done properly

The five whys is a Taiichi Ohno technique from Toyota Production System practice, and it is the most misused tool in the set. The failure mode is stopping at the first answer that sounds like a cause, which is usually a person.

Run it against example four, the checklist that became a record:

Stop at step two and you get "the operator was careless," which is wrong and fixes nothing. The fix sits at steps three and five, and it is a design change, not a discipline talk. Formal treatments of this reasoning sit under root cause analysis.

What the six have in common

None of the causes were the person doing the work. In four of the six, the first proposed fix was another inspection.

The cost of a defect is mostly set by how far it travels before someone notices, so detection lag deserves as much attention as prevention. The second question, why nothing caught it, yields different and often cheaper answers than the first.

These examples describe operating controls, not a certification claim. ISO 9001 is a quality-management-system standard that sets requirements for a quality management system; it does not prescribe these specific fixes.

Common questions

How do I tell whether a failure is worth investigating at all?

Ask whether you expect it to recur and whether you would find out if it did. A one-off with a visible cause and no recurrence mechanism can be fixed and forgotten. Anything you would not detect a second time deserves attention regardless of how mild this instance was.

Our failures never look this tidy. Is that normal?

Yes. These are written backwards from a known answer, which is the distortion to watch for when reading any worked example, including this one. Real investigations spend most of their time on hypotheses that turn out wrong, and that part is missing from every write-up ever published.

Should we investigate every defect?

No, and trying produces a backlog that discredits the practice. Investigate patterns, anything with a severe consequence, and anything you did not detect yourself. Log the rest so patterns can be seen later, which requires only that somebody records them in one place with enough detail to group.

Who should run the investigation?

Someone close enough to understand the work and far enough not to be defending a decision. Where those cannot be combined, use two people. The worst arrangement is an investigation run by the person whose choice is under examination, because they will be honest and nobody will believe them.