ControlStandard.Tools Get a free report

Glossary

Root Cause Analysis (RCA)

Root cause analysis (RCA) is a structured way to find the underlying cause of a problem — not just its symptoms — so a fix stops it coming back. It uses tools like the 5 Whys, fishbone diagrams and Pareto analysis to move from "what happened" to "why", and ends in a change with a named owner and a date.

Root cause analysis (RCA) is the practice of finding the real, underlying cause of a problem rather than reacting to its symptoms. The logic is simple: if you only treat the symptom, the problem comes back; if you remove the cause, it stops. RCA is used wherever recurring failures are expensive — manufacturing, software, healthcare, and operations. The American Society for Quality describes RCA as a collective term for the methods used to uncover the causes of problems, and the NHS treats it as a core method for learning from patient-safety incidents.

The common tools

RCA is a family of techniques, not a single recipe. The ones you will meet most:

  • The 5 Whys — ask "why?" repeatedly to trace one problem to its source. Best for single-cause problems.
  • The fishbone diagram — sort possible causes into categories so nothing is missed. Best for multi-cause problems.
  • Pareto analysis — the rule that roughly 80% of effects come from 20% of causes, used to decide which cause to tackle first.

A typical RCA defines the problem clearly, gathers evidence of what actually happened, uses one or more of these tools to identify the cause, then agrees a corrective action.

Why most RCAs fail

The usual failure is stopping at the first plausible answer, or turning the review into a hunt for who to blame — at which point people stop telling the truth and nothing is learned. Keep it blameless but accountable: separate what in the system allowed the problem from any question of individual fault, the way a good after-action review does.

The second failure is ending with insight but no change. RCA only pays back when the corrective action has a named owner and a date. When the same problem keeps recurring across projects, that is a signal the system — not the people — needs fixing, which is the drift tax at work. For the step-by-step method, see how to run a root-cause analysis.

Frequently asked

What are the main root-cause-analysis tools?
The three you will meet most are the 5 Whys, which drills into a single cause; the fishbone (Ishikawa) diagram, which sorts many possible causes into categories; and Pareto analysis, which decides which cause to tackle first. Safety-critical work adds more formal methods such as fault tree analysis, but most operational problems are solved with the first three.
What's the difference between a root cause and an immediate cause?
An immediate cause is the visible thing that triggered the problem, such as a late sign-off. A root cause is the underlying condition that allowed it, such as a hand-off with no step for setting a decision date. Fixing the immediate cause clears one instance; fixing the root cause stops the problem returning.
How do you keep a root-cause analysis blameless?
Separate what the system allowed from any question of individual fault, and make clear the session is looking for a fixable condition, not a person to punish. People give the honest account only when they trust the review won't be used against them. The American Society for Quality frames RCA as systemic problem-solving for exactly this reason.

Related

Term

The 5 Whys

The 5 Whys is a root-cause technique: you ask "why?" about five times in a row, tracing a problem back from its visible symptom to the underlying cause, so you fix what actually broke instead of the surface effect. Developed at Toyota, it suits single-cause problems and pairs well with a fishbone diagram.

 Term

Fishbone Diagram (Ishikawa)

A fishbone diagram — also called an Ishikawa or cause-and-effect diagram — is a visual tool that sorts the possible causes of a problem into categories, so a team can see every contributing factor at once instead of fixing the first thing they notice. Created by Kaoru Ishikawa, it is a staple of root-cause analysis.

 Term

After-Action Review (AAR)

An after-action review is a short, structured debrief that asks four questions: what was supposed to happen, what actually happened, why was there a difference, and what will we change? Originally a US Army practice, it turns experience into improvement — and works best when it's blameless but accountable.

 Guide

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

To run a root-cause analysis, define the problem precisely, gather evidence of what actually happened, map the possible causes with a fishbone diagram, drill into the likeliest one with the 5 Whys until you reach a cause you can change, then agree a corrective action with a named owner and a date. Verify later that it worked.

 Term

Lessons Learned

Lessons learned are the documented insights a team captures during or after a project — what worked, what didn't, and what should change — so the next piece of work benefits from the last. A core project-management practice, recognised by PMI and PRINCE2, it only pays back when a lesson becomes an actual change.

 Term

Just Culture

A just culture is an organisational approach to error that holds people accountable for reckless choices while treating honest mistakes as a signal to fix the system, not the person. Popularised by Sidney Dekker and David Marx, it replaces "who messed up?" with "what let this happen?" — so people report problems instead of hiding them.

← Back to the glossary