How to create a root cause analysis flowchart
How to draw a root cause analysis flowchart that picks the technique for you: the evidence gate that precedes every method, the branch that separates one chain from many, and where each method stops.
A worked example, stage by stage
Framing is a loop, not a step
Three rows, and the tree has not started yet: "Problem clearly defined?" refuses a statement until "Bound the problem statement" has narrowed it. Every choice downstream is made from that wording, so a statement naming a suspected cause has picked the method before any evidence is read.
Evidence before technique
Nothing is chosen yet: "Evidence already available?" and "Data sufficient to analyse?" sit upstream of every method box. The "Insufficient" exit lands on "Return to evidence collection", because a sequence nobody can reconstruct cannot say whether one chain or several categories are in play.
The row that picks the method
Structure comes first: "Single event or recurring?" leads to "Failure nature?", whose three exits are the entire point — "Technical" to "Build a fault tree", "Human" to "Run 5 Whys on the chain", "Systemic" to "Map causes on a fishbone". Anything recurring goes straight to the fishbone.
Two endings that are not a cause
Verification ends three ways and two of them are not a cause. "More evidence obtainable?" ends on "Exhausted" at "Close with a data limitation", where no technique's entry test is still met; "Cause within local control?" ends on "Beyond local" at "Escalate to formal investigation".
How it works
List the methods your team can actually run
Write down the four or five techniques someone here is trained in — 5 Whys, fishbone, fault tree, change analysis, FMEA — with one sentence each on the evidence they require. A decision tree that ends in a method nobody can run is a referral to a stranger, and it will be ignored.
Write the entry test for each method
State the condition that selects each technique: a reconstructable sequence for 5 Whys, several plausible categories for a fishbone, conditions that had to coincide for a fault tree, worked yesterday and broken today for change analysis. Those conditions become the diamonds, so they must be checkable rather than tasteful.
Type the questions as rows, answers as branches
Each diamond is one row: the question in Box text, Decision in the Shape column, the destination row numbers in Line to, and the answers in Line text in the same order. The three-way row carries three numbers and three labels, and the chart is unreadable the moment those two lists fall out of step.
Give every method row a stopping rule
A box that says only to run the technique will be run until the investigator gets bored. Put the stop condition in the step's comment field — the last cause this organisation can change — and draw a decision immediately after it, so a chain that splits has somewhere to be sent.
Draw the two endings that are not findings
A working tree needs an exit for evidence that has run out and an exit for a cause outside local control. Set the Shape column to Reject on the first and End on the second. Without the first, an investigator whose records have gone runs the nearest technique anyway with its entry test unmet — the one outcome a chooser exists to prevent.
Test it against three closed investigations
Take three closed analyses, walk each down the tree from its problem statement, and see whether it lands on the technique actually used. Where it does not, decide which of the two was wrong before changing either: an entry test that misroutes a case is a defect in the tree, and a case that took the wrong method is an investigation to re-open.
Frequently asked questions
Which root cause analysis method should I use?
It depends on the shape of the evidence, which is why the choice belongs in a decision tree rather than in a policy. A single failure with a reconstructable sequence suits 5 Whys. A recurring problem whose cause could lie in materials, method, machine or people suits a fishbone. A failure that required several conditions at once suits a fault tree. Something that worked until a known change suits change analysis. If the question is what could fail rather than what did, that is FMEA, not root cause analysis.
What is the difference between 5 Whys and a fishbone diagram?
5 Whys follows one causal chain backwards; a fishbone spreads candidate causes across categories. The difference that matters is structural. 5 Whys can only express a sequence, so it cannot hold two causes that both had to be present, while a fishbone holds dozens of candidates but says nothing about which of them operated. Used together, the fishbone is the divergent step and 5 Whys the convergent one, run down a single branch after the field has been narrowed.
How many whys is enough in a 5 Whys analysis?
Five is a mnemonic, not a rule. The chain stops at the last cause the organisation can change and would recognise as a cause: a specification, a control, a workload, a design choice. Two whys is sometimes enough and nine is sometimes still short. A chain that runs past the point of control and into philosophy has gone one why too far; a chain that splits into several plausible answers has stopped being a chain, which means the failure is multi-factor and the technique has run out.
Is human error ever a root cause?
Almost never, in the sense that acting on it changes anything. A person performing a task differently from the procedure is itself an event with a cause: an instruction that does not match the equipment, two similar containers side by side, a check scheduled at the eleventh hour of a shift. The usable test is whether the next competent person on that shift would have done the same thing, and where the answer is yes the name in the report is a date stamp on the failure rather than an account of it.