Guide #1. Practitioner guide.
I have sat through a lot of 5-Whys sessions. The good ones produced a corrective action that survived contact with the next quarter. The bad ones produced a CAPA nobody reopened. The difference between the two had almost nothing to do with the event, and almost everything to do with how the session was facilitated.
This is a guide to the failure modes. If you are about to run a 5-Whys session — for a defect escape, a near-miss on the line, a batch deviation, a customer escalation — read this first. Most of the work is pre-commitment: deciding, before you start asking "why," what you will and will not let the session do.
The five ways a 5-Whys session derails
There are more than five. These are the five I see in almost every session I sit in.
Derailment 1 — Stopping at the first satisfying answer
The most common failure. The room arrives at "the operator missed the check" or "the shift lead missed the alarm" and exhales. The investigation is over because someone has accepted blame.
The 5 in "5 Whys" is not a target word count. It's a forcing function. The whole technique exists because the answer that satisfies you on Why 2 is almost never the answer that prevents the next variant of the same event. If your team is happy at Why 2, your job as the facilitator is to look at the answer and ask "and why was that allowed to be true?" out loud, even if it feels like beating a dead horse. Especially if it feels like beating a dead horse.
Pre-commitment: before the session starts, the facilitator says "we are not stopping at Why 2 or Why 3. If we get to Why 5 and we are still on a real failure mode, we keep going." Put it on the whiteboard. The point is to remove the social cost of asking the next question.
Derailment 2 — Asking "why" of people, not the system
The session turns into "why didn't Alex notice?" and from there into a performance review with extra steps. This is the single fastest way to destroy an incident-review culture, and it produces no usable corrective action — because "Alex should pay more attention" is not an action, it's a wish.
A blameless 5-Whys treats every human action as data about the system. The shift lead missed the alarm? That's not the answer. Why was the alarm designed in a way that allowed it to be missed? is the answer. The line ran short-staffed on third shift? That's not the answer. Why does our scheduling produce short-staffed shifts? is the answer.
Pre-commitment: every "why" sentence has to end with a system noun, not a person's name. "Why did incoming inspection accept it" is in. "Why didn't the inspection team test it" is the same sentence, in disguise — recast it. "Why did the inspection plan not require this case" is in.
Derailment 3 — Forcing a single linear chain
The classical 5-Whys diagram is a single line: A causes B causes C causes D causes E. Real events are not lines. They branch. There is a proximate fault, and then there are contributing factors that turned that fault into a disaster — process variability, containment posture, alarm coverage, organizational seams.
If you force everything into one chain, you lose the contributing factors. You end up with a perfect explanation of the trigger and no explanation of the blast radius. That's an incident review that says "the operator missed the check" and leaves the customer escalation unexplained.
Pre-commitment: at every node, the facilitator asks two questions, not one. "Why did this happen?" is the main chain. "What else had to be true for this to be bad?" is the contributing-factor branch. Both go on the board.
Derailment 4 — Asserting without evidence
Somebody says "I think the batch was bigger than usual" and the room nods, and now "the batch was bigger than usual" is in the diagram as if it were a fact. By Why 4, half the nodes are this kind of comfortable conjecture, and the corrective actions are pointed at a theory of the event, not the event.
Every node in a 5-Whys investigation has to resolve to evidence, or be flagged as inference. The fix isn't to suppress speculation — speculation is how you find the next branch to investigate. The fix is to label it. A node that has an inspection record, a control chart, an SOP citation, or a transcript behind it is a fact. A node that has "I think" or "probably" behind it is an inference, and it gets a flag on it. Inferences are allowed. Unlabeled inferences are not.
Pre-commitment: the board has two columns. Records in one. Inferences in the other. Anybody in the room can call out a node and ask which column it should be in. The flag isn't a punishment — it's a to-do for follow-up.
Derailment 5 — Conflating corrective and preventive actions
The session ends with "we'll add a check at incoming inspection." Six months later, a different class-of-failure event hits the same line. The inspection step was fine — it caught the defect mode you patched and missed the one nobody anticipated.
"Add a check at incoming inspection" is a corrective action. It addresses this event. A preventive action addresses the class of event. They are different artifacts. They are written by different people. They have different acceptance criteria. If your 5-Whys session produces only corrective actions, you have closed the CAPA on this event and signed up to live through the next one.
The most useful split I know: corrective actions live at Why 1 through Why 3. Preventive actions live at Why 4 and Why 5. The deeper you walked, the more class-of-failure your answer is, and the more leverage there is in fixing it once.
Pre-commitment: the session output is a branching diagram with two action lists hanging off it. One for "what we are doing in the next cycle to close this event." One for "what we are doing in the next quarter to close this class of event." If you finish the session and one of the lists is empty, you have not finished the session.
A worked example — mapping a defect escape
Take a familiar event on a discrete-manufacturing line: a defective unit ships to a customer and is caught by the customer's incoming inspection. The trigger is a missed final-inspection check. The blast radius is the customer escalation, the containment recall of every unit shipped in the same window, and the CAPA the auditor will ask about next quarter.
Walk it with branches, not as a single chain. The main chain runs from the symptom down through the failure mode — the gauge was out of calibration, the calibration was overdue, the calibration schedule had a gap because a technician left and the work was never reassigned. That's a clean chain to Why 4 and it produces real corrective actions: recalibrate the gauge, reassign the schedule.
The contributing-factor branches are where the leverage lives. Why did the line continue running on an overdue gauge? — because the work instruction did not gate production on calibration status. Why did the customer escalation happen at all? — because outbound inspection did not sample the affected lot. Why did containment take three days? — because the lot-traceability query was a spreadsheet a single engineer maintained.
Now look at where the corrective actions are versus where the preventive actions are. Corrective actions cluster around Why 1 to Why 3 — recalibrate, recall the lot, retrain the operator. Those are real, and you do them. The preventive actions live deeper. Why was a single overdue gauge able to escape detection on the line and again at outbound? That answer is a category mistake at the level of quality systems — calibration status was advisory, not interlocked — and the action that flows from it is a re-architecture of how calibration gates production.
You do not get that second list if you stop the investigation at Why 2.
Pre-flight checklist for your next session
Before you start the next 5-Whys session — paper, whiteboard, RCA Map, anything — pre-commit to these five things:
- We will not stop at the first satisfying answer. The facilitator's job is to push past consensus.
- Every "why" ends in a system noun, not a person's name. Recast as needed.
- The board allows branching. Contributing factors hang off main-chain nodes.
- Every node is either evidence-backed or labeled as inference. The flags are the to-do list.
- The output is two action lists: corrective (this event) and preventive (this class). Both must be non-empty.
If you can hold all five, the session will not produce a CAPA that nobody opens again. It will produce a corrective action that closes this event, and a preventive action that earns its place on next quarter's roadmap.
That, in my experience, is the entire difference between a 5-Whys that worked and a 5-Whys that didn't.