TrueCauses

Root cause analysis

Root cause analysis is the discipline of asking why something went wrong until the answer stops moving. Fix the root and the symptoms above it go with it; fix a symptom and it comes back. Quality management, IT incident response, patient safety and aviation all require one after a failure. The methods differ mainly in who does the reasoning.

The methods

Five whys
Ask "why" of the failure, then of the answer, five times. One person or a small team. Fast and cheap, and it finds one chain of causes — the one the person asking already suspects. Good for a single incident with a single mechanism; weak where causes interact.
Fishbone (Ishikawa) diagram
Causes sorted into categories — people, process, equipment, materials, environment — drawn as bones off a spine. A facilitator fills it in from a group's suggestions. Broad rather than deep: it lists candidates but says nothing about which causes drive which.
Fault tree analysis
Top-down logic tree from the failure through AND/OR gates to basic events. Rigorous for engineered systems where the components and their failure modes are known. Built by an analyst; needs data the social world rarely has.
Pareto analysis
Count the incidents by category and fix the categories that account for most of them. Says where the pain is, not what causes it — a triage tool, not a cause finder.
Structured Democratic Dialogue
The people who live with the problem write the candidate causes, clarify them, and then judge — one pair at a time, at an 80% bar — whether each cause significantly influences each other. The answers are assembled into an influence map by an algorithm (interpretive structural modelling), and the causes at the bottom of the map are the roots. Fifty years of practice, several hundred documented dialogues. It is what this site runs.

When the group beats the analyst

One question decides. Is the cause known to anyone in the room? If a machine failed, an engineer with the logs will find why faster than fifteen people voting. If deliveries are late, patients wait, a school is losing teachers or a town is losing trust, the causes are spread across the people involved — the night shift knows one, the dispatcher another, the customer a third — and no analyst holds them all. Then the method has to collect the causes from everyone and let everyone judge the links, or it finds only what the analyst already believed.

Two findings from the research explain why a plain group discussion does not do this either. People asked to rank causes by importance before the links between them are examined rank them wrongly — the erroneous priorities effect — and a group asked for its views spreads them so widely that nothing has a majority — spreadthink. Structured dialogue is built around both: no ranking until the links are judged, and links judged one at a time by supermajority.

What a good root cause analysis produces

The seven-stage template · A worked example with real numbers · How this site runs it for any number of groups