Root Cause Analysis
Topic 5 of 12 · In Process Improvement · September 9, 2026
Apply 5 Whys, Fishbone diagrams, Pareto analysis, fault tree analysis, FMEA, scatter diagrams and hypothesis testing to find and fix the true causes of process problems.
Overview
Root cause analysis (RCA) is the practice of looking beyond symptoms to find the true underlying cause of a problem. Fixing a symptom — like retraining staff every time an error occurs — treats the visible effect but leaves the real cause untouched, guaranteeing the problem will return.
RCA is the "diagnose before you prescribe" phase of process improvement. A doctor who treats a fever without finding the infection is not practicing medicine — they are managing symptoms. Similarly, a process improvement project that implements solutions without confirming root causes is guessing. This topic equips you with six essential RCA tools and teaches you when to use each one.
Before You Start
- Complete Six Sigma Basics first; you will need the DMAIC framework, baselines and the idea of special-cause variation.
- Bring frequency or cost data on a recurring problem you want to diagnose so the Pareto exercise uses real numbers.
- Prepare the 6M categories (Man, Machine, Material, Method, Milieu, Measurement) so the fishbone session can start immediately.
- Have a calculator ready for the RPN, Pareto and simple hypothesis-testing checks.
- Write a crisp problem statement (what, when, where, how much) before the lesson begins — a vague problem produces a vague root cause.
Learning Objectives
- Apply the 5 Whys technique to peel back layers of symptoms
- Construct and analyze a Fishbone (Ishikawa) diagram
- Use Pareto analysis to prioritize causes by frequency or impact
- Build a fault tree for system-level failure analysis
- Conduct a basic Failure Mode and Effects Analysis (FMEA)
- Interpret scatter diagrams to identify correlations between variables
- Use basic hypothesis testing to validate suspected root causes
- Select the appropriate RCA tool for different problem types
Prerequisites
Complete Six Sigma Basics (DMAIC) first. You should understand the DMAIC framework, measurement and the concept of variation before diving into root cause tools.
The 5 Whys
The 5 Whys is the simplest RCA tool, developed by Sakichi Toyoda and used within Toyota. When a problem occurs, you ask "Why?" — and then ask "Why?" about each answer, typically five times, until you reach the root cause.
Example:
- Why did the customer receive a wrong order? — Because the picker grabbed the wrong item.
- Why did the picker grab the wrong item? — Because items A and B have nearly identical packaging.
- Why do items A and B have identical packaging? — Because the design team did not add a distinguishing visual indicator.
- Why was there no visual indicator? — Because the packaging review process does not include a "differentiability check."
- Why does the review process not include that check? — Because the packaging review checklist was created 5 years ago and has never been updated.
Root cause: outdated packaging review checklist. Solution: add a differentiability check to the checklist and audit it quarterly — not just retrain the picker.
Fishbone (Ishikawa) Diagram
The Fishbone diagram (also called the Ishikawa or Cause-and-Effect diagram) organizes potential causes into categories, resembling a fish skeleton. The problem (effect) is the head; the major cause categories are the bones; sub-causes branch off each bone.
Common categories (the 6M framework):
- Man (People) — skills, training, fatigue, communication
- Machine (Equipment) — tools, software, maintenance, calibration
- Material — inputs, supplies, data quality
- Method (Process) — procedures, policies, workflows
- Milieu (Environment) — physical workspace, culture, regulatory environment
- Measurement — metrics, data accuracy, monitoring systems
Steps to build a fishbone:
- Write the problem statement at the head (right side) of the diagram.
- Draw the main spine and label the category bones.
- Brainstorm causes within each category (use sticky notes in a team session).
- For each major cause, ask "Why?" to add sub-causes (at least two levels deep).
- Vote on the most likely root causes and validate with data.
Pareto Analysis
Pareto analysis applies the 80/20 rule: roughly 80 % of problems come from 20 % of causes. A Pareto chart is a bar chart sorted from highest to highest frequency, with a cumulative percentage line.
How to use it:
- Collect data on the frequency or cost of each problem type.
- Sort categories from highest to lowest frequency.
- Calculate cumulative percentage.
- Plot bars and cumulative line.
- Identify the "vital few" — the categories that account for the first 80 % of impact.
Pareto analysis ensures you fix the causes that matter most first, rather than spreading effort evenly across all problems.
# Pareto chart in Python
import matplotlib.pyplot as plt
import numpy as np
causes = ['Wrong item', 'Late delivery', 'Damaged packaging', 'Missing item', 'Invoice error']
frequency = [42, 28, 15, 10, 5]
total = sum(frequency)
cumulative = np.cumsum(frequency) / total * 100
fig, ax1 = plt.subplots(figsize=(10, 6))
ax1.bar(causes, frequency, color='steelblue')
ax1.set_ylabel('Frequency')
ax2 = ax1.twinx()
ax2.plot(causes, cumulative, 'ro-')
ax2.set_ylabel('Cumulative %')
ax2.axhline(80, color='red', linestyle='--', alpha=0.5)
plt.title('Pareto Chart — Customer Complaints')
plt.tight_layout()
plt.show()Fault Tree Analysis (FTA)
Fault tree analysis is a top-down, deductive method that starts with an undesired top event (system failure) and works backward through Boolean logic (AND/OR gates) to identify the combinations of basic events that could cause it.
Structure:
- Top event — the failure you are analyzing (e.g. "Server downtime")
- Intermediate events — contributing failures (e.g. "Database crash", "Network failure")
- Basic events — root-level failures that require no further decomposition (e.g. "Disk full", "Power outage")
- Gates — AND gate (all inputs must occur for the output to occur) and OR gate (any input can cause the output)
FTA is especially valuable in engineering, IT and safety-critical systems where understanding combinations of failures is essential.
Failure Mode and Effects Analysis (FMEA)
FMEA is a proactive risk assessment tool that identifies how a process or product can fail, what the effects would be, and how likely the failure is. Each potential failure mode is scored on three dimensions:
- Severity (S) — how serious is the impact if this failure occurs? (1–10 scale)
- Occurrence (O) — how likely is this failure to occur? (1–10 scale)
- Detection (D) — how likely is the current control to detect it before it reaches the customer? (1–10 scale)
Risk Priority Number (RPN) = S × O × D. The higher the RPN, the more urgent the action. Teams typically prioritize failure modes with RPN > 100 or severity ≥ 8.
| Failure Mode | Effect | S | O | D | RPN |
|---|---|---|---|---|---|
| Wrong item picked | Customer returns order | 7 | 6 | 4 | 168 |
| Label printed upside down | Cosmetic issue | 3 | 8 | 2 | 48 |
| Fragile item not padded | Item arrives broken | 9 | 4 | 5 | 180 |
Scatter Diagrams
A scatter diagram plots two variables against each other to visualize their relationship. The x-axis represents the suspected cause; the y-axis represents the effect.
Interpreting patterns:
- Positive correlation — as x increases, y increases (points trend upward to the right)
- Negative correlation — as x increases, y decreases (points trend downward to the right)
- No correlation — points are scattered randomly (no relationship)
Scatter diagrams are a quick visual check before running formal correlation or regression analysis. A strong visual pattern suggests a hypothesis worth testing statistically.
Hypothesis Testing for Root Cause
When you suspect a root cause, hypothesis testing provides statistical evidence to confirm or reject it:
- Null hypothesis (H₀) — there is no difference / no relationship (the suspected cause has no effect).
- Alternative hypothesis (H₁) — there is a difference / relationship.
- p-value — if p < 0.05 (typically), you reject the null hypothesis and conclude the suspected cause is statistically significant.
Common tests:
| Test | Use When |
|---|---|
| t-test | Comparing means of two groups |
| Chi-square | Testing association between two categorical variables |
| ANOVA | Comparing means across three or more groups |
| Correlation (Pearson) | Measuring the strength of a linear relationship between two continuous variables |
# Simple t-test to compare two groups
from scipy import stats
# Group A (with new process): resolution times
group_a = [12, 15, 11, 13, 14, 12, 16, 13, 11, 14]
# Group B (old process): resolution times
group_b = [18, 22, 19, 21, 20, 17, 23, 19, 22, 20]
stat, p_value = stats.ttest_ind(group_a, group_b)
print(f"t-statistic: {stat:.3f}, p-value: {p_value:.4f}")
if p_value < 0.05:
print("Statistically significant: the new process is faster.")
else:
print("No significant difference detected.")Selecting the Right RCA Tool
Each tool has strengths suited to different situations:
| Situation | Best Tool |
|---|---|
| Simple, linear problem with a clear starting point | 5 Whys |
| Broad brainstorming of causes across categories | Fishbone diagram |
| Prioritizing which causes to address first | Pareto analysis |
| Complex system with logical failure combinations | Fault tree analysis |
| Proactive risk assessment of a new or redesigned process | FMEA |
| Visual check of a suspected cause-effect relationship | Scatter diagram |
| Statistical confirmation of a suspected root cause | Hypothesis testing |
In practice, you often use multiple tools together: Fishbone to brainstorm, Pareto to prioritize, 5 Whys to drill into the top cause, and hypothesis testing to confirm.
Hands-On Practice
Take a recurring problem you face (at work, school or home):
- Write a clear problem statement: what, when, where, how much.
- Use the 5 Whys to explore one suspected root cause chain (at least 5 levels).
- Build a Fishbone diagram with all 6M categories, listing at least 3 causes per category.
- If you have frequency data on different types of this problem, create a Pareto chart.
- For your top suspected cause, design a simple scatter diagram using available data.
- Write a one-page RCA summary: problem, tools used, root cause identified, recommended action.
Deeper Worked Examples
Five Whys on invoicing price errors
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Pareto and mini-FMEA on delivery defects
Step 1
Step 2
Step 3
Step 4
Step 5
Step 6
Common Mistakes
- Stopping at the first 'why' — the root cause is rarely the most obvious answer
- Using only one RCA tool — combining tools gives a more complete picture
- Confusing correlation with causation — scatter diagrams show correlation; hypothesis testing confirms it
- Conducting RCA alone when the problem crosses multiple roles — involve the people who do the work
- Jumping to solutions before confirming the root cause with data
- Forgetting to validate — always test your suspected root cause before implementing a permanent fix
Real-World Usage
A SaaS company had a 25 % monthly churn rate. They used a Fishbone diagram with categories: Product, Sales, Onboarding, Support, Pricing, Competition. Pareto analysis of churn reasons showed that 70 % of churned customers cited "poor onboarding experience." 5 Whys drilling into onboarding revealed that new users received a 60-page PDF manual but no live walkthrough. A hypothesis test confirmed that customers who attended a live onboarding session churned at 8 % vs. 32 % for those who did not. The root cause was clear: the onboarding process was passive, not interactive. The fix — mandatory live onboarding for all new accounts — cut churn to 14 % within three months.
Mini Project
Business problem: A customer support team handles 500 tickets per week. 30 % are escalated to senior agents because the first-response agent could not resolve them. Escalation costs the company an extra $15 per ticket in labor.
Objective: Identify the root causes of excessive escalation and propose solutions.
Task 1
Task 2
Task 3
Task 4
Task 5
Task 6
Task 7
| Deliverable | What it proves |
|---|---|
| Escalation data + Pareto chart | You can identify the vital few causes |
| Fishbone diagram | You can brainstorm causes systematically across categories |
| 5 Whys chain | You can drill to a root cause |
| Statistical comparison | You can validate with data, not intuition |
| Mini-FMEA | You can proactively assess failure modes |
| RCA report | You can communicate findings and recommendations |
Key Takeaways
- Root cause analysis looks beyond symptoms to find the true underlying cause of problems
- The 5 Whys is a simple, powerful technique for drilling down through layers of causes
- Fishbone diagrams organize potential causes into categories for systematic brainstorming
- Pareto analysis prioritizes causes by frequency or impact to focus effort on the vital few
- Fault tree analysis models logical combinations of failures in complex systems
- FMEA proactively assesses failure modes using Severity × Occurrence × Detection = RPN
- Scatter diagrams visually reveal correlations between suspected causes and effects
- Hypothesis testing provides statistical confirmation of suspected root causes
- Combining multiple RCA tools gives a more complete and reliable picture
Key Terms & Glossary
| Term | Meaning |
|---|---|
| 5 Whys | Toyota's drill-down technique that asks 'why' repeatedly — typically five times — to move from a symptom to a root cause along one cause chain. |
| Fishbone (Ishikawa) diagram | A cause-and-effect diagram that organises potential causes under the 6M categories (Man, Machine, Material, Method, Milieu, Measurement) for systematic brainstorming. |
| Pareto analysis | An 80/20 prioritisation tool that sorts causes by frequency or cost and highlights the 'vital few' that account for the bulk of the problem. |
| Fault tree analysis | A top-down, deductive method using AND and OR gates to model the combinations of basic failures that produce a system-level top event. |
| FMEA and RPN | Failure Mode and Effects Analysis scores each failure on Severity, Occurrence and Detection; the product RPN = S x O x D ranks which risks demand action first. |
| Scatter diagram | A plot of a suspected cause against an effect, revealing positive, negative or no correlation as a visual hypothesis check before formal testing. |
Learning Resources
Root Cause Analysis — ASQ
Comprehensive guide to RCA tools, techniques and best practices from the American Society for Quality.
Root Cause Analysis: Simplified and Applied — Douglas Hubbard
A practical, no-nonsense guide to performing effective root cause analysis.
Root Cause Analysis (Coursera — University System of Georgia)
A focused course on RCA methods including 5 Whys, Fishbone and FMEA.
FMEA Tutorial (iSixSigma)
Step-by-step guide to conducting Failure Mode and Effects Analysis.
The Ishikawa Diagram — Kaoru Ishikawa
The original work by the creator of the fishbone diagram.
Chapter Quiz
Chapter Quiz — Root Cause Analysis
5 Whys, fishbone diagrams, Pareto, fault trees, FMEA, scatter diagrams and hypothesis testing.
Question 1 of 5
The 5 Whys technique works best when the problem is:
Knowledge Check
End-of-Topic Exam
Hint: Each 'why' must flow from the previous answer; the root cause should be a design or process gap, not the operator.
Model answer: Why 1: customers receive duplicate emails because the order system sends a confirmation and the marketing system triggers its own 'order received' email for the same event. Why 2: the marketing campaign fires on the same order-placed event without an exclusion rule. Why 3: the two systems were integrated by different vendors who each assumed the other would de-duplicate. Why 4: there is no documented event-ownership map for the order lifecycle. Why 5: the integration was never reviewed against a single source-of-truth definition. Root cause: email events are not centrally owned or de-duplicated. The countermeasure is to define one system of record for order events, add a de-duplication rule (one email per order ID per 24 hours), and document the event-ownership map — not simply to 'double-check before clicking send'.
Hint: Sort descending, accumulate percentages, and find where the cumulative line crosses about 80%.
Model answer: Sorted: unclear process 340 (48.6%), missing information 190 (75.7%), tool failure 90 (88.6%), complex case 60 (97.1%), other 20 (100%). The vital few are 'unclear process' and 'missing information', which together account for 75.7% of escalations — very close to the 80% bar. The team should attack those two before touching tool failure or complex case, because fixing them delivers the largest escalation reduction per unit of effort. The likely root causes sit in the method and measurement categories of a fishbone: poorly documented procedure screens and agents lacking a mandatory-information checklist.
Hint: Multiply S x O x D, then re-read the severity and detection scores before ordering the work.
Model answer: Wrong part picked: 8 x 5 x 9 = 360. Label upside down: 2 x 8 x 3 = 48. Fragile unpacked: 9 x 4 x 4 = 144. Acting on RPN alone, the team works on wrong part picked first (360), then fragile unpacked (144), then label upside down. However, label upside down has a detection score of 3, meaning current controls rarely catch it even though it happens often (O=8); its low RPN comes from a forgiving severity of 2. Teams still fix it because high-occurrence, low-detection modes drain customer patience and rework quietly, but it rightly ranks last when scarce resources exist — the severity-8 and severity-9 modes (unpacked fragile item carries legal and brand risk) are funded before the cosmetic one.
Hint: State the null and alternative hypotheses, pick a test, and define what p-value threshold forces a conclusion.
Model answer: State the hypotheses: null (H0) — overtime hours have no effect on picking errors; alternative (H1) — picking error rate rises with overtime hours. Define the variables: error rate per hundred picks (continuous) against hours of overtime worked in the prior week per shift. Use a correlation test (Pearson) if both variables are continuous, or a two-sample t-test comparing the mean error rate of high-overtime shifts against low-overtime shifts. Collect at least 20 shifts of data, run the test, and if the p-value comes out below 0.05, reject the null hypothesis and confirm overtime as a statistically significant driver; if the p-value is above 0.05, the manager must look elsewhere — and no training budget should be spent on a cause the data did not support.