How to Run a 5 Why Analysis on the Shop Floor (Without a Conference Room)

Most 5 Why write-ups assume you have a whiteboard, a facilitator, and ninety minutes of everyone's afternoon. On a production floor you have none of those things. You have a line that just scrapped a 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.

What follows is the version that actually works out there, on machining cells, assembly lines, and molding presses, 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 worn cutting tool, a missed PM, a short shot on a molding press, 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 resin lot meets a certain mold 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 material 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 of the bad 5 Whys in circulation 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 chips get swept up and the coolant gets topped off. The fixture gets pulled and sent to the tool room. The operator who saw the machine stall 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.

"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 run the wrong offset? Was there no first-piece check after the tool change? No touch-off step in the program? Was the setup sheet out of date? Was the standard work unclear, or was the takt so tight that the check gets skipped every time the cell 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 machining cell, the shape most real ones take:

Notice what each answer is: a checkable fact. The oversize dimension is on the inspection record. The insert change is in the tool log. The stoppage is in the downtime record. The alarm is in the machine 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 offset stale?" not "Why did you run the wrong offset?"
• 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 (the defect, tool marks, 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-system upgrade and the PM schedule — you find that in the records, not on the floor.
• The paperwork in play — traveler, material 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 concentration sensor on the PM schedule, add the coolant-system upgrade to the management-of-change checklist so the next modification updates PMs automatically, and make the touch-off a required program step after any insert change so a stale offset can't run. 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.