Week 11: The 5 Whys Is the Most Misused Tool in CI
The 5 Whys Is the Most Misused Tool in CI
Everyone thinks they know how to do 5 Whys.
Almost nobody does it properly.
I know that is a bold claim. The 5 Whys is probably the most widely taught tool in Continuous Improvement. It is in every Lean training. Every Six Sigma course. Every CI introductory workshop. It is simple, intuitive, requires no statistical knowledge, and can be explained in under two minutes.
And precisely because it looks simple, people assume they know how to do it. They do not.
After 20+ years of CI practice, 40+ organisations, and training over 300 practitioners, I can tell you that the 5 Whys is the most consistently, systematically, and confidently misused tool in the entire CI toolkit. And the way it is misused reveals a much deeper problem with how most organisations think about problem solving.
The Classic Failure
Let me give you an example. I have seen variations of this at Shell, at Johnson Controls, at manufacturing plants, at financial services companies, and at nearly every organisation I have consulted for.
The problem: A quality defect. Product failed inspection.
The 5 Whys as most people do it:
Why did the product fail? -- The specification was out of tolerance.
Why was it out of tolerance? -- The machine settings were incorrect.
Why were the settings incorrect? -- The operator used the wrong settings.
Why did the operator use the wrong settings? -- They did not follow the procedure.
Why did they not follow the procedure? -- They were not properly trained.
Root cause: Insufficient training. Action: Retrain the operator.
This looks neat. It looks logical. It follows a clear chain. It reaches a conclusion. Management can sign off on it, the action is quick and cheap, and the paperwork is complete.
There is just one problem. It is completely wrong.
"The operator did not follow the procedure" is not a root cause. It is a human being being blamed for a system that failed them. And "retrain the operator" is not a countermeasure. It is the improvement equivalent of telling someone to try harder.
I have seen this pattern so many times that I started tracking it. In one organisation, I reviewed 47 completed 5 Whys analyses over a 12-month period. Thirty-one of them -- sixty-six percent -- ended with some variation of "operator error" or "procedure not followed" as the root cause. And the corrective action for every single one was either retraining or adding a step to the procedure.
None of those problems were actually solved. Most of them recurred within three months. Because the root cause was never the operator. The root cause was the system that allowed the error to happen.
The Right Way to Ask Why
Here is how the 5 Whys should work for that same quality defect.
The problem: Product failed inspection.
Why did the product fail? -- The specification was out of tolerance.
Why was it out of tolerance? -- The machine settings were incorrect.
Why were the settings incorrect? -- The machine had not been reset after the previous product run.
Here is where it changes. Instead of asking "why did the operator not reset the machine?" -- which leads straight to blame -- you ask:
Why does the system allow production to start with incorrect settings? -- There is no interlock or verification step that prevents the machine from running with settings from the previous product.
Why is there no interlock? -- Because when the process was designed, this failure mode was not considered. The assumption was that operators would always reset manually.
Root cause: The process design assumes a manual step that has no error-proofing. The system allows a defect to be produced because it relies on human memory rather than built-in verification.
Countermeasure: Install a verification step -- a poka-yoke -- that prevents the machine from starting a new run until the settings match the product specification. Remove the reliance on human memory entirely.
Do you see the difference? The first version blames the person. The second version fixes the system.
The first version will result in retraining. The operator will attend a session, sign a form, and the defect will recur within weeks because nothing in the system changed.
The second version will result in a process change that makes the defect physically impossible. Not unlikely. Impossible. That is the difference between blaming and improving.
Why People Get It Wrong
There are three reasons the 5 Whys is consistently misused, and all three are cultural, not technical.
Reason one: It is faster to blame a person than to fix a system.
Retraining an operator takes an hour. Redesigning a process, installing an interlock, or changing a system takes days or weeks. And it requires someone with authority to approve the change, allocate resources, and accept responsibility for the modification.
Blaming the operator is the path of least resistance. It is quick. It is cheap. It closes the investigation. It satisfies the auditor. And it guarantees the problem will come back, which means job security for whoever runs the next investigation.
Reason two: People stop asking why too early.
The 5 in 5 Whys is not a magic number. It is a guideline. Sometimes you need three whys. Sometimes you need seven. The point is to keep asking until you reach a cause that, if addressed, would prevent the problem from recurring.
"The operator did not follow the procedure" is not that cause. Because even if you retrain every operator in the building, the next person who forgets -- and someone will forget, because humans forget -- will produce the same defect.
The test for whether you have reached the root cause is simple: If I fix this cause, is the problem physically prevented from recurring? If the answer is no, you have not gone deep enough.
Reason three: The organisation's culture does not support system-level thinking.
In many organisations, problems are attributed to people, not systems. "Who made the mistake?" is the first question, not "Why does the system allow this mistake?"
This is a cultural issue, not a training issue. You can teach the 5 Whys technique perfectly, and people will still default to blaming individuals if the culture punishes people for errors rather than investigating systems for weaknesses.
At Shell, one of the most important cultural shifts I witnessed was the move from "who" to "why." When an incident occurred, the investigation framework explicitly directed attention to systemic causes rather than individual blame. Not perfectly -- no culture shift is perfect. But consistently enough that operators and engineers learned that reporting a problem would lead to a system fix, not a reprimand.
That shift took years. It required leadership modelling the behaviour repeatedly. It required leaders publicly correcting themselves when they slipped into blame language. It was slow and sometimes uncomfortable.
But once it took hold, the quality of problem solving transformed. People started asking the real questions. Why does the system allow this? What design assumption failed? How do we make this physically impossible?
The Questions You Should Be Asking
Let me give you the questions that separate good 5 Whys practice from bad.
Instead of "Why did the person make the error?" ask: "Why does the system allow this error to occur?"
Instead of "Why did they not follow the procedure?" ask: "Why is the procedure not error-proof? What happens when someone deviates?"
Instead of "Why were they not trained?" ask: "Why does the process rely on training to prevent a defect? What would make training unnecessary?"
Instead of "Why did they not notice the problem?" ask: "Why is the problem not visible at the point where it occurs? Where is the earliest detection point?"
Every one of those reframes shifts attention from the person to the system. From blame to design. From retraining to error-proofing.
That shift is the difference between a 5 Whys that closes an investigation and a 5 Whys that actually solves a problem.
The Challenge
I am going to ask you to do something uncomfortable.
Go back to the last three root cause analyses your organisation completed. Read the root causes. Read the corrective actions.
How many of them ended at "human error," "procedure not followed," or "insufficient training"? How many of the corrective actions were "retrain," "add to procedure," or "increase awareness"?
If the answer is most of them, your organisation is not doing root cause analysis. It is doing blame allocation with a structured format. And the problems you think you solved are sitting there, waiting to recur.
The 5 Whys is not a bad tool. It is an excellent tool. When used properly, it forces you past symptoms to systemic causes. When used poorly, it is a blame machine with a methodology label.
The next time someone tells you the root cause is "operator error," ask them one more why: "Why does the system allow the operator to make that error?" If they cannot answer, they have not found the root cause. They have found a scapegoat.
Build real problem-solving capability. The Stormholt CI Mastery Toolkit includes 25 professional templates, including structured root cause analysis tools that drive system-level thinking.
https://stormholt.org/products/ci-mastery-toolkit