How to Run a Root-Cause Analysis: A Practical Step-by-Step

A root-cause analysis is worth running when a problem is expensive, likely to return, or keeps reappearing in new disguises. The goal is not to explain the problem — it is to find the one condition you can change so it stops.

What is a root-cause analysis?

A root-cause analysis (RCA) is a structured way to find the underlying cause of a problem rather than its symptoms, so a fix actually holds. The discipline matters because symptom-fixing feels like progress while changing nothing: you chase the late approval, soothe the unhappy client, patch the bug — and the same failure returns next month because its cause is still there. RCA replaces "make this go away" with "stop this happening again".

It is a cornerstone of safety-critical work for exactly this reason. The UK Health and Safety Executive treats identifying root causes — not just immediate causes — as the point of any incident investigation, because "if the root causes are not addressed, similar incidents are likely to recur."¹

Step 1 — Define the problem precisely

Write down what happened in one or two specific sentences, with facts: what, where, when, and how big. "Communication is bad" is not a problem statement; "the v2 build shipped three days late because the client sign-off arrived after the deadline" is. A vague problem produces a vague cause and a fix that changes nothing. Pin the symptom down before you reach for any tool.

Step 2 — Gather the evidence

Collect what actually happened before anyone theorises about why. Pull the timeline, the messages, the data, and — most valuable — the account of the people who were there. Do this before opinions harden, and do it blameless: you want the honest version, which you will not get if the session feels like a hunt for who to punish. Separate what the system allowed from any question of individual fault, the way a good after-action review does.

Step 3 — Map the possible causes with a fishbone

For anything with more than one plausible cause, start wide. A fishbone diagram sorts candidate causes into categories — people, process, tools, materials, environment — so the team examines all of them instead of anchoring on the first one mentioned. The aim here is breadth: surface every plausible contributor before judging any. Then pick the branch most likely to be driving the problem.

Step 4 — Drill to the root with the 5 Whys

Take the likeliest cause and go deep with the 5 Whys: ask "why did that happen?", then ask it again of each answer, until you reach a cause you can actually change. The 5 Whys was developed by Sakichi Toyoda and became part of the Toyota Production System, where the discipline of asking "why?" repeatedly is documented as the basis of Toyota's scientific approach to problem-solving (American Society for Quality, Five Whys).

1. The build shipped late. Why? Sign-off came after the deadline.
2. Why? The approver only saw it on the due date.
3. Why? It sat in their inbox with no decision date attached.
4. Why? We never agreed when a reply was needed when we sent it.
5. Why? Our hand-off has no step for setting a decision date.

The symptom was a late build. The root cause is a missing step in the hand-off — and that is the level at which a fix prevents the next slip. Five is a guide, not a target: stop when the next "why" would only invite guesswork or blame.

"Fixing the symptom feels like progress and changes nothing. Fixing the cause is the only repair that lasts." — The Control Standard

Step 5 — Agree a corrective action with an owner and a date

An analysis that ends in insight but no change is a tidy story about a problem that will recur. Convert the root cause into a specific corrective action, give it one named owner — not "the team" — and a date. If the fix is itself a small process change, that is exactly what good systemising looks like: making the work explicit and repeatable so the failure can't quietly return.

Step 6 — Verify the fix actually worked

Root-cause work isn't finished when the action is assigned; it is finished when the problem stops. Set a date to check that the corrective action was made and that the symptom hasn't returned. This closure step is the one most often skipped, and it is why so many "fixed" problems come back.

When the same problem keeps recurring

A single RCA repairs one event. The bigger prize is the pattern: when a similar problem keeps surfacing across projects, the system — not the people — is producing it, and that recurring cost is the drift tax in action. Deciding whether a repeated pain is worth turning into a permanent system fix — a checklist, a rule, an automation — is exactly what the free Pain Automation Score below helps you judge in about five minutes.

1. UK Health and Safety Executive, Investigating accidents and incidents (HSG245) — guidance on identifying immediate, underlying and root causes. ↩