Root cause analysis flowchart (decision tree template)

What the root cause analysis flowchart (decision tree template) process is

Two different diagrams get called a root cause analysis flowchart. One is a process map: it answers what happens next and who does it, running from the problem being raised through containment, evidence collection, analysis, verification and the handover into corrective action. That one is the root cause analysis process flowchart at /templates/root-cause-analysis-process. This page is the other kind: a decision tree. It answers which technique to use on the problem in front of you, and who has the authority to decide.

The distinction matters because the techniques are not interchangeable. 5 Whys follows a single causal chain and works when one team owns that chain end to end. A fishbone, or Ishikawa diagram, spreads the search across categories (method, machine, material, people, measurement, environment) and suits problems where several factors plausibly combine. A fault tree works backwards from a defined failure through the logic of how components and conditions produce it, which fits technical failures with a specification to test against. Left undecided, the method defaults to whichever one the facilitator ran last time, and the investigation quietly inherits that tool's blind spot.

The chart below is nine questions and four endpoints, laid out across four lanes that name who answers each question rather than who does the work. The questions run from whether the problem is bounded, through whether the evidence already exists and whether it is sufficient, to whether this is a single event or a recurring pattern and whether the failure is technical, human or systemic. Branches end in four named outcomes: a cause accepted and a CAPA raised, an escalation to a formal investigation, a return to evidence collection, and a close with a documented data limitation. Nothing funnels back into one happy path, because a real investigation does not always end with a proven cause.

What this flowchart covers

In this template

• Four decision-rights lanes (Process owner, Investigation lead, Quality reviewer and Management) across five stages: Frame the problem, Check the evidence, Choose the method, Run the analysis, and Verify and decide.
• Two entry gates before any technique is chosen: "Problem clearly defined?" returns a No to bound the problem statement and re-asks, and "Evidence already available?" splits Available from Must gather so collection is a step rather than an assumption.
• A "Data sufficient to analyse?" gate owned by the Quality reviewer, whose Insufficient branch terminates in "Return to evidence collection" instead of allowing a method to be picked on thin data. The sufficiency test is written on the node as a comment.
• The method selector itself: "Single event or recurring?" sends Recurring straight to a fishbone, and "Failure nature?" routes Technical to a fault tree, Human to 5 Whys and Systemic to a fishbone.
• A "Reached a controllable cause?" check after the 5 Whys: Yes goes on to verification, No re-routes the problem onto a fishbone rather than accepting a chain that ran past anything the organisation can change.
• The closing split: "Cause verified by evidence?" separates Verified from Hypothesis, "More evidence obtainable?" either loops back to collection or closes with a documented data limitation, and "Cause within local control?" ends in either "Cause accepted, CAPA raised" or "Escalate to formal investigation".

When to use this template

• Investigations use whichever technique the facilitator happens to know, and you want the method chosen from the problem rather than from habit.
• You are writing or revising an RCA or problem management procedure and need the method-selection rules recorded next to the process steps.
• Teams keep running 5 Whys on multi-factor problems and stopping at the first answer that sounds plausible.
• You need a defined way to stop (a documented data limitation or an escalation) instead of a speculative cause written to close the record.
• You want the escalation trigger agreed in advance, so causes that sit with a supplier, another site or a policy leave the local team instead of stalling inside it.

How it works

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.