5 Why Root Cause Analysis

What this tool does

CM8-226 is a working register of 5 Why analyses. Each record is one complete analysis: the problem statement, the chain of whys, the root cause you reached, the countermeasure, and whether that countermeasure has been implemented and then verified. Keeping every analysis in one register — rather than scattered across whiteboard photographs and meeting notes — is what turns 5 Why from a one-off exercise into a memory. The charts show which root cause types dominate, which areas keep coming back, and how deep your analyses actually go.

Everything runs inside this single file. There is no account, no upload and no network request of any kind, so the honest, sometimes uncomfortable content of a root cause analysis never leaves the computer you are using.

Where 5 Why comes from

The method was developed inside Toyota as part of its production system, and it spread with lean manufacturing to every industry that adopted lean thinking. The idea is disarmingly simple: when something goes wrong, do not stop at the first explanation. Ask why that explanation was true, then why that was true, and keep going until you arrive at a condition in the system — a method, a design, a plan — that, if changed, would prevent the problem recurring.

Its power is its cheapness. A 5 Why needs no software, no statistics and no consultant: it needs the people who know the work, fifteen honest minutes, and the discipline not to stop early. Its weakness is the same informality — done carelessly, it produces a chain of guesses that ends wherever the loudest person in the room wanted it to end. The sections below are about doing it carefully.

Writing the problem statement

The analysis can only be as sharp as the problem statement, so spend time on it. A good statement says what happened, where, when, and how big — and nothing else:

• Specific. "Blistering on 14 of 60 panels in batch P-4471" — not "paint quality issues".
• Measurable. A count, a quantity, a duration. "Seven orders missed the Friday collection" tells you later whether the countermeasure worked; "orders are sometimes late" never will.
• Free of causes. "Panels blistered because the degreaser failed" has already skipped three whys and may have skipped to the wrong one. State the deviation only.
• Free of blame. No names, no "carelessly", no "again". The statement will be read by the people involved, and a statement that reads as an accusation gets defensive answers to every why that follows.

Asking why without blaming

Almost every chain passes through a human action at some point: someone picked the wrong part, missed a check, sent the wrong file. The critical move is what you do next. "Why did the person err?" is a dead end — the answer is some variation of "people make mistakes", and the countermeasure becomes "told them to be more careful", which changes nothing. Ask instead: why did the process allow the error, and why did nothing catch it?

In the sample data, the wrong-item picks were made by a person — but the chain does not stop there. Why did they pick the wrong part? Two part numbers differ by one digit on adjacent shelves. Why wasn't it caught? The check-scan step wasn't in the written procedure, so a new starter never learned it. The countermeasure fixes the procedure and the induction, not the person. That is the whole discipline in one example: people appear in the middle of a good chain, never at the end of one.

When to stop asking

You have reached a root cause when the answer is something you can change that would prevent recurrence. Test each candidate ending against that:

• "Operator error" — not a root cause. You cannot change human fallibility; keep asking why the error was possible and undetected.
• "Bad luck" or "one-off" — not a root cause. It is a decision to stop investigating, dressed up as a conclusion.
• "No temperature check or alarm on the degrease bath" — a root cause. You can add the check, and doing so prevents the recurrence.

A practical check is to run the chain backwards using "therefore": the thermostat failed unnoticed, therefore the bath ran cold, therefore oil survived degreasing, therefore the paint blistered. If any "therefore" step is not actually inevitable, the link is weak and the chain needs another look. And where evidence can be checked — a temperature log, a returns record, the actual hose grade — check it before writing the why down. Chains built on assumption produce countermeasures that fix imaginary problems.

Why depth matters — and why five is not a law

The tool records a depth for every analysis:

Depth is a smell test, not a score. One or two whys almost always means the chain stopped at the symptom or at a person, and analyses below your minimum credible depth (three, unless you change it in Settings) are flagged in the register. But five is a guideline from the method's name, not a law of nature: some chains genuinely bottom out at three — the late-dispatch analysis in the sample reaches a workable root cause in three steps — and some need six or seven. Never pad a chain with filler whys to reach five, and never stop at five if the answer there still is not something you can change. The depth chart shows the distribution across your register; a register full of ones and twos is a register of symptom patches.

Countermeasure, not quick fix

