Root cause analysis flowchart (decision tree template)
A root cause analysis flowchart drawn as a decision tree: nine tests route a problem to 5 Whys, a fishbone, a fault tree, escalation or a documented stop.
How it works
Rename the lanes to your actual decision-makers
The lanes here are decision rights, not departments: Process owner, Investigation lead, Quality reviewer, Management. Replace them with the roles that genuinely answer each question in your organisation, and keep the investigation lead separate from the process owner where you can. An investigation led by the person accountable for the process tends to settle on causes that are comfortable to state.
Write the problem statement rule on the first gate
"Problem clearly defined?" only works if someone has said what defined means. The usual test is that the statement gives what failed, where, when and how often, and names no cause at all. A statement that already contains the cause — most often some version of operator error — turns the rest of the tree into a confirmation exercise.
Set the sufficiency threshold on the data gate
Decide what "Data sufficient to analyse?" requires before you need it: a timeline that can be reconstructed, retained samples or logs still inside their retention window, and at least one first-hand account. Flag the perishable items, because those set how fast collection has to happen. Without a written threshold the Insufficient branch is never taken and the method is chosen on whatever happened to be at hand.
Fix your own method-selection rules
The routing in this chart — Recurring to a fishbone, Technical to a fault tree, Human to 5 Whys, Systemic to a fishbone — is a defensible default, not a law. Adjust it to the techniques your people are actually trained in, and add any you use, such as change analysis or barrier analysis. What matters is that the rule exists and is visible on the diagram, so the choice can be challenged in review.
Define the 5 Whys stop rule and the way out
"Reached a controllable cause?" is the node that stops a 5 Whys running into the weather or the economy. Stop at the last cause your organisation can change. If the chain runs out before that, or splits into several plausible answers, the problem is multi-factor and the No branch moves it onto a fishbone rather than letting a thin chain through.
Agree the escalation trigger and keep both diagrams versioned
Write down what forces "Cause within local control?" to the Beyond local branch: causes owned by another site, a supplier or a policy this team cannot change; events reportable to a regulator or customer; anything involving safety or product already shipped. Then link this decision tree to the end-to-end root cause analysis process flowchart, and keep both under version control with their approvals captured, so investigators and reviewers work from the same authorised version.
Frequently asked questions
Is a root cause analysis flowchart a process map or a decision tree?
It can be either, and the two answer different questions. A process map answers what happens next and who does it: raise the problem, contain it, collect evidence, analyse, verify, hand into CAPA. A decision tree — this page — answers which technique to apply and who decides, and its branches end in different outcomes rather than converging on one path. Most organisations need both: the process map for the procedure, the decision tree for the judgement calls inside it. If you want the end-to-end flow, use the root cause analysis process flowchart at /templates/root-cause-analysis-process.
How do I choose between 5 Whys, a fishbone and a fault tree?
By the shape of the problem, which is what the two method decisions in this chart test. 5 Whys suits a single causal chain owned by one team, where each answer becomes the next question. A fishbone, or Ishikawa diagram, suits a problem where several categories could be involved — method, machine, material, people, measurement, environment — because it forces the team past the first plausible branch. A fault tree suits a technical failure with a definable top event and components whose failure logic you can work backwards through. A recurring pattern almost always deserves a fishbone first, since recurrence usually means conditions rather than a one-off chain. Many investigations use two: generate candidates on a fishbone, then run 5 Whys down the branch the evidence supports.
What happens when the 5 Whys does not reach a cause we control?
That is what the "Reached a controllable cause?" decision is for. If the chain runs past anything your organisation can change, or forks into several equally plausible answers, the No branch moves the problem onto a fishbone instead of accepting the last link as the root cause. This is the most common failure mode in practice: a chain is followed until it reaches something unarguable but unactionable, such as market pressure or human nature, and an action gets written against it anyway.
What should the flowchart do when the evidence is gone?
Give it a named outcome rather than leaving it as a gap. This tree has two. Before the analysis, "Data sufficient to analyse?" can send the case to "Return to evidence collection", which pauses rather than proceeding on thin data. After the analysis, when a cause is still only a hypothesis, "More evidence obtainable?" either loops back to collection or ends at "Close with a data limitation". Closing with a stated limitation is a legitimate result and normally generates an action of its own: make the missing data available next time.
Does any standard require a particular root cause analysis method?
The common management system standards require you to determine the causes of a nonconformity and to act so it does not recur, but they do not prescribe how. ISO 9001 clause 10.2 is written that way, and ISO 13485 takes the same approach for corrective and preventive action. That leaves the method choice to you — which is precisely why it is worth documenting. A decision tree like this one, with the tests written on the nodes, shows an auditor that the technique was selected against stated criteria rather than by preference, and the answer stays consistent whoever runs the investigation.