Most 5 Why write-ups assume you have a whiteboard, a facilitator, and ninety minutes of everyone's afternoon. On a forging floor you have none of those things. You have a press that just scrapped a heat lot, a shift that ends in three hours, and a supervisor who wants to know whether to keep running. The good news: a 5 why analysis was never supposed to be a meeting. It's a line of questioning, and the best place to ask it is standing at the machine while the problem is still warm.
I've run these on hydraulic presses, furnaces, and trim lines. What follows is the version that actually works out there — not the laminated-poster version.
When 5 Why fits — and when it doesn't
5 Why is the right tool when you're chasing a single failure path: one part, one machine, one event, and a chain of causes you can walk backward one link at a time. A cracked die, a missed PM, an overheated billet, a torqued-wrong fastener — these are 5 Why problems. The method is fast, needs no software or training beyond discipline, and everybody on the crew can follow the logic.
It's the wrong tool when:
- Multiple causes interact. If scrap only shows up when a certain alloy meets a certain die temperature on a certain shift, a single chain of whys will flatten that into a story that's too simple. That's fishbone-and-data territory.
- The problem is intermittent and nobody saw it happen. Asking "why" five times about an event nobody witnessed produces five guesses. Get data first, then ask why.
- The answer is genuinely unknown territory — a metallurgical failure you've never seen, a new process. You need a lab report or a trial plan, not a questioning technique.
Be honest about this up front. Half the bad 5 Whys I've seen weren't done badly — they were done on the wrong kind of problem.
Run it at the machine, not next Tuesday
Evidence on a shop floor has a half-life measured in hours. The scale pattern on the billet gets swept up. The die gets pulled and sent to the tool room. The operator who saw the press stutter goes home, and by Monday remembers it differently. If you book a conference room for Thursday, you'll be doing archaeology instead of analysis.
So run the first pass immediately, at the machine, with whoever was there. It takes fifteen minutes. You're not writing the final report — you're capturing the chain of causes while every link is still checkable. Walk the line of questioning right where you can point at things: show me the reading, show me the lube line, show me the last work order. Every answer you can verify on the spot is an answer that won't fall apart in the CAPA review.
If the full analysis needs more people, fine — but the at-the-machine pass is the raw material. The conference room, if it ever happens, is for confirming, not discovering.
The "operator error" trap
Here's the most common way a 5 why root cause analysis dies: it stops at a person.
"Why did the part crack?" — "Operator loaded it cold." — Root cause: operator error. Action: retrain operator. That's not a root cause. That's an accusation with paperwork.
"Operator error" is almost never the bottom of the chain — it's the middle. The question that matters is: why was it possible for the operator to load a cold billet? Was there no temperature check before the press cycle? No interlock? Was the pyrometer reading wrong? Was the standard work unclear, or was the takt so tight that the check gets skipped every time the line falls behind? Keep asking why until you hit something about the process — a missing control, a broken standard, a design that invites the mistake.
A practical rule: if your last why names a person, you have at least two more whys to go. People are how failures surface; systems are why they happen. And practically speaking, "retrain operator" fixes nothing — the next operator inherits the same trap.
How to phrase each why
The quality of a 5 Why lives or dies on phrasing. Each question should be aimed at the previous answer, and each answer should be something you could verify — a reading, a record, a condition you can point at. Not an opinion.
A chain from a forging cell, the shape of dozens I've run:
why 2: Why was the billet below temperature? → It sat in the transfer queue longer than the standard allows.
why 3: Why did it sit too long? → The press was down for eleven minutes mid-sequence.
why 4: Why was the press down? → The main hydraulic pump tripped on temperature.
why 5: Why did the pump overheat? → The heat exchanger was fouled; it wasn't on the PM schedule after the coolant system was modified last year.
Notice what each answer is: a checkable fact. Queue time is on the furnace log. The press stoppage is in the downtime record. The pump trip is in the alarm history. The PM gap is visible in the CMMS. Nobody has to take anyone's word for anything — and the chain survives scrutiny because of it.
Three phrasing habits that keep the chain honest:
- Ask why about the condition, not the person. "Why was the billet cold?" not "Why did you load a cold billet?"
- Ban "because they didn't follow the procedure" as a terminal answer. Ask why the procedure wasn't followed — unclear? impractical? unknown? never trained?
- Stop when you reach something you can act on. Five is a guideline, not a rule. Sometimes it's three whys, sometimes seven. You're done when the answer is a process condition your team has the authority to change.
Evidence to capture while you're standing there
The 5 Why gives you the chain; evidence is what makes anyone believe it — including an auditor eight months later. While you're at the machine, capture:
- Photos of the failed part (fracture face, scale, witness marks), the machine state, gauge readings, and anything about to be cleaned up or torn down.
- Process readings — actual temperatures, pressures, cycle times, alarm codes. Pull them now; some HMIs only buffer a shift's worth.
- Work order and PM history for the equipment in the chain. In the example above, the whole root cause lived in the gap between a coolant modification and the PM schedule — you find that in the records, not on the floor.
- The paperwork in play — traveler, heat lot cert, setup sheet, last first-piece inspection.
- Names and times — who was running, who responded, when each event happened. Not for blame; for sequence.
A 5 Why with photos and log excerpts attached is a different animal from one scribbled from memory. One closes CAPAs; the other reopens them.
Turn the last why into a corrective action
The final why is only worth the walk if it becomes an action that removes the cause. From the chain above: put the heat exchanger on the PM schedule, add the coolant-system modification to the management-of-change checklist so the next modification updates PMs automatically, and add a low-temperature hold at the press so a cold billet can't be struck. Cause removed, recurrence blocked, and a control added for the failure mode in general.
That handoff — from cause to documented corrective action with an owner, a due date, and a verification step — is its own discipline, and it's where audits are won or lost. And if you're wondering how the 5 Why fits into the bigger corrective-action machinery your quality system requires, that's the RCA-versus-CAPA distinction in a nutshell: the whys find the cause, the CAPA fixes and prevents it.
One more thing. If you want the questioning discipline without carrying the method in your head, Root Cause AI walks your team through a root cause analysis conversationally — asking the whys, pushing past "operator error," and capturing photos and evidence right at the machine, then turning the result into an audit-ready report.