Why-why analysis (also called 5 Whys or 5Y) is a root-cause method: state the problem, ask why it happened, then ask why again — until you reach a cause that, if fixed, stops the problem returning. Five is a guideline, not a rule. You stop when the answer is something you can act on.
It is the simplest root-cause tool that actually works, which is exactly why it gets misused. This guide covers the format, a real worked example from a factory floor, and — honestly — the three ways why-why analysis goes wrong.
Where does it come from?
Taiichi Ohno at Toyota made repeated questioning the foundation of the Toyota Production System's approach to problems. His famous example, from his own book: a machine stopped.
- Why did the machine stop? — The fuse blew from overload.
- Why was there an overload? — The bearing wasn't lubricated properly.
- Why wasn't it lubricated? — The lubrication pump wasn't pumping enough.
- Why wasn't it pumping? — The pump shaft was worn and rattling.
- Why was it worn? — There was no strainer, and metal scrap got in.
Replace the fuse and you're back in a week. Fit a strainer and the problem is gone. Five questions separate those two outcomes — that's the entire method.
What is the why-why analysis format?
The format that works on an actual shop floor is a simple chain — problem at the top, one cause per row, action at the bottom:
| Step | Question | Answer (one specific cause, verified) |
|---|---|---|
| Problem | What happened, where, when? | Hydraulic press P-2 stopped, night shift, 11 March |
| Why 1 | Why did it stop? | Pressure dropped below the safety threshold |
| Why 2 | Why did pressure drop? | Main cylinder seal was leaking |
| Why 3 | Why was the seal leaking? | It was 14 months old — rated life is 12 months |
| Why 4 | Why wasn't it replaced at 12 months? | The PM task for seal replacement never got scheduled |
| Why 5 | Why wasn't it scheduled? | PM dates are tracked in a spreadsheet; the entry was missed after a staff change |
| Root cause | PM schedule depends on one person remembering a spreadsheet | |
| Action | Seal replaced AND every press PM moved to an automatic schedule with a named assignee |
Three rules make the format work:
- Each answer must be verified, not guessed. Go look at the machine, the log, the part. "Probably the operator" is not an answer; it's an accusation.
- Each answer must be specific. "Poor maintenance" explains nothing. "The PM task was never scheduled" can be fixed.
- The chain must point at the process, not a person. If your root cause is "operator error", ask why number six: why was the process able to fail when one human had a bad day?
We watched this play out with our own hardware. An MDIM converter kept dropping offline and wouldn't come back after a power cycle, and the reflex was to blame the new device — it's the thing that changed. Follow the chain instead, and the real cause surfaced: two devices sharing one static IP, colliding on every reboot until one lost the address and dropped off the network. The "faulty" converter was fine; the IP plan wasn't.
When should you run a why-why analysis?
Not on everything — that's how the method becomes a form-filling ritual. Run it on:
- Repeat breakdowns — anything that's happened twice on the same machine. Once is bad luck; twice is a system.
- Quality rejections traced to a machine condition — the defect is the symptom; the machine state is the chain to follow.
- Safety near-misses — the one category where you run it even on a first occurrence.
- Any breakdown above a cost threshold you set — for many plants, anything that stopped a line for over an hour.
For a single cause-and-effect chain, why-why is enough. When a problem has several interacting causes — three shifts, two materials, an environmental factor — a fishbone diagram maps the territory first, and you run why-why down the branch that the evidence supports.
The three ways why-why analysis goes wrong
1. The chain confirms what you already believed. You decide the answer is "operator error" at why number one, and every subsequent why marches obediently toward it. Antidote: a second person who wasn't involved in the breakdown asks the questions.
2. The answers are guesses dressed as facts. The chain reads logically, but nobody actually checked the pump shaft or pulled the lubrication log. A why-why analysis is only as good as the evidence at each link.
3. The action never happens. This is the big one. The analysis is done at the morning meeting, everyone nods at the root cause, the corrective action lives in the minutes of a meeting — and the same seal fails again 14 months later. A root cause without a tracked corrective action is a diagnosis without a prescription.
The third failure is a systems problem, not a discipline problem. The action needs to become a work order with a named owner and a due date — and the recurring fix (a PM, a design change, a new checklist step) needs to fire automatically, forever, without depending on anyone's memory.
An opinion from the field: Indian plants are excellent at the analysis and terrible at the follow-through. Open almost any ISO audit file and you'll find beautiful why-why forms for problems that recurred anyway — because the form was filled in for the auditor, not for the machine.
Doing it digitally (without losing the simplicity)
Why-why analysis needs no software — a whiteboard works. What needs a system is everything around it:
- Knowing which breakdowns repeat. If your breakdown history lives in a paper register, you can't see that press P-2 has failed four times this year — so you never trigger the analysis. A work-order history per machine makes repeats visible.
- Capturing the root cause where the work happened. When the root-cause field lives on the work order itself, the analysis is attached to the machine's history — searchable next time, not buried in a meeting file.
- Making the corrective action permanent. "Replace seal every 12 months" only counts as a fix if it becomes a schedule that fires on its own.
Where MachDatum fits: work orders carry a root-cause field that's required before a repair can close — so the why-why result is captured at the machine, every time. Repeat failures are visible in each asset's history, and corrective actions become preventive maintenance schedules that dispatch themselves. We're onboarding our first group of manufacturing teams right now — see it on your own breakdown data.
