Goal
Identify and validate a systemic root cause through a structured, evidence-based Why chain that can be directly linked to a corrective action.
Required Execution Checklist
- Problem defined with measurable data (value vs. specification)
- Linear Why chain built — one cause path at a time, no branching
- Each Why supported by objective evidence (not opinion or "probably")
- Logical consistency verified — reversal check passed
- Systemic root cause identified (not "human error" or symptom)
- Root cause validated: reproducibility test + elimination test
- Output enables definition of corrective action (PCA or CAPA)
When to use
Use 5-Why for any quality problem with a single, linear cause chain. Works best for process failures, equipment failures, and procedural non-compliances. For complex problems with multiple contributing causes, use Fishbone first to identify candidate root causes, then use 5-Why to drill into each.
If multiple potential cause paths exist — do not combine them into one chain. Run separate 5-Why chains for each path and determine which is confirmed by evidence.
Prerequisites
- Problem is clearly defined (use Is/Is-Not to scope if needed)
- The investigation team has access to the process, machine, or system where the defect occurred
- Physical evidence or production records are available
Use within 8D — Occurrence and Escape
When used for 8D D4, two separate Why chains are required:
| Chain | Starting question | What it finds |
|---|---|---|
| Occurrence chain | "Why did the defect happen?" | Root Cause of Occurrence (RCO) — the process or design failure that created the defect |
| Escape chain | "Why was the defect not detected before reaching the customer?" | Root Cause of Escape (RCE) — the detection system failure |
Run each chain independently. Do not mix occurrence and escape causes in the same chain — they have different corrective actions. The occurrence chain addresses prevention; the escape chain addresses detection.
Workflow
Step 1 — State the symptom precisely
Start with a factual, measurable problem statement. Not "the part was bad" but "dimension X measured 23.5mm; specification is 25.0 ± 0.5mm on part number Y, batch 2026-05-12."
The first Why answers: "Why did [specific symptom] occur?"
Step 2 — Build the Why chain
For each Why, follow these rules:
Rule 1: Each answer must be supported by evidence
- Acceptable evidence: measurement data, production records, machine logs, direct observation, physical samples
- Not acceptable: "probably," "maybe," "someone said"
Rule 2: Each answer must logically lead to the next Why
- Test reversibility: "Because [Why N], therefore [Why N+1]"
- If the sentence doesn't make logical sense, the chain is broken
Rule 3: Keep the chain focused
- One Why chain = one cause path
- If you reach a fork (two possible causes), investigate both separately
Rule 4: Stop at a systemic root cause
- You have reached root cause when: fixing it would prevent the defect from ever recurring
- Typical systemic root causes: missing procedure, inadequate training system, process design gap, absence of poka-yoke, measurement system failure
Step 3 — Validate the chain
Work backwards through the completed chain:
"Because [Why 5], therefore [Why 4]. Because [Why 4], therefore [Why 3]..."
If any step does not logically follow, revise that step.
Step 4 — Validate the root cause
The root cause is correct if:
- Reproducibility test: can you deliberately create the defect by triggering the root cause? Yes → validated
- Elimination test: if you fix the root cause, does the defect disappear? (trial run or logical test)
If neither test is possible, the root cause is not confirmed — it is a hypothesis. Do not close the investigation on a hypothesis. Either obtain evidence to confirm it, or investigate alternative cause paths.
Example
Problem: Connector pin bent at incoming inspection, 12/200 parts (6%).
| # | Why | Evidence | Validated? |
|---|---|---|---|
| 1 | Why are pins bent? | Pins deformed during insertion into housing | Microscopy confirmed deformation pattern |
| 2 | Why during insertion? | Insertion force exceeded pin yield strength | Force measurement: 48N, pin rated to 35N |
| 3 | Why was force 48N? | Operator used incorrect insertion tool (hand press vs. pneumatic jig) | Tool log: jig under maintenance since 05-10 |
| 4 | Why was incorrect tool used? | No instruction specifying which tool to use when jig is unavailable | Work instruction reviewed — no contingency |
| 5 | Why no contingency? | Tool maintenance downtime not considered in work instruction design | Process FMEA missing this scenario |
Root cause: Work instruction design does not cover tool substitution contingency; FMEA does not identify tool maintenance as a failure scenario.
Reversal check: "Because FMEA doesn't cover tool maintenance → therefore no contingency instruction → therefore wrong tool used → therefore excess force → therefore pins bent." ✓ Logical.
Common mistakes — reject these
"Human error" as a final answer → Ask: why was the error possible? What in the system allowed it?
"Operator didn't follow the procedure" → Ask: why didn't they follow it? Was it unclear? Not trained? Impossible to follow?
"Machine was out of calibration" → Ask: why? What is the calibration interval? Was it missed? Why?
Circular reasoning → "The part was defective because it didn't meet spec, because it was defective." → reframe the first Why as the physical mechanism.
Stopping at a symptom, not a cause → "The defect occurred because the part was wrong" — that IS the defect, not a cause.
Branching the chain prematurely → Each Why step should have one answer. If you have two, run two separate 5-Why chains.
Output content
A validated 5-Why must include:
- Problem statement (measured, quantified)
- Each Why with: the answer, the supporting evidence, and validated (Yes/No)
- Root cause statement
- Reversal check (one sentence confirming logical flow)
- Validation method (how the root cause was confirmed)
- Corrective action direction — what type of action addresses this root cause (used as direct input to 8D D5 or CAPA)
Output Format
At the start of each use, ask the user:
"How would you like to receive the output? A — Structured Markdown (formatted tables and sections, ready to copy) B — Plain tables (simplified structure for Excel or Word) C — Narrative report (flowing text for a formal document or email)
Default: A."
Adapt all output sections to the chosen format. If the platform or session context already defines a format preference, skip this question.
Reference files
Changelog
| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 | 2026-06-01 | @RBraga01 | Initial release |
| 1.1 | 2026-06-03 | @RBraga01 | Added dual-chain requirement (occurrence + escape), evidence status tracking |