← More Toolbox Talks
📱
Best viewed in landscape & full screen
Rotate your phone sideways, then tap the button below for the best experience. You can also swipe left/right to navigate slides.
Continue without full screen
📋 Toolbox Talk  ·  Continuous Improvement

Root Cause Analysis:
Fix It Once

How to find the real reason a problem keeps happening — using the 5 Whys and a fishbone diagram — and fix that, so the problem stays fixed.

✅ Updated October 2026📚 Lean & continuous improvement🏭 Warehouse · logistics · manufacturingukworkrights.co.uk

Talk 4 of 7 in the Continuous Improvement series  ·  a working method, not legal guidance

What it is

Symptom or cause?

  • A symptom is what you see: a mis-pick, a jam, a late delivery, a damaged part
  • The root cause is the underlying reason it happened — fix that and the problem doesn't come back
  • 5 Whys: keep asking 'why?' until you reach a cause you can act on
  • Fishbone (Ishikawa) diagram: sorts possible causes into groups so nothing obvious is missed
  • Error-proofing makes the mistake hard or impossible to make in the first place
  • Root cause analysis looks for a process cause, not a person to blame

Blame is not a root cause

'Operator error' is where the analysis starts, not where it ends. Ask why the process made the error easy to make.
Why it matters

Why fixing the cause pays

  • Quick fixes treat the symptom, so the same problem comes back and gets fixed again and again
  • Firefighting eats time that could go on improvement
  • The real cause often leads to a simpler, cheaper fix than expected
  • The method works for quality problems, delays, near misses and complaints
  • A no-blame approach means people report problems early instead of hiding them
  • Each problem becomes learning the whole site can use

Contain first, then solve

If the problem is happening now, contain it first — quarantine stock, stop the line, warn the next shift. Then find the cause. Containment is not the fix.
How to do it

The 5 Whys, step by step

1
State the problem

What happened, where, when and how often. Facts, not opinions.

2
Ask why it happened

Answer with what you can see or check, not guesses.

3
Ask why again

Ask it of that answer, and keep going.

4
Stop at a fixable cause

Usually a missing or weak part of the process that you can change.

5
Check the chain backwards

Read it back with 'therefore'. If it doesn't make sense, an answer is wrong.

Example chain

A pallet arrived damaged. Why? It fell from the forks. Why? It overhung the forks. Why? It was a non-standard size. Why? A supplier changed pallet size and nobody updated the goods-in check. Fix: add pallet size to the check and talk to the supplier.
How to do it

The fishbone (Ishikawa) diagram

  • Write the problem at the head of the fish, on the right
  • Each bone is a group of causes; a common set is the 6 Ms:
  • Method (the process), Machine (equipment), Materials, Measurement (data and gauges), People (skills and training, sometimes called Man) and Environment (heat, light, noise, sometimes called Mother Nature)
  • The team brainstorms possible causes onto each bone — no idea is criticised at this stage
  • Then circle the likely causes and check each one with data or by going to see
  • Run 5 Whys on the circled causes to dig deeper

Where the name comes from

It is named after Kaoru Ishikawa, the Japanese quality expert who popularised it. It is also called a cause-and-effect diagram.
How to do it

Error-proofing: make it hard to get wrong

  • Poka-yoke is the Japanese term for mistake-proofing, linked to Shigeo Shingo
  • Prevent: design the job so the error can't happen — a part that only fits one way, a jig that only takes the right part
  • Detect: if it can happen, catch it at once — a scanner that warns on the wrong barcode, a weight check on a packed order
  • Everyday examples: a plug that only fits the socket one way round, a microwave that won't start with the door open
  • A physical change beats a sign, and a sign beats 'be more careful'
  • Ask: could someone new, tired or rushed still get this right?

⚠ 'Be more careful' is not a fix

Training and reminders have their place, but people will always make mistakes sometimes. Change the process so the mistake can't happen, or is caught straight away.
Worked example  ·  Warehouse

Mis-picks of look-alike products

  • Problem: customers receiving the small size of a product instead of the large one
  • Contain: an extra check on orders with either product until the fix was in
  • Fishbone: causes on Method (no product scan at pick), Materials (near-identical packaging) and Environment (dim lighting in that aisle)
  • 5 Whys on the strongest cause: the two products sat side by side, and picks were confirmed by location, not by product barcode
  • Fix: separate the look-alikes, scan the product barcode at pick, and fix the lighting

What changed

A wrong product now gets a scanner warning at the pick face instead of a customer complaint days later. Error-proofing replaced 'pick more carefully'.
Worked example  ·  Manufacturing

A filling machine that kept jamming

  • Problem: the machine jammed several times a shift; each time it was cleared and restarted
  • 5 Whys: jam → bottles tipping on the conveyor → guide rails set too wide → rails set by eye at changeover → no marked setting for each bottle size
  • Fix: marked rail settings for each bottle size, added to the changeover checklist
  • Clearing a jam meant stopping and locking off the machine, so fewer jams also meant less time spent on a higher-risk task
  • Check: jams tallied for two weeks after the change

What changed

The cause was a missing standard, not a careless operator. The fix took minutes, and jams became rare instead of normal.
Common mistakes

What goes wrong

  • Stopping at 'human error' or naming a person as the cause
  • Guessing the answers to each 'why' instead of checking them
  • Following only one branch when there are several causes
  • Fixing the symptom — retraining or a reminder — and calling it the root cause
  • Analysis in the office by people who weren't there
  • No check afterwards to prove the problem has really gone

⚠ Watch for this

If the action is 'retrain the operator' or 'remind staff', ask one more why. It is rarely the root cause.
Try it this week

5 Whys on one repeat problem

1
Pick a repeat problem

Something the team has 'fixed' before that came back.

2
Write it as a fact

What, where, when and how often.

3
Ask why as a team

Five times, or until you reach a fixable cause. Check each answer if you can.

4
Agree one fix for the cause

And how you will know it has worked.

Bring it back

Did the problem come back? If it did, the chain missed something — go round again with the new facts.
Over to you

Discussion questions

  • What problem do we fix over and over again?
  • When something goes wrong here, do we look for a cause or for someone to blame?
  • Which of our jobs relies on people 'just remembering'?
  • Where could a simple physical change stop a mistake happening?
  • How would we know a problem had really gone?

For the presenter

Keep the discussion on processes, not people. If a name comes up, turn the question into 'what made that easy to do?'
Quick check

Check your understanding

1
What does root cause analysis look for?

A) Who made the mistake    B) The underlying reason the problem happens    C) The quickest fix

2
The 5 Whys means:

A) Exactly five questions, no more, no less    B) Asking why until you reach a cause you can act on    C) Asking five people

3
On a fishbone diagram, where does the problem go?

A) At the head    B) On the tail    C) On the bottom bone

4
Which is the strongest fix?

A) A reminder sign    B) Retraining    C) A change that makes the error impossible

Answers

1 B  ·  2 B  ·  3 A  ·  4 C
Common questions

Frequently asked questions

Do you always need exactly five whys?
No. Five is a rule of thumb. Some problems reach a fixable cause in three, others take more. Stop when you reach a cause you can act on that would stop the problem coming back.
What if there is more than one root cause?
That is common. Use a fishbone diagram to see the different causes, then run 5 Whys on each likely one, and fix the ones that matter most first.
Is this the same as an accident investigation?
It uses the same kind of thinking, but an accident or serious incident should be investigated under your site's own procedure by the right people. This talk is about everyday process problems.
For whoever runs this talk

Delivery notes & attendance record

Suggested length: 10–15 minutes. A toolbox talk is a short briefing on one topic, given by a supervisor or team leader to the people doing the work.

Before you start

Bring a flip chart or whiteboard to draw a fishbone on, and pick a real repeat problem from your site beforehand.

How to run it

Explain symptom and cause (slides 2 and 3), walk through the 5 Whys and the fishbone, then run a live 5 Whys on your chosen problem with the team.

Where this fits

Talk 4 of the Continuous Improvement series. It is the Plan step of PDCA (talk 3) done properly.

The worked examples are illustrations to start a discussion, not real case studies or measured results.

Attendance record
TopicRoot Cause Analysis: Fix It Once
Date
Site / location
Delivered by
Actions agreed
Next talk due
Attendees
NameSignature

Use the Print handout button to print this record. General guidance on a working method — not legal, health and safety or HR advice. Before changing how a job is done, check the risk assessment and safe system of work for that job, and involve the people who do it.

Continuous Improvement series

Keep
improving

Seven short talks that build on each other. Run them in order, or pick the one your team needs next.

Next talk
Standard Work
ukworkrights.co.uk/toolbox-standardwork.html
After that
Value Stream Mapping
ukworkrights.co.uk/toolbox-vsm.html
The full series
All 7 talks
ukworkrights.co.uk/toolbox-talks.html#continuous-improvement
This talk
Root Cause Analysis
ukworkrights.co.uk/toolbox-rootcause.html

General guidance on a working method — not legal advice · Updated October 2026 · © UK Work Rights Ltd · Company No. 17228507 · ICO Registration No. ZC239465 · Registered office: 71–75 Shelton Street, Covent Garden, London, WC2H 9JQ  ·  hello@ukworkrights.co.uk
Directed and published by Matt Thompson, founder
Content is produced with AI assistance.