From Symptoms to Root Causes
Descriptive analysis told you what happened. Now you find out why.
A production line slows down. Customer complaints spike. A project runs over budget. These are symptoms. Diagnostic analysis asks the harder question: what actually caused this? Without a rigorous answer, organisations treat symptoms — spending resources on solutions that leave the underlying problem untouched.
Fishbone (Ishikawa) Diagram
Maps potential causes of a problem across six standard categories: People, Process, Equipment, Material, Method, Environment.
5 Whys
Iterative questioning technique. Ask "why?" five times in sequence to drill past surface explanations to the root cause.
Pareto Analysis (80/20)
Identifies the "vital few" causes — typically 20% of causes that produce 80% of the effect. Prioritises where to act first.
Correlation Analysis
Quantifies the strength of the relationship between two variables. Helps identify which factors move together with the problem.
Scatter Plot Analysis
Visualises the relationship between two numeric variables. Reveals direction, strength, and whether the relationship is linear.
Process Mapping
Documents a workflow visually to identify where failures, delays, or inefficiencies occur within a sequence of steps.
Cause-and-Effect Matrix
Rates potential causes by their impact score, combining structured thinking with numerical prioritisation.
FMEA
Failure Mode and Effects Analysis. Identifies potential failure points and calculates their Risk Priority Number (RPN = Severity × Occurrence × Detection).
Correlation analysis (Technique 04) identifies variables that move together — it does not prove one causes the other. A strong correlation is a starting point for further investigation, never a conclusion. Causation requires the deeper methods covered in Sets 04 and 05.
Fishbone Diagram & 5 Whys
Two structured methods that turn vague frustration into specific, actionable root causes.
Fishbone (Ishikawa) Diagram
The fishbone diagram gets its name from its shape: a horizontal "spine" representing the problem, with diagonal "bones" branching off representing categories of causes. It was developed by quality engineer Kaoru Ishikawa and is now standard in manufacturing, healthcare, and service industries worldwide.
The six standard categories — remembered with the mnemonic 6M — are: Man (People), Machine (Equipment), Material, Method, Measurement, Mother Nature (Environment). In service environments these are often adapted to: People, Process, Technology, Policy, Place, Procedure.
5 Whys Method
The 5 Whys is the simplest root cause technique. Start with a problem statement and ask "why?" — each answer becomes the next question. Five iterations typically reach a root cause that is actionable, rather than a symptom.
| Iteration | Question | Answer |
|---|---|---|
| Why 1 | Why did the machine stop? | The fuse blew due to an overload. |
| Why 2 | Why was there an overload? | The bearing was not lubricated properly. |
| Why 3 | Why was it not lubricated? | The lubrication pump was not working. |
| Why 4 | Why was the pump not working? | The pump's intake shaft was worn. |
| Why 5 | Why was the shaft worn? | There was no maintenance schedule or filter on the pump. |
Root cause identified: No preventive maintenance schedule. Fix: implement scheduled maintenance and install a filter — not replace the fuse.
The 5 Whys works best for simple, linear cause chains. When a problem has multiple interacting causes (which most complex business problems do), a fishbone diagram or FMEA is more appropriate — it forces you to explore all categories simultaneously rather than pursuing a single thread.
Pareto Analysis — The 80/20 Rule
Not all causes are equal. A small number of causes produce the majority of the effect.
The Pareto Principle, named after Italian economist Vilfredo Pareto, states that in many systems, roughly 80% of effects come from 20% of causes. In business diagnostics this translates to: a small number of failure types, complaint categories, or defect causes are responsible for most of the problem.
Pareto analysis is not a precise law — sometimes it is 70/30 or 90/10. What it reliably tells you is that causes are not equal, and acting on the top contributors delivers far more return than addressing all causes equally.
A service manager has 1,200 complaints to address. Instead of allocating resources equally across all complaint types, she runs a Pareto analysis and discovers that two categories — Late Delivery and Wrong Item — account for 63% of all complaints. Solving just these two issues eliminates over half the complaint volume.
How to build a Pareto chart
| Step | Action | Purpose |
|---|---|---|
| 01 | List all causes/categories and count their frequency | Establishes the raw data |
| 02 | Sort from highest to lowest frequency | Required for the visual to work correctly |
| 03 | Calculate each category's % of total | Identifies individual contribution |
| 04 | Calculate cumulative % as you move down the list | This is the key line — shows where 80% is crossed |
| 05 | Draw bars (frequency) + line (cumulative %) | Creates the dual-axis Pareto chart |
| 06 | Draw a horizontal line at 80% on the cumulative axis | Everything to the left of where the line crosses is your "vital few" |
Correlation & Scatter Plot Analysis
Quantify and visualise the relationship between two variables — as a starting point for root cause investigation.
Correlation analysis produces a correlation coefficient (r) between −1 and +1. It measures both the strength and direction of a linear relationship between two numeric variables.
| r value | Strength | Direction | Business interpretation |
|---|---|---|---|
| +0.9 to +1.0 | Very strong | Positive | As X increases, Y almost always increases too. Very strong association worth investigating. |
| +0.6 to +0.9 | Strong | Positive | A clear positive pattern — X is likely a meaningful driver of Y. |
| +0.3 to +0.6 | Moderate | Positive | Some relationship, but other factors also matter. |
| −0.3 to +0.3 | Weak / None | Mixed | Little evidence of a linear relationship. |
| −0.6 to −0.3 | Moderate | Negative | As X increases, Y tends to decrease. |
| −1.0 to −0.6 | Strong | Negative | Strong inverse relationship. |
Ice cream sales and drowning rates are strongly correlated. Both increase in summer — because of the heat, not because ice cream causes drowning. A correlation tells you two variables move together. It does not tell you why, or which causes which. Always ask: is there a third variable (confounder) that explains both?
Scatter Plot — what to look for
Positive correlation
More training hours → higher performance scores. Points cluster around an upward-sloping line.
Negative correlation
More machine age → fewer units produced. Points cluster around a downward-sloping line.
No relationship
Shoe size and sales performance. Points scattered randomly with no discernible slope.
Non-linear relationship
Correlation coefficient will understate the relationship. A linear model is inappropriate. Consider log transformation or polynomial regression.
Process Mapping, C&E Matrix & FMEA
Three structured tools for systematic failure investigation in complex processes.
Process Mapping
A process map documents a workflow as a sequence of steps, decisions, and handoffs. It makes invisible waste and failure points visible. The most common format is a swim lane diagram — each lane represents a team or role, showing who does what and where handoffs occur.
In root cause analysis, the process map is used to identify: where in the process the defect could be introduced · which steps have no quality check · where delays accumulate · which handoffs create communication failures.
Cause-and-Effect Matrix (C&E Matrix)
The C&E Matrix scores potential causes against output requirements, weighting each by importance. It bridges the fishbone's brainstorming phase with quantitative prioritisation.
| Potential Cause | Output 1 (weight: 9) | Output 2 (weight: 6) | Output 3 (weight: 3) | Total Score |
|---|---|---|---|---|
| Insufficient training | 3 | 9 | 1 | 81 |
| Equipment malfunction | 9 | 3 | 1 | 108 |
| Supplier variability | 1 | 3 | 9 | 54 |
Score = Σ(Rating × Weight). Higher score = higher priority cause to investigate.
FMEA — Failure Mode and Effects Analysis
FMEA identifies potential failure modes in a process, their effects, and calculates a Risk Priority Number (RPN):
| Factor | What it measures | Score 1 = | Score 10 = |
|---|---|---|---|
| Severity | Impact on the customer if the failure occurs | Minor annoyance | Safety hazard / complete failure |
| Occurrence | How often the failure mode happens | Almost never | Happens nearly every cycle |
| Detection | How unlikely it is to catch before reaching the customer | Always detected | Never detected |
Failure modes with the highest RPN scores are addressed first. An RPN above 100–120 typically triggers immediate corrective action.
Microsoft Excel
Pareto charts, correlation, scatter plots, and FMEA templates — all without add-ins.
Excel is the most common tool for FMEA. Build a table with these columns:
| Column | Content | Formula (if any) |
|---|---|---|
| Process Step | Name of the step | Text |
| Potential Failure Mode | What could go wrong | Text |
| Potential Effect | Impact on output/customer | Text |
| Severity (S) | 1–10 rating | Number |
| Potential Cause | Root cause of failure | Text |
| Occurrence (O) | 1–10 rating | Number |
| Current Controls | Existing detection methods | Text |
| Detection (D) | 1–10 rating | Number |
| RPN | Risk Priority Number | |
| Recommended Action | What to do for high RPNs | Text |
Sort by RPN column descending to prioritise. Apply conditional formatting: to the RPN column for instant heat-map effect.
Minitab & IBM SPSS
Purpose-built statistical tools with dedicated quality and diagnostic procedures.
Minitab is the industry standard for quality analysis (Six Sigma, Lean). Its quality tools menu makes Pareto and fishbone creation faster than Excel.
Python — Diagnostic Analysis
Automate Pareto charts, correlation matrices, scatter plots, and FMEA scoring at scale.
Three Simulators
Practice the three core diagnostic tools before applying them to real work.
Simulator 1 · Pareto Analyser
Eight complaint types are listed with their frequencies. Identify which categories form the "vital few" — the ones that cross the 80% cumulative threshold. Click each bar to select/deselect it as a vital-few category.
Simulator 2 · 5 Whys Walk-Through
Follow a 5 Whys analysis for a real business problem. At each step, select the most analytically sound "why" answer to progress toward the root cause.
Simulator 3 · Root Cause Classifier
Classify each potential cause into the correct fishbone category by clicking the cause, then clicking the category it belongs to.
Common Mistakes
These are the errors that turn root cause analysis into a political exercise instead of an analytical one.
Stopping at the first cause found
The first explanation is almost always a symptom, not a root cause. If you stop after one "why," you will solve the fuse (symptom) not the missing maintenance schedule (root cause). Always drill deeper.
Confusing correlation with causation
Two variables that move together are not necessarily connected. Before acting on a correlation, ask: is there a plausible mechanism? Could a third variable explain both? Run the analysis but state the limitation explicitly.
Fishbone sessions dominated by one voice
The fishbone diagram is a brainstorming tool. Its value comes from diverse perspectives filling in the branches. If one person dominates, critical causes in other categories (often Environment or Measurement) will be missed.
Treating all FMEA RPNs as equally reliable
RPN scores depend entirely on the quality of the ratings. Inconsistent raters (one person rates Severity 3, another rates the same failure 7) make the RPN meaningless. Always calibrate raters before scoring.
Using Pareto to ignore the "trivial many"
The 80/20 rule says act on the vital few first — not ignore everything else forever. After resolving the top 20%, the next tier becomes the new top 20%. Pareto analysis drives prioritisation, not permanent neglect.
Skipping the verification step
Root cause analysis produces a hypothesis, not a proven cause. After identifying the likely root cause, you must verify it — check if the problem disappears when the cause is removed. Without verification, you are still guessing.