Root cause analysis process map

A swimlane map of an RCA from problem statement and containment through evidence, cause analysis, verification and corrective action, across the facilitator, the process owner, the investigation team, quality and management. Containment comes first and verification comes before action: both are deliberate, and both are what most informal RCAs get backwards.

Open this map in the editor

Opens a copy in the editor and saves it in this browser. No account, nothing sent anywhere.

What is in this map

20 steps across 5 swimlanes and 5 phases, with 3 decision points.

Swimlanes (who does the work): Facilitator, Process owner, Investigation team, Quality and Management
Phases (left to right): Problem and containment, Evidence, Cause analysis, Verification and Corrective action

Why map this process

Root cause analysis fails in two predictable ways: the team fixes the first plausible cause without testing it, and the corrective action is agreed in a room and never implemented. The map is drawn against both. Verification sits between analysis and action, so an untested hypothesis cannot become a change; and the corrective action phase has an owner lane and a closure step, so an agreed action has somewhere to be chased.

Containment first is the other structural claim. While the analysis runs (days or weeks), the problem is still happening, and a process that goes straight to investigation is implicitly accepting that. Making containment a separate early step with its own owner separates 'stop the bleeding' from 'understand the wound', which are different jobs on different clocks.

Every step in the map

This is the spreadsheet behind the diagram. The numbers in “Goes to” are row numbers, which is exactly what the editor’s “Line to” column holds — so you can read the flow here and retype any part of it.

Every step in the Root cause analysis process process map, in the order the editor numbers them.
#	Step	Shape	Swimlane	Phase	Goes to
1	Problem raised for investigation	Start	Facilitator	Problem and containment	2
2	Describe the problem as observed	Process	Process owner	Problem and containment	3
3	Agree the problem statement	Process	Facilitator	Problem and containment	4
4	Apply immediate containment	Process	Process owner	Problem and containment	5
5	Assemble the investigation team	Process	Facilitator	Problem and containment	6
6	Collect data and physical evidence	Process	Investigation team	Evidence	7
7	Evidence sufficient to proceed?	Decision	Facilitator	Evidence	10 (Sufficient), 8 (Gaps), 9 (Unavailable)
8	Extend sampling and interviews	Process	Investigation team	Evidence	7 (Re-assess)
9	Close with documented data limitation	Reject	Quality	Evidence	End
10	Reconstruct the event timeline	Process	Investigation team	Evidence	11
11	Generate cause hypotheses	Process	Investigation team	Cause analysis	12
12	Test hypotheses against the evidence	Process	Investigation team	Cause analysis	13
13	Cause verified by evidence?	Decision	Facilitator	Verification	14 (Verified), 11 (Re-analyse), 8 (More data)
14	Separate root cause from contributing factors	Process	Investigation team	Verification	15
15	Review and challenge the conclusion	Process	Quality	Verification	16
16	Record the RCA findings	Document	Facilitator	Verification	17
17	Propose corrective actions	Process	Process owner	Corrective action	18
18	Actions approved and resourced?	Decision	Management	Corrective action	19 (Approved), 17 (Rework)
19	Open CAPA record and assign owners	Registry	Quality	Corrective action	20
20	Close the RCA record	End	Facilitator	Corrective action	End

The decision points

Every branch in the map, with the label on each outgoing line. These are the questions the process has to be able to answer.

7. Evidence **sufficient** to proceed?

Owned by Facilitator · Evidence
- Sufficient → step 10
- Gaps → step 8
- Unavailable → step 9
13. Cause **verified by evidence**?

Owned by Facilitator · Verification
- Verified → step 14
- Re-analyse → step 11
- More data → step 8
18. Actions **approved and resourced**?

Owned by Management · Corrective action
- Approved → step 19
- Rework → step 17

Notes on specific steps

These notes travel with the map. In the editor they live in the Notes column and appear when you open a box.

3. Agree the *problem statement*: State what happened, where, when, on how many units, and how far that is from what should have happened. Keep cause and blame out of it: a problem statement that already names a cause closes the investigation before it starts.
4. Apply **immediate containment**: Containment protects the customer today, it is not the fix. Record it separately with an owner and a review date so it is withdrawn once the corrective action is in place.
11. Generate cause hypotheses: 5 Whys suits a single linear chain owned by one team. Use a fishbone when several categories could contribute (method, machine, material, people, measurement, environment), so the team does not stop at the first plausible answer.
14. Separate *root cause* from contributing factors: A root cause is one you can remove so this problem cannot recur. A contributing factor made it more likely or worse. Both earn actions, but only the root cause closes the investigation.

Making it yours

This map is method-agnostic on purpose: the cause-analysis phase is one step that your chosen technique fills: five whys, fishbone, fault tree. Name the technique in the Notes column rather than expanding it into rows, because the technique is the part that changes per problem and the surrounding process is the part that should not.

What to watch out for

An RCA with no verification step is a guess with a document attached. If you cut one thing from this map, do not cut that one.
The facilitator and the process owner must stay in different lanes. The person who owns the failing process is the wrong person to run the analysis of it, and a single 'investigator' lane quietly removes that safeguard.
Effectiveness review happens after the corrective action has been live for a while, which means it is scheduled rather than immediate. Draw it, and put the interval in the Notes column, or it will be the step that never happens.

Frequently asked questions

When should an RCA be triggered rather than a quick fix?

The map does not answer that, and it should not: the trigger belongs to the process that found the problem. Incidents, complaints and quality failures each have their own threshold. What this map assumes is that once triggered, the analysis follows the same shape regardless of where it came from.

Can I use this for IT incidents as well as quality problems?

Yes. The lanes rename (facilitator becomes problem manager, quality becomes service management), but containment, evidence, analysis, verification and corrective action are the same five phases. That is why it is worth having one RCA map rather than one per department.

How many root causes should an analysis end with?

As many as survive verification, which is often more than one and occasionally none. The map allows for that: the verification decision can send the analysis back for more evidence, and a branch that loops is a more honest representation of investigation than a straight line to a single answer.

Open the map and start editing

The editor loads this chart with the spreadsheet underneath it. Change a cell and the diagram redraws — no drawing, no signup.

Open this map in the editor