Most people run a 5-Whys analysis as a straight line. Something broke, you ask "why" five times, and you walk away with a tidy chain: A caused B caused C caused D caused E. It is the version on every whiteboard and in every template.
The straight line is also where most investigations quietly fail. Real events are not lines. The trigger runs down one chain, but the reason the trigger turned into a disaster almost always lives on a different one. Force everything into a single chain and you explain what triggered the event — and stay silent on what made it a disaster.
A 3-legged 5-Whys fixes that by running more than one chain at once. This is a short guide to what the three legs are, why you need them, and what it looks like worked all the way through on a real event.
A single chain of 'why' explains the trigger. It almost never explains the disaster.
First, the one-chain version — and where it breaks
Say a part shipped to a customer with a defect. The classic chain:
- Why did the customer get a bad part? → It passed final inspection.
- Why did it pass inspection? → The inspection step didn't check for this defect.
- Why didn't it check? → The defect mode wasn't on the inspection plan.
- Why wasn't it on the plan? → No one updated the plan after the last design change.
- Why wasn't it updated? → Plan updates aren't tied to design changes.
That is a real root cause, and the fix — tie inspection-plan updates to design changes — is a good one. But notice what this chain cannot tell you. It does not explain why a defect this size made it all the way to a customer without anyone catching it earlier. It does not explain why the team was comfortable shipping. It explains the hole the part fell through and stays silent on why nobody was standing under the hole.
That silence is the gap the second and third legs fill.
The three legs
Think of any serious event as having three questions, not one. Each question is its own chain of "why." Together they form the three legs — called Occurrence, Detection, and Systemic in FMEA-based quality systems.
Leg 1 — Occurrence: What physically failed? This is the chain people are used to. Start at the symptom and walk down to the specific mechanism that broke — the part, the code path, the seal, the step that didn't run. This leg answers what happened.
Leg 2 — Detection: What let the warning sign get ignored? Almost no big failure is a true surprise. There is usually a smaller version that showed up earlier and got waved through. This leg walks down the chain of how the early signal was handled — the check that wasn't required, the recurring near-miss that got filed under "known issue," the review that rubber-stamped it. This leg answers why we didn't catch it in time.
Leg 3 — Systemic: What shaped the decision? Someone, somewhere, made a call that let the event proceed — to ship, to launch, to skip the step, to overrule the objection. This leg walks down the pressures and structures behind that call — the deadline, the incentive, who had the authority and who didn't. This leg answers why the decision went the way it did.
Occurrence, Detection, Systemic. Miss any leg and the fix lands on the symptom.
You will not always have exactly three. Sometimes the process and decision legs merge; sometimes there are four. "Three-legged" is a habit, not a law: it is the reminder that at the top of your tree you should branch into what broke, what let it through, and what decided it — instead of committing to one chain and losing the other two.
A worked example: Challenger, January 1986
The clearest example I know is the loss of the Space Shuttle Challenger. It is decades old and exhaustively documented in the public record, which is exactly why it makes a good teaching case — every claim below traces to the 1986 Rogers Commission report.
Here is the whole investigation as a tree. The incident sits at the top, and three legs branch out of it. Pan around it before you read on — the shape is the point.
Now walk the three legs.
Leg 1 — Occurrence
The vehicle broke apart because a joint on one of the solid rocket boosters failed to contain the hot gas inside it. Walk down: the joint seals dynamically — at ignition it flexes open for a fraction of a second and a rubber O-ring has to spring into the gap fast enough to block the gas. It was record cold that morning, far colder than the seal had ever flown in. The cold-stiffened rubber was too slow to seat in that tiny window, and the gas escaped.
That is a complete, correct technical chain. And on its own it points to one fix: don't launch in the cold. True, and not nearly enough — because it doesn't explain why anyone launched in the cold in the first place. For that you need the other two legs.
Leg 2 — Detection
This is the leg the headlines skip. The cold-weather seal problem was not a surprise on launch morning. Earlier flights had come back showing damage to those same seals. Each time, the mission had succeeded anyway — so the damage got read as proof the joint could tolerate the condition, rather than as a recurring warning running on borrowed margin.
Each success made the next risk look smaller. That is normalization of deviance — and it hides in routine.
That slow slide has a name: normalization of deviance. A signal that should have forced a stop got re-labeled, one reasonable-looking step at a time, as normal and expected. The fix on this leg isn't about temperature at all — it's about making a repeating warning sign trigger a real investigation instead of getting absorbed into the baseline.
Leg 3 — Systemic
The night before launch, the engineers closest to the hardware did the right thing: they recommended, in writing, not to fly in the forecast cold. They were overruled. The decisive move was subtle — the question in the room flipped. The engineers came to answer "is it safe to fly this cold?" The pushback they got, in effect, was "prove that it isn't." (This decision — and the normalization that led to it — gets its own full walkthrough in the Challenger O-ring post.)
That flip is fatal, because you cannot prove a specific failure in advance. The moment the bar became "show me it will fail," the objection was guaranteed to lose no matter how strong the underlying case. Behind the flip was a structural problem: the same office that owned the launch schedule also got to judge the safety concern. There was no independent voice whose only job was to protect the hold.
The first two legs explain the failure. The systemic leg explains the decision that allowed it — and that is the one most likely to repeat on the next event.
The fix on this leg is organizational: clearing a documented engineering hold should require positive evidence of safety, and the authority that can clear the hold must not be the authority that owns the deadline.
Why all three were needed
Look at what each leg gave you. Leg 1 alone says don't fly in the cold — a fix for one event. Leg 2 says stop letting repeating warnings get normalized — a fix for a whole class of events. Leg 3 says protect the hold point from schedule pressure — a fix for how every future high-stakes call gets made.
Drop the second and third legs and you patch the cold seal and live through the next variant. That is the entire argument for the three-legged structure: the leg you are tempted to skip is usually the one carrying the fix with the most leverage.
The leg you are tempted to skip is usually the one carrying the fix with the most leverage.
How to model this in RCA Map
The structure above is exactly what RCA Map is built for. A 3-legged 5-Whys is awkward on a whiteboard — branches collide and you run out of room — but natural as a tree:
- Put the event at the top.
- Branch into your legs directly under it: one node each for what failed, what let it through, and what decided it. You are not committing to a single chain; you are opening three.
- Walk each leg down with its own "why" chain. Don't force them to the same depth — the technical leg might bottom out in three steps while the decision leg takes five.
- Hang the corrective and preventive actions off the leg they belong to. The Challenger map above does this: each leg ends in an action aimed at that leg's failure, not a single generic to-do.
The map stays readable no matter how wide it gets, every node holds the evidence behind it, and the finished tree is something you can hand to someone who wasn't in the room.
And you don't have to structure it alone. RCA Map's AI understands the 3-legged 5-Whys natively: it can help you open the three legs from the event, suggest which leg a given cause belongs on, and prompt the next "why" when a chain stalls a level too early. Think of it as an expert-analyst companion working alongside you on the analysis — not a blank canvas you have to fill in by yourself.
Try it on your own incident
Take the last incident your team reviewed — the one that ended in a single neat chain — and ask the two questions that chain skipped: was there an earlier warning we waved through? and what pressure shaped the call that let it proceed? If either question has an answer, you had a three-legged event and only investigated one leg.
Open a blank map and try it. Start with the event, branch into the three legs, and see how much of the story was hiding off the main chain.
Source: Report of the Presidential Commission on the Space Shuttle Challenger Accident (the Rogers Commission report, 1986). The Challenger example describes roles rather than naming individuals, and follows the Commission's published findings.