# Root Cause Analysis Template: 5-Why and Fishbone Diagram Worksheets
Root Cause Analysis (RCA) is a structured method for identifying the underlying cause of a quality problem - not just its symptoms. This template provides two complementary worksheets: the 5-Why Method and the Fishbone (Ishikawa) Diagram, along with a corrective action tracker.
When to Use This Template
Use this template whenever:
- •A product defect or non-conformance is detected
- •A customer complaint is received
- •An internal audit finding requires investigation
- •A process failure or near-miss occurs
Part 1: Problem Statement Worksheet
Before starting any analysis, define the problem clearly. A vague problem statement leads to vague root causes.
| Field | Details |
|---|---|
| **Problem Title** | *(e.g., "Sealing defect on Batch #B2204")* |
| **Date Detected** | |
| **Detected By** | |
| **Product / Process Affected** | |
| **Batch / Lot Number** | |
| **Defect Description** | *(What exactly is wrong? Be specific.)* |
| **Defect Quantity / Rate** | *(e.g., 42 units out of 1,200 - 3.5%)* |
| **Customer Impact** | *(Internal / External / None yet)* |
| **Immediate Containment Action** | *(What was done right away to stop the problem spreading?)* |
Tips for a good problem statement:
- •Use the format: *"[What] happened to [which object] at [where/when], resulting in [impact]."*
- •Avoid including causes in the problem statement - describe only what is observed.
Part 2: 5-Why Analysis Worksheet
The 5-Why method drills down from the symptom to the root cause by asking "Why?" repeatedly. Five iterations are typical, but you may need fewer or more.
Instructions
- 1Write the problem statement in the Problem row.
- 2Ask "Why did this happen?" and record the answer as Why 1.
- 3Ask "Why did *that* happen?" for each subsequent answer.
- 4Stop when you reach a cause you can control and fix.
- 5Validate: if you reverse the chain ("Therefore…"), it should logically lead back to the original problem.
5-Why Worksheet
| Step | Question | Answer |
|---|---|---|
| **Problem** | What is the problem? | |
| **Why 1** | Why did the problem occur? | |
| **Why 2** | Why did [Why 1 answer] happen? | |
| **Why 3** | Why did [Why 2 answer] happen? | |
| **Why 4** | Why did [Why 3 answer] happen? | |
| **Why 5** | Why did [Why 4 answer] happen? | |
| **Root Cause** | What is the confirmed root cause? |
Validation Check
- Reading the chain in reverse ("Therefore…") logically leads back to the original problem
- The root cause is something the team can act on
- The root cause is not a person's fault, but a process or system gap
Part 3: Fishbone (Ishikawa) Diagram Worksheet
The Fishbone Diagram is a visual brainstorming tool that maps all potential causes of a problem across standard categories. It is especially useful when the cause is not immediately obvious or when multiple contributing factors are suspected.
The 6M Categories (Manufacturing)
| Category | Description | Example Causes |
|---|---|---|
| **Machine** | Equipment, tools, technology | Worn sealing jaw, miscalibrated sensor |
| **Method** | Processes, procedures, SOPs | Incorrect torque setting, missing step in SOP |
| **Material** | Raw materials, components, packaging | Supplier batch variation, wrong film grade |
| **Man (People)** | Training, skills, human error | Operator not trained on new line, fatigue |
| **Measurement** | Inspection, gauges, data collection | Gauge not calibrated, wrong sampling plan |
| **Mother Nature (Environment)** | Temperature, humidity, dust | High ambient humidity causing seal failure |
For service/food industries, substitute with: 5P categories - People, Process, Policy, Plant, Product.
Fishbone Worksheet - Brainstorming Table
For each category, list all possible causes your team can think of. Do not filter at this stage.
Problem (Effect): _______________________________________________
| Category | Possible Cause 1 | Possible Cause 2 | Possible Cause 3 |
|---|---|---|---|
| Machine | |||
| Method | |||
| Material | |||
| Man | |||
| Measurement | |||
| Environment |
Narrowing Down Causes
After brainstorming, vote or use data to identify the most likely causes:
- Circle the top 3–5 causes most likely to have contributed
- Verify each shortlisted cause with data, observation, or testing
- Mark confirmed causes with ✓ and eliminated causes with ✗
Part 4: Root Cause Confirmation
Before moving to corrective actions, confirm the root cause is real - not assumed.
| Confirmation Method | Used? | Finding |
|---|---|---|
| Process observation / gemba walk | ☐ Yes ☐ No | |
| Data analysis (trend, SPC chart) | ☐ Yes ☐ No | |
| Equipment inspection / measurement | ☐ Yes ☐ No | |
| Operator interview | ☐ Yes ☐ No | |
| Trial / simulation | ☐ Yes ☐ No |
Confirmed Root Cause: _______________________________________________
Part 5: Corrective & Preventive Action (CAPA) Plan
| # | Action Description | Type | Owner | Target Date | Status |
|---|---|---|---|---|---|
| 1 | ☐ Corrective ☐ Preventive | ☐ Open ☐ Closed | |||
| 2 | ☐ Corrective ☐ Preventive | ☐ Open ☐ Closed | |||
| 3 | ☐ Corrective ☐ Preventive | ☐ Open ☐ Closed | |||
| 4 | ☐ Corrective ☐ Preventive | ☐ Open ☐ Closed |
Corrective Action = fixes the current problem (reactive).
Preventive Action = changes the system so the problem cannot recur (proactive).
Part 6: Effectiveness Verification
After implementing CAPA, verify that the actions actually solved the problem.
| Verification Step | Details |
|---|---|
| **Verification Method** | *(e.g., monitor defect rate for 30 days, re-audit process)* |
| **Verification Period** | |
| **Target Metric** | *(e.g., defect rate < 0.5%)* |
| **Actual Result** | |
| **Effective?** | ☐ Yes - Close RCA ☐ No - Reopen investigation |
Part 7: RCA Sign-Off
| Role | Name | Signature | Date |
|---|---|---|---|
| QA Lead | |||
| Production Manager | |||
| Department Head |
Quick Reference: Common Mistakes in RCA
- •Stopping too early - "Operator error" is rarely a root cause; ask why the operator made the error.
- •Jumping to solutions - Define the root cause fully before deciding on actions.
- •Single-cause thinking - Most real problems have multiple contributing causes.
- •No verification - Always confirm the fix worked with data, not assumption.
- •Blaming people - RCA should identify system and process gaps, not assign personal blame.
*Template version 1.0 - IdeaSprout Quality Assurance Suite*