The quick fix deals with the instance: mop the coolant, rework the batch, apologise to the customer. It is necessary and it is not a countermeasure. The countermeasure removes the root cause, so the instance cannot recur: fit the low-level alarm, put the cutoff time into the planning system, write the check into the procedure. A register where the countermeasure column repeats the clean-up — or says "operator reminded" — is a register that will fill up with the same problems on a loop.

Every countermeasure needs an owner and a due date, and the tool will not let you mark an analysis implemented or verified without one written down. It also refuses one specific contradiction: a root cause type of "not yet established" together with an implemented countermeasure. If you have not found the cause, whatever you implemented was a guess.

Verification discipline

Implemented is not fixed. Fixed is verified: the countermeasure was put in place and the problem measurably stopped. Write the verification method at the start, not after the fact — "zero adhesion rejects across the next ten batches", "no missed Friday collections for eight weeks" — so that passing it means something. The tool requires a verification method before an analysis can be marked verified, and the "Open and unverified" table keeps every analysis in view until it passes, with the next step spelled out: establish the cause, implement the countermeasure, or verify it worked.

Verification is also where honest analyses admit failure. If the problem recurs after the countermeasure, the chain was wrong somewhere — reopen the analysis and walk it again with the new evidence. That is not wasted work; it is the method working.

When 5 Why is the wrong tool

A why-chain is a single thread. It suits problems with one dominant cause — most everyday quality, breakdown and delivery problems are exactly that. It suits badly:

• Problems with several interacting causes. A defect that only appears when a particular material meets a particular machine setting on a hot day will not fit one thread. Use a fishbone (cause-and-effect) diagram to map the candidate causes across categories first, then run a why chain down the branches that the evidence supports.
• Serious injuries and major failures. These deserve a formal investigation with evidence preservation and independent review. A 5 Why can be a useful input to that; it should not be the whole of it.
• Chronic, data-rich problems. If the problem occurs hundreds of times, analyse the data for patterns before asking why — the pattern usually answers the first two whys for you.

Printing and sharing

Print Report produces a report from whatever the current filter shows: the headline tiles, the four charts, the root cause register, the open-and-unverified list and your closing notes. Print to PDF to circulate it. The scope line under the title states the filter in force — clear the filters before issuing anything described as the full register. Because each analysis is one record, an individual analysis also prints cleanly as a single entry, whys and all.

Saving your work

Analyses, settings and the report header are written to this browser's local storage as you type, and the toolbar shows the time of the last save. That storage belongs to one browser on one computer: another browser, a private window, a second machine or a clean-up tool that clears site data will not have it.

Treat Export .json as the real save — one file containing everything, which Import .json restores anywhere. Export CSV gives you the register for spreadsheet work. Reset asks twice, then erases everything this tool has stored. There is no undo.

Frequently asked questions

Do I have to fill in all five whys? No. Fill the whys the chain genuinely needs and stop when you reach something you can change. Blanks after the chain ends are correct; blanks in the middle break the depth count, because a chain with a hole in it is not a chain.

Can one problem have two root causes? Occasionally a chain forks. If both branches matter, record two analyses with the same problem statement and one branch each — the register handles that cleanly, and each branch gets its own countermeasure and verification. If it forks repeatedly, you are looking at a fishbone problem, not a 5 Why problem.

Who should do the analysis? The people closest to the work, as soon after the event as practical, ideally where the problem happened. A manager writing whys alone at a desk a week later is recording guesses.

What counts as an area repeat? The area chart turns red when an area has two or more analyses in the current filter. That is deliberately sensitive — the second occurrence is exactly when you should ask whether the first countermeasure held.

Why does the tool refuse "root cause not yet established" with an implemented status? Because implementing before establishing means the countermeasure is aimed at a guess. Establish the cause first, or record what you did as an interim containment in the problem statement.

Accuracy & disclaimer

This tool records what you enter and counts it. It cannot tell whether a why is evidenced or assumed, whether the chain stopped at the real cause or a convenient one, or whether the verification method is strong enough to prove anything — every conclusion in the report depends on those judgements being made honestly.

A single why-chain assumes one dominant cause; problems with several interacting causes will be oversimplified by it. For serious incidents, regulated events or anything with legal consequence, treat a 5 Why as one input to a proper investigation, not as the investigation.