5why Root Cause

5-Why Root Cause Analysis

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:

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%).

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:

1. Problem statement (measured, quantified)
2. Each Why with: the answer, the supporting evidence, and validated (Yes/No)
3. Root cause statement
4. Reversal check (one sentence confirming logical flow)
5. Validation method (how the root cause was confirmed)
6. 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

• Chain validation guide

Changelog

Source: hashgraph-online/awesome-codex-plugins → plugins/RBraga01/Quality-Engineering-Skills/skills/problem-solving/5why-root-cause/SKILL.md