---
name: root-cause-analysis
description: Use when asked to investigate why a problem happened, rather than just its symptoms — the identify/gather-data/analyze/identify-cause/plan/implement steps of root cause analysis (RCA) — used across engineering, manufacturing, healthcare, software, and business management.
---

# Root Cause Analysis (RCA)

Root cause analysis (RCA) is a problem-solving technique used to identify
the underlying causes of an event, rather than just treating its
symptoms — aiming to prevent similar problems from recurring, and widely
used across engineering, manufacturing, healthcare, software development,
and business management.

## Steps

1. **Identify the problem** — define what needs to be solved, including
   its symptoms, its impact on the system, and the timeline of events
   leading up to it.
2. **Gather data** — collect relevant information: observing the problem
   in action, reviewing documents and records, interviewing stakeholders.
3. **Analyze data** — determine causes and effects, using a timeline of
   events, cause-and-effect diagrams (see
   [[cause-and-effect-diagram]], [[fishbone-diagram]],
   [[ishikawa-diagram]]), or statistical analysis (see
   [[statistical-analysis]]).
4. **Identify the cause** — the root cause is the underlying factor (or
   factors) that, if removed or changed, would prevent the problem from
   recurring — distinct from the immediate, visible symptom that
   triggered the investigation.
5. **Develop a plan** — create a corrective action plan targeting the
   root cause specifically, not just the symptom.
6. **Implement the plan** — this may involve changes to policies and
   procedures, training programs, equipment modifications, or other
   concrete measures.

## Why root cause matters, not just symptoms

Treating symptoms without finding the root cause tends to produce
recurring problems — the same failure keeps resurfacing in slightly
different forms because the actual underlying condition was never
addressed. Identifying the true root cause lets a team implement a
targeted, durable fix instead of a series of short-term patches.

## Common pitfalls

- **Stopping at the first plausible cause** — the first explanation found
  is often a contributing factor or a symptom itself, not the true root
  cause; techniques like the "five whys" or a structured
  [[cause-and-effect-diagram]] help push past the first answer.
- **Skipping data-gathering in favor of assumption** — jumping straight
  from "identify the problem" to "identify the cause" without actually
  collecting evidence risks confirming a bias rather than finding the
  real cause.
- **No corrective action plan** — identifying the root cause without
  following through to a concrete, implemented fix leaves the
  investigation's value unrealized.
- **Treating RCA as blame-assignment** — a root cause analysis focused on
  finding a person to blame, rather than a systemic condition to fix,
  tends to produce worse data (people become less forthcoming) and a
  less durable fix.

## Learn more

- [[cause-and-effect-diagram]], [[fishbone-diagram]], [[ishikawa-diagram]] for structuring the analysis step.
- [[statistical-analysis]], [[anomaly-analysis]] for data-driven approaches to identifying causes.
- [[causal-analysis-based-on-system-theory]] for a more systems-oriented alternative approach to causal investigation.