Root cause analysis: getting past the first plausible answer

Root cause analysis is the practice of investigating a problem until you understand the mechanism that produced it, rather than the event that revealed it. The test of whether you have arrived is straightforward: if you removed what you have identified, would this class of problem stop happening? If the honest answer is probably not, the analysis is unfinished.

What makes it hard is not technique. It is that every investigation passes through an answer that feels sufficient — somebody was careless, the supplier sent a bad batch, the system was slow — and stopping there is comfortable, quick and usually wrong.

The methods, and what each is good for

• Five whys: ask why repeatedly until answers stop being events and start being conditions. Fast, informal, and prone to producing one narrow chain when several causes combined.
• Fishbone diagram, also called Ishikawa: sort possible causes into categories — people, process, equipment, materials, environment, measurement — to force breadth before depth.
• Fault tree: work backwards from the failure through the combinations of conditions that could produce it. Heavier, and suited to safety-critical work.
• Timeline reconstruction: lay out what happened minute by minute. Frequently the single most useful step, because it exposes the gaps in what people assumed.
• Change analysis: ask what was different this time. Problems that appear suddenly usually follow a change somebody did not consider risky.

Five whys has a known weakness worth naming: it produces a single chain, and real failures are usually a coincidence of several conditions. If your analysis reads as one tidy line of reasoning, check whether you discarded contributing factors because they did not fit the chain.

Stopping at human error

When an investigation concludes that someone made a mistake, it has generally stopped one step early. People make errors at a fairly stable rate; what varies is how easy a system makes them and whether anything catches them. The useful question is not who erred but what allowed the error to reach the outcome — no confirmation step, two documents that look alike, a warning everyone has learned to dismiss, a workload that made haste rational.

This is not about being generous. It is that fixes aimed at a person do not survive that person leaving, while fixes aimed at conditions apply to everybody who comes after.

Running one

1. Do it while the memory is fresh, but after the immediate situation is contained.
2. Reconstruct the timeline first, from records rather than recollection where possible.
3. Gather people who saw different parts of it, and make it explicit that the purpose is not blame.
4. Generate candidate causes broadly before evaluating any of them.
5. Test each candidate against the evidence: would this actually have produced what we saw?
6. Keep going until the causes are conditions rather than events.
7. Identify which causes you can realistically change, and accept that some are outside your control.
8. Write it up briefly — problem, timeline, causes, actions, owners — and make the write-up findable.

The write-up is the artefact

An analysis that lives only in the meeting is lost within weeks. The write-up does two things beyond recording the outcome: it lets someone hitting a similar problem in a year find out what was learned, and it exposes patterns when several are read together. The second is where the real value accumulates — three separate investigations that each ended at a different proximate cause often share a condition nobody noticed while looking at them one at a time.

Ettex Docs is the practical place for that write-up: a document per investigation with the timeline, the causes and the actions, version history so later corrections are visible, and comments so people who were involved can dispute the account before it is filed. Duplicating the previous one gives you the structure without a blank page.

It offers no analysis tooling — no fishbone or fault-tree diagramming, no template library, no linkage from a cause to the actions tracked elsewhere. The diagram, if you want one, is drawn elsewhere and pasted in; the actions belong in whatever you use to track work.

Blameless does not mean consequence-free

The reason to run these without blame is practical: people who expect punishment give incomplete accounts, and an incomplete account produces a wrong analysis. That is compatible with accountability for what happens next — someone owns each action and is answerable for whether it happens. What it is not compatible with is treating the investigation as the process that identifies who to discipline, because then the next investigation gets nothing useful.

Build the timeline first, generate causes broadly before judging them, keep going until you reach conditions rather than events — and write it down somewhere the next person will look.