From symptom to cause

The customer complaint came in on a Tuesday: a product batch out of spec. The report was closed in four days with a tidy root cause —"operator error"— and a corrective action: retrain the staff. File closed, indicator green.

Three months later the same defect reappears. Another shift, another operator, the same training that was never scheduled. No one had looked at the data in plain sight from day one: in the Pareto of complaints, the defect was concentrated, almost entirely, on the night shift. It wasn't the person. It was the line's start-up setup, badly adjusted since the shift change. The five whys never went down to the plant floor; they were filled in a room, from the memory of whoever wrote the report.

The scene is composite —it repeats, with variations, in any operation in the region—, but the logic is exact. And it probably sounds familiar.

In the first installment of this series we saw why the system rewards fighting fires and not preventing them. This is the sequel: what happens when someone does try to genuinely solve —and still fails.

The complaint was closed. The question is whether the problem was solved.

To understand it, we have to start with the most famous and worst-used of the quality tools.

The poster no one fills in

In almost any quality room there's an immaculate poster: the five whys, in five boxes, framed. Everyone glances at it on the way to the coffee machine. Almost no one remembers the last time it was filled in with real data. It's used, when it's used, to close fast: you drill down to "lack of attention" or "operator error", you sign, and the closed-complaints indicator ticks up by one.

The myth behind that habit is simple and recited from memory in any quality committee: asking "why" five times leads, almost by design, to the root cause. The tool comes from the production line, from Taiichi Ohno's insistence on not settling for the first explanation of a failure. That origin is real and worth reclaiming: it isn't a consultant's cliché, it's a shop-floor tool.

The problem isn't what Ohno invented. It's what was done with it afterward.

In 2017, a review published in BMJ Quality & Safety was scathing about the way the five whys are used in practice. Different people, facing the same incident, arrive at different root causes. The depth at which the fifth why stops is arbitrary —why five and not seven?—. And the method pushes, almost by structure, toward settling on a single cause when most complex problems have several. Its popularity, the review concludes, doesn't come from working better than the alternatives: it comes from being simple, fast and fitting inside a laminated box.

None of those failings is in the tool. They're in where and how it's used: in a meeting room and from memory, not at the place of the facts and with data.

Desk 5 Whys vs. gemba 5 Whys

Here is the heart of the difference between amateur and professional analysis, and there's nothing esoteric about it: it's a matter of verifying every link of the causal chain with data, at the place where the work happens —the gemba, in Toyota's vocabulary—, instead of reconstructing it from memory in an air-conditioned room.

The rule Toyota demands of this kind of analysis is simple to state and hard to meet. The root cause has to explain all the data of the current state, not just the specific case that prompted the meeting. If the defect appears only on the night shift, "operator error" can't be the root cause: it doesn't explain why the morning shift, with different operators and the same training, doesn't have the same problem. A cause that doesn't explain the full pattern isn't a cause: it's a conjecture in the shape of a conclusion.

Go back to the complaint at the start. The Pareto was built, someone had printed and filed it next to the report. It showed, unambiguously, that 80% of the out-of-spec units came from a single shift. No one cross-checked that data against the cause about to be signed. Had they done so, the next question wouldn't have been "who made the mistake?" but "what's different about that shift?". The start-up setup, the absence of a second check, the rotation of a less senior supervisor. That's the fifth why that actually matters, and the one almost never asked because it means leaving the room.

This connects with something this firm has written about metrics: sometimes the mis-diagnosed problem is nothing more than a badly chosen indicator. We saw it when we discussed why metrics get corrupted: if the dashboard measures "closed complaints" instead of "complaints that don't recur", the whole system pushes toward the fast close, not the right cause.

But even the best cause analysis is wasted if it starts from a badly framed problem. And there almost everyone fails, much further upstream in the process than they imagine.

The problem statement almost no one writes

Before asking why, you have to be able to write precisely what.

As Dwayne Spradlin wrote in Harvard Business Review in 2012, the rigor with which an organization defines the problem is what weighs most when it comes to finding a good solution. Most companies aren't rigorous enough at that step and, because of it, end up investing resources in solving something that wasn't the real problem. It's the same principle this firm has worked on the capital-projects side: the front-end loading we covered in investment governance. Cheap definition prevents the expensive correction, whether in an industrial plant or an US$18 million project.

What does a well-written problem statement look like in practice? Nelson Repenning and colleagues, in a 2017 MIT Sloan Management Review article, propose five conditions that are rarely all met together:

With the problem well framed and the cause verified at the gemba, the skeleton of a complete routine begins to show. At 32sur we gave it a name.

The Closed Loop: the four stations

We call this method The Closed Loop, and it has four stations, not three loose steps or one more poster for the wall.

Frame. The problem is written with the five conditions from the previous section. Define, don't diagnose.

Verify. The cause is tested at the gemba, with data, and must explain one hundred percent of the available facts —not just the case that prompted the meeting.

Solve. The countermeasure is assigned to an owner with a full name, and a date. Not a generic training "for the team", not a memo that circulates and gets filed.

Close. You measure whether the problem happened again —the recurrence rate— and run a short debrief that records what was learned. This last station is the one almost no one installs as a routine, and it's so decisive that we'll devote the whole next installment to it.

The method's signature, what sets it apart from any training workshop: the loop only closes when you measure that the problem didn't come back. Not when the report is signed.

Each station calls for a different tool depending on the type of problem, and that's where teams go wrong most: they use the same tool for everything because it's the one they know.

If you lead and don't execute, you don't need to memorize the table that follows —your quality people do—. It's enough for you to demand that this criterion exist.

Charles Conn and Robert McLean sum it up bluntly in Bulletproof Problem Solving (Wiley, 2019): systematic problem-solving "isn't taught in most universities or business schools". It's learned as a craft —with logic trees, explicit hypotheses and a tool chosen on purpose—, not by inspiration or from the poster stuck on the wall for five years.

All of this can sound like added cost: more steps, more discipline, more meetings. It's worth looking at the other side of the counter.

What not having a root cause costs

There's a factory that appears on no org chart and that almost no company measures: the one devoted, every day, to reworking what came out wrong the first time. Rework, scrap, re-inspection, returns, and in the worst case, a recall. Quality specialists call it, rightly, the hidden factory.

The cost of poor quality usually sits, per industry estimates compiled by the American Society for Quality, around 15-20% of revenue in plants that have never measured it. In those operating with world-class discipline, it drops below 5%. It's an indicative figure, not an academic study with a controlled sample; what matters is the gap: between not measuring it and measuring it there are, at minimum, ten points of revenue in difference.

That cost isn't abstract. In a machining plant in the region, the customer reject rate jumped from a target of 0.9% to 1.57%: 4,933 defective parts and a loss of nearly 34,500 dollars in a single reporting period. The initial meeting, as in the night-shift complaint, looked for a culprit. But this time the team ran a full DMAIC project —define, measure, analyze, improve, control— instead of closing with a generic training. It verified the cause on the floor, validated it against production data and only then defined the countermeasure. The process returned to the 0.9% target.

The difference between that case and the opening complaint isn't the industry or the size of the company. It's that someone demanded the cause explain the data before signing the close.

And does it really work, beyond one specific plant? There's a documented case that shows it with concrete numbers.

The proof: the refinery that stopped patching

In a case documented by MIT Sloan Management Review in 2017, a refinery had been operating in permanent firefighting mode. Procurement was piling up supplier-payment delays that put it on the verge of losing credit lines, and each week was a succession of improvised fixes to keep the plant from stopping. The team replaced that way of working with structured problem-solving —the very elements of this method: a problem framed with data, a verified cause, a countermeasure with an owner. The result was measurable: on-time supplier payments went from crisis levels to more than 90%. On top of that, the area freed up two roles previously devoted full-time to putting out that particular fire.

The proper caveat applies: it's a documented case, not an industry average. But it's exactly the kind of evidence that separates "sounds reasonable" from "proven to work".

The phrases that close the file

"We already do the five whys." Good —in the room or on the floor? Does the cause you wrote down explain all the data —the shifts, the lines, the batches— or just the one case in front of you that day?

"We hired a consultancy that left us the methodology." The methodology is almost never the problem. It's used well by whoever goes to the gemba and verifies every link with data; the rest hang it on the wall, next to the five-whys poster, and keep closing complaints with "operator error".

Back to the night shift

The opening complaint was closed in four days. The indicator turned green. And the defect came back, three months later, on the same shift, with another operator carrying blame that wasn't his. The method to prevent it already existed inside the company —the Pareto was printed, filed, a click away— but it never came down from the meeting room to the production line.

Now suppose your company does all this well. It frames the problem rigorously, verifies the cause at the gemba, solves with an owner and a date. There's still one last trap, and it's the most expensive of the three you'll meet in this series. The method applied well just once is not an installed capability. A systematic review of 21 root-cause-analysis studies found that only two showed a real improvement, and that in half the cases the recommendations weren't enough to keep the problem from happening again.

In the final installment of this series: how the loop is installed so it truly doesn't come back —who has to be the owner, what cadence sustains it and which single metric almost no one in the region measures yet.