The 5 Whys, Fishbone Diagram and Pareto Analysis

The 5 Whys, fishbone diagram and Pareto analysis are practical tools for understanding process problems. They answer different questions. 5 Whys follows a cause chain. A fishbone diagram organises possible causes. Pareto analysis helps identify which categories or causes appear most significant.

The direct answer is this: use 5 Whys when the problem is specific and you can trace cause and effect; use a fishbone when there may be many possible causes; use Pareto analysis when you have data and need to prioritise the biggest contributors.

Tool Comparison Table

Tool	Best for	Risk
5 Whys	Tracing one specific problem through cause and effect.	Can become guesswork without evidence.
Fishbone diagram	Brainstorming and organising possible causes.	Can produce many ideas without prioritisation.
Pareto analysis	Ranking causes or issue categories by frequency or impact.	Can mislead if data categories are weak.

5 Whys Template

Level	Answer
Problem statement
Why 1?
Why 2?
Why 3?
Why 4?
Why 5?
Countermeasure

Fishbone Cause Categories

Category	Possible causes
People	Skills, training, workload, authority.
Process	Steps, handoffs, sequence, standards.
Information	Missing, late, inaccurate or unclear data.
Tools / systems	Software, equipment, forms, templates.
Environment	Workspace, layout, interruptions, conditions.
Management	Policies, incentives, approvals, priorities.

Pareto Table Template

Issue category	Count	Percentage	Cumulative percentage

Panith Illustrative Case Study

Panith Illustrative Case Study: A small restaurant receives complaints about delivery orders. A fishbone session identifies packaging, driver timing, order entry, menu availability and kitchen checks as possible causes. A simple Pareto count then shows most complaints come from missing side items. The team uses 5 Whys on that specific issue and finds the kitchen ticket format hides side orders.

References and Further Reading

SEO improvement pass: expanded depth and practical application

Expanded Practical Guidance

These three tools often work best together. Pareto analysis helps choose the most important issue category. A fishbone diagram helps explore possible causes. 5 Whys then helps trace one specific cause chain to a countermeasure.

The tools should not replace judgement. A fishbone full of guesses is not evidence. A Pareto chart based on poor categories can mislead. A 5 Whys chain can go in the wrong direction if the team has not first understood the current state.

Tool Selection Decision Tree

Situation	Use first
You have many complaint categories and need to prioritise.	Pareto analysis.
You have one recurring problem but many possible causes.	Fishbone diagram.
You have a specific confirmed point of occurrence.	5 Whys.
You only have opinions and no evidence.	Current-state observation and data collection first.

Practical Next Step

Start with one well-defined problem. Use Pareto only if you have categories, fishbone only if you need possible causes, and 5 Whys only when the team can test the cause chain against reality.

Visual Learning Aids

The following visual structures translate this lesson into practical management tools. They are designed for SME use and can be copied into a workshop, team meeting or improvement plan.

1. Process Diagram

Input	Work system	Output	Owner	Main risk
Customer need or business trigger	The 5 Whys, Fishbone Diagram and Pareto Analysis applied to the business process	Reliable customer or internal outcome	Process owner	Rework, delay or quality failure

2. Flowchart

[Start] Trigger received
   |
   v
[Understand] Work is mapped
   |
   v
[Decide] Bottleneck or waste is identified
   |
   v
[Act] Improvement option is selected
   |
   v
[Review] New way of working is tested
   |
   v
[Improve] KPI review confirms next action

3. Decision Tree

Is the issue clear and evidence-based?
- No: clarify the problem, collect examples and involve the people closest to the work.
- Yes: does it affect customers, cost, quality, risk or growth?
  - No: document the learning and monitor lightly.
  - Yes: assign an owner, choose a practical method, define success measures and review progress.

4. Priority Matrix

	Low effort	High effort
High impact	Do first: quick operational improvement	Plan carefully: strategic improvement project
Low impact	Do only if it removes friction	Avoid or defer unless required for risk, compliance or learning

5. Implementation Timeline

Stage	Typical SME timing	Output
Diagnose	Week 1	Problem statement and evidence
Design	Week 2	Chosen method, owner and measures
Test	Weeks 3-4	Small pilot or controlled trial
Standardise	Weeks 5-6	Checklist, SOP, dashboard or decision rule
Improve	Monthly	Review notes and next improvement action

6. Illustrative Performance Chart

Illustrative example: replace these sample scores with real business data before using the chart for decisions.

Measure	Current score	Target score	Visual gap
Clarity	2/5	4/5	2 blocks to 4 blocks
Ownership	2/5	5/5	2 blocks to 5 blocks
Measurement	1/5	4/5	1 block to 4 blocks
Consistency	3/5	4/5	3 blocks to 4 blocks

7. Maturity Model

Level	Maturity stage	What it looks like	Next improvement
1	Informal work	Informal work is visible in the way the business manages this topic.	Documented process
2	Documented process	Documented process is visible in the way the business manages this topic.	Measured process
3	Measured process	Measured process is visible in the way the business manages this topic.	Controlled process
4	Controlled process	Controlled process is visible in the way the business manages this topic.	Continuously improved process
5	Continuously improved process	Continuously improved process is visible in the way the business manages this topic.	Sustain and refine through periodic review

8. Comparison Table

Dimension	Current-state process	Future-state process
Decision basis	Experience, urgency or individual memory	Evidence, agreed criteria and visible trade-offs
Accountability	Unclear or dependent on the founder	Named owner with clear responsibility and review rhythm
Measurement	Discussed only when something goes wrong	Tracked using cycle time, first-time-right rate, cost and customer impact
Scalability	Works only while the team is small	Can be taught, repeated and improved as the business grows