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 root cause analysis flowchart is a decision tree that routes an investigator to the technique the available evidence can actually support (5 Whys, a fishbone, a fault tree) and says where each one stops.
The short version
- One output: the technique to open, not a narrative of the investigation.
- 5 Whys assumes one chain and fails quietly whenever there is more than one.
- Reach for a fishbone when the cause could sit in any of several categories.
- A fault tree earns its cost only when several conditions had to coincide.
- Naming a person is where an analysis stopped early, not where it finished.
A method chooser, not an investigation diary
Search for a root cause analysis flowchart and nearly everything returned is an investigation diary: define, collect, analyse, verify, act. It is accurate and it is useless, because nobody has ever been stuck on the order of those five words. What investigators are stuck on is which technique to open, and a chart that does not answer that has drawn the easy half of the job.
Apply 5 Whys to a failure that needed three conditions to coincide and it still produces five tidy lines: wrong, confident, and now written down. A fishbone assumes categories and cannot express dependency; a fault tree expresses dependency but needs a defined top event. One branch therefore has to sit upstream of all three: does the evidence describe a single chain of events, or several candidate causes? Put it there and technique stops being a matter of taste.
The example below decides more than it narrates: nine of its nineteen rows are questions, and three of its four endings stop short of a cause. The arrows that matter run backwards. "Reached a controllable cause?" sends a chain that has split back to "Map causes on a fishbone" (an admission mid-analysis that the method was wrong), and "More evidence obtainable?" returns to "Collect records and interviews" rather than letting a hypothesis be filed as a finding.
From evidence to a chosen method
Five phases, and no technique is picked before the third: watch "Failure nature?" route "Technical", "Human" and "Systemic" to three different methods.
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.
Mistakes to avoid
5 Whys on a multi-cause failure
The technique cannot represent two conditions that both had to be present, so it silently picks one and follows it. What comes out is a single chain that reads convincingly and removes part of the cause.
Choosing the technique first
The method arrives with whoever was assigned, and the evidence is then read to suit it. Keep the sufficiency and structure questions upstream of every method box so the facts make the choice.
Stopping at the name of a person
An analysis that ends with somebody performing a task incorrectly has found the last event, not the cause. Ask what made that performance likely: the instruction, the layout, the workload, the handover.
Opening a method with no exit criterion
Without a stated stopping rule, a why-chain runs on to philosophy or to blame, and a fishbone becomes a list of everything anyone dislikes about the process. Write the rule onto the step itself.
Build your own RCA decision tree
Open the method decision tree as your own chart and set the tests your investigators use to choose between techniques.
Related guides
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.