Why the 5 Whys Falls Apart Without Structure
The 5 Whys is popular for a good reason: it needs no training, no software, and no facilitator certification. Ask "why" about the answer to the last "why," five times, and you're supposedly at the root cause. In a whiteboard session with a sharp facilitator, it can work. As a repeatable investigation process across a whole organization, it falls apart in the same four places almost every time.
Where it breaks
It assumes one causal path. "Why" implies a single chain: A caused B caused C. Most real incidents are a tree, not a chain — two or three conditions that each contributed, combining at the wrong moment. A strict 5 Whys session picks one path and follows it, quietly discarding the other contributing factors because the format doesn't have anywhere to put them.
Five is an arbitrary number. Sometimes the root cause is two whys deep. Sometimes it's eight. Teams that treat "five" as a target either stop early because they hit the number, or manufacture a fifth "why" that isn't really doing causal work — it's just there to complete the exercise.
Nothing checks whether a "why" is actually true. Each answer in a 5 Whys chain is usually whatever the most confident person in the room says. There's no built-in step that asks "how do we know that" or requires evidence before you build the next why on top of it. Get one link wrong and the rest of the chain is a well-reasoned answer to the wrong question.
There's no record of what else was considered. If the finding gets challenged later — by a regulator, an auditor, or just someone who disagrees — a 5 Whys writeup usually can't show what alternative causes were ruled out and why. It shows the path that was taken, not the reasoning for not taking the others.
What actually fixes it
Not abandoning "why" as a question — it's still the right question. What fixes it is putting structure around it:
- Branch, don't chain. Let a single event have multiple why-options, each explored, not just the first one that sounds right.
- Tag the cause type as you go — immediate cause, contributing factor, root cause — so "operator error" can't get filed as a systemic finding just because it was the first answer.
- Rate the causes you're keeping, so a low-risk contributing factor doesn't get the same weight in the report as the thing that actually needs to change.
- Gate the irrelevant branches instead of forcing every investigator through a generic checklist regardless of what actually happened.
That's the structured version of the same underlying idea — a section-by-section questionnaire with why-options, gate questions and a risk rating on every cause, instead of five sequential "why"s and whatever the room agrees on.