How to Run a Root Cause Analysis Investigation

Symptoms vs Root Cause

When a machine fails or a defect appears, the fast fix addresses the symptom, and the problem returns. RCA digs deeper: it keeps asking why until it reaches a cause that, if corrected, stops the problem from happening again. The goal is a permanent fix, not a recurring firefight.

Common RCA Methods

• 5 Whys: repeatedly asking why to trace a cause chain.
• Fishbone diagram: mapping possible causes by category.
• Fault-tree analysis: working backward from a failure logically.
• Corrective action: verifying the fix actually prevents recurrence.

RCA is central to continuous improvement and pairs with Lean Six Sigma and inspection methods like nondestructive testing.

Five Whys and Fishbone Diagrams

The five whys drills down through a chain of causes, and fishbone diagrams organize possible causes by category. Both need facts, not guesses.

Verify each cause with evidence.

Preserving Evidence

Collect data, photos and statements early. Conditions change quickly after an event.

Interview without blame.

Corrective and Preventive Actions

Actions should address the root cause and be tracked to completion. Verify that the fix works.

Share lessons learned.

Building the Right Team

Include people who do the work, not only managers. Their knowledge of the process reveals causes that data alone may miss.

Keep the tone focused on learning, not blame.

Verifying the Cause

A likely cause should be tested before acting. Look for evidence that removing it removes the problem.

Guessing wastes effort and can create new issues.

Following Up After the Fix

Check later that the problem has not returned. Track the measure that first alerted you.

Share lessons across teams.

What the Method Is For

Root cause analysis is a structured approach to finding why a problem occurred so that a correction prevents recurrence rather than addressing the visible symptom.

Organizations that skip it accumulate a history of repeated incidents with the same underlying cause and different surface descriptions each time.

The discipline is in continuing past the first plausible explanation, which is where most investigations stop because the first explanation is usually satisfying and usually incomplete.

Defining the Problem

An investigation is only as good as the problem statement, and vague statements produce vague conclusions that cannot be acted on.

A usable statement specifies what happened, where, when, how often and what the measurable effect was, without embedding a suspected cause in the description.

Embedding a cause in the problem statement narrows the investigation before evidence is gathered, which is the most common way an analysis goes wrong at the start.

Gathering Evidence

Evidence includes physical evidence, records, process data and accounts from the people involved, and each degrades or changes at a different rate.

Physical evidence and witness recollection are both perishable, which is why early collection matters more than early conclusion.

People describe what actually happened only when the process is not being used to assign blame, and an investigation perceived as punitive returns unreliable information.

Analysis Techniques

Repeated questioning of why a condition existed is simple and works for straightforward problems where a single causal chain exists.

Cause and effect diagrams organize possible contributors across categories and are useful when the causes are unknown and numerous.

Fault tree analysis and structured causal factor charting suit complex incidents with multiple interacting contributors, and choosing a technique heavier than the problem wastes effort without improving the answer.

Reaching Actual Causes

Most investigations that stop at operator error have stopped too early, because the useful question is why the error was possible and why it was not caught.

System conditions including design, procedure quality, training, workload, supervision and time pressure are where durable corrections are usually found.

An analysis that produces only a recommendation to retrain or remind people has generally failed to reach a cause that can be controlled.

Corrective Action and Verification

Corrective actions need owners, dates and a defined way of confirming they were implemented and that they worked.

Verification after a defined interval is the step most frequently skipped, which leaves organizations with a list of actions rather than evidence of improvement.

Applicable regulations, quality system requirements and employer procedures define what must be investigated and documented, and those requirements should be confirmed for the specific setting.

Common Mistakes and How to Avoid Them

Recurring errors include stating the problem with a cause already embedded, stopping at operator error, running an investigation in a way that discourages honest accounts, and closing corrective actions without verifying they had any effect.

Supervisors can help by making it acceptable to pause and ask. A culture where questions are treated as competence rather than weakness produces fewer errors in root cause analysis.

How Employers Evaluate Readiness

Organizations assess this through recurrence rates for the same problem, the quality of investigation documentation, how many corrective actions address system conditions rather than behavior, and whether verification actually takes place.

Keeping Skills Current

Processes, equipment and staffing change over time. Reviewing whether earlier corrective actions still apply prevents maintaining controls designed for conditions that no longer exist.

Planning and Preparation

Preparation includes preserving evidence before conditions change, assembling people who understand the process rather than only managers, agreeing the scope of the investigation and establishing that the purpose is cause finding rather than attribution of blame.

Documentation That Holds Up

The problem statement, evidence collected, the causal analysis itself, corrective actions with owners and dates, and verification results are what allow a later reviewer to judge whether the conclusion was sound.

Where This Fits

This page covers one angle of a broader topic. For the full treatment, start with Root Cause Analysis: Tools Like 5 Whys and Fishbone and come back here for the detail specific to this page.

Frequently Asked Questions