Root Cause Analysis

Move from symptoms and blame to verified causal factors and stronger actions that reduce recurrence.

In one minute

Root Cause Analysis (RCA) is a structured investigation. It asks:

1. What happened?
2. What conditions and actions made it possible?
3. Which causal claims are supported by evidence?
4. What system change would reduce the chance or impact of recurrence?
5. How will we know the action worked?

RCA is an umbrella process that can use timelines, change analysis, barrier analysis, 5 Whys, Ishikawa diagrams, Pareto charts and other tools. Complex events may have several interacting causes.

Best for: recurring problems, significant failures, near misses and unexplained performance shifts.
Avoid when: immediate containment is still incomplete or the “analysis” is intended to confirm a person to blame.

The problem it addresses

Teams often treat a visible symptom, such as retraining an employee after an error, while the conditions that shaped the error remain unchanged. The problem returns in the same or a different form.

The intended outcome is a verified causal explanation, proportionate corrective actions and follow-up evidence.

When to use it

• a problem recurs after previous fixes;
• an incident had or could have had serious consequences;
• a process shifts without an obvious explanation;
• several teams or controls were involved;
• the cost of recurrence justifies investigation;
• a near miss exposes a system vulnerability.

When not to use it

Do not start a full RCA:

• before making the situation safe or containing customer harm;
• for every minor, isolated variation;
• when the event and scope have not been defined;
• to replace specialist safety, legal or forensic investigation;
• when evidence has been lost and the team intends to fill gaps with certainty;
• if leaders will not protect a fact-finding, non-retaliatory process.

For safety-significant or regulated events, this guide is only an orientation. Preserve evidence, follow the governing incident or CAPA process and involve qualified legal, safety, quality or technical specialists. A learning method cannot determine product disposition, regulatory reportability or legal responsibility.

Inputs required

• a precise problem statement and consequence;
• event, baseline and comparison data;
• a timeline of what happened;
• people who know the work as performed;
• relevant procedures, logs, system records and physical evidence;
• known changes before the event;
• existing controls and their intended purpose;
• authority to implement and verify corrective actions.

Step-by-step process

1. Contain and preserve

Protect customers, people and operations. Preserve logs, artefacts and time-sensitive observations. Containment is not the permanent fix.

2. Define the problem

Describe what, where, when, extent and consequence. Avoid causes in the problem statement.

Weak: “Complaints rose because agents were careless.”
Better: “Billing complaints increased from 4% to 7% of invoices in May across two service teams.”

3. Build the event timeline

Separate observed events from interpretations. Include normal conditions, changes, decisions, control points and recovery actions.

4. Gather perspectives and evidence

Interview people close to the work and compare accounts with records. Ask what made each action reasonable at the time; do not use hindsight as proof.

5. Generate causal hypotheses

Use more than one lens where appropriate:

• 5 Whys for a focused chain;
• Ishikawa for a broad cause set;
• change analysis for performance shifts;
• barrier analysis for failed prevention or detection;
• Pareto for measured concentration.

6. Test causal claims

For each candidate cause, ask:

• Is there evidence it existed?
• Is there a credible mechanism?
• Does it explain the timing and pattern?
• What alternative explanation was considered?
• Would changing it reduce recurrence or consequence?

7. Select corrective actions

Prefer actions that change the system: design, constraints, automation, standard work, feedback or effective controls. Training and reminders may support a change but are often weak when used alone.

8. Assign and verify

Define owner, due date, implementation evidence, outcome measure and monitoring period. Close the analysis only after effectiveness is checked.

Visual model

Text alternative: define the problem, gather timeline evidence, form hypotheses and verify them. Verified causes lead to corrective actions and effectiveness measurement; weak results return the team to the causal analysis.

Interactive example

Scenario

Customer complaints about incorrect appointment reminders increased by 35% in one month.

Initial explanations:

• “The support team needs retraining.”
• “The reminder service became unreliable.”
• “Customers are entering bad phone numbers.”

Available evidence:

• the increase started two days after a scheduling release;
• delivery success remained at 99.2%;
• wrong appointment times cluster in rescheduled bookings;
• a new event handler writes the updated time to one table but the reminder job reads another.

Your move

Which explanation is currently best supported, and what should the team do before declaring a root cause?

Worked answer

The strongest hypothesis is a data-consistency defect introduced by the release, because timing, clustering and system behaviour align. The team should reproduce the path, inspect records for affected and unaffected bookings, test the handler and reminder read model, and rule out relevant alternatives.

“Support needs retraining” is not supported by the evidence. Even after verification, the team should identify why integration tests and monitoring did not detect the inconsistency; the code defect may be an immediate cause, not the only system vulnerability.

Facilitation notes

• Include people who perform and support the process.
• Keep containment actions separate from corrective actions.
• Use neutral language and replace “who failed?” with “what conditions shaped the outcome?”
• Record uncertainty instead of forcing one neat root cause.
• Have an independent reviewer challenge causal logic for significant events.

Expected output

• a scoped problem statement;
• a factual timeline;
• evidence and unresolved gaps;
• verified causal and contributing factors;
• rejected alternatives and reasons;
• corrective actions linked to causes;
• implementation and outcome measures;
• review date and lessons that apply elsewhere.

Common mistakes

1. Naming human error as the root cause.
2. Stopping at the first plausible explanation.
3. Confusing correlation with causation.
4. Using only one analysis tool.
5. Selecting training as the default action.
6. Ignoring failed detection or mitigation barriers.
7. Closing the RCA when actions are assigned rather than verified.

Quality checklist

• Immediate harm was contained.
• The problem statement contains no assumed cause.
• Facts, interpretations and assumptions are labelled.
• People close to the work contributed.
• Alternative causes were tested.
• Each causal claim has evidence and a mechanism.
• Actions address the relevant system condition.
• Effectiveness measures and review dates are defined.

Template

Knowledge check

Which statement is the strongest causal claim?

A. “The operator was inattentive.”
B. “The incident happened after the update.”
C. “The update caused the incident because a reproduced data path wrote and read different appointment times, matching every affected record.”
D. “The team believes the system is unreliable.”

Answer: C. It combines temporal fit, a mechanism, reproduction and pattern evidence.

Related tools

• Supported by: 5 Whys, Ishikawa Diagram
• Often combined with: Pareto Analysis, PDCA
• More advanced than: treating a single symptom
• Not to be confused with: incident containment or assigning accountability

References

1. American Society for Quality. “Root Cause Analysis.” ASQ overview (opens in a new tab). Authoritative professional overview of RCA as a family of approaches.
2. U.S. Department of Energy. Root Cause Analysis Guidance Document, DOE-NE-STD-1004-92. DOE standard record (opens in a new tab). Archived historical guidance, not a current governing standard. Retained only for methodological history.
3. National Patient Safety Foundation. RCA²: Improving Root Cause Analyses and Actions to Prevent Harm, Version 2, 2016. IHI-hosted report (opens in a new tab). Authoritative systems-focused guidance; healthcare context.
4. American Society for Quality. “Problem Solving.” ASQ process overview (opens in a new tab). Professional guidance on defining, diagnosing, acting and sustaining results.
5. NASA Office of the Chief Engineer. “SWE-204 — Process Assessments,” NASA Software Engineering Handbook, Version D. Current handbook page (opens in a new tab). Active independent government guidance on timelines, causal factors, systemic process weaknesses, corrective actions and effectiveness evidence; its scope is high-severity software non-conformance.

Sources reviewed 27 July 2026.