Five whys (5 whys)
Start from a problem you have actually observed, ask why each explanation is true, and stop where the evidence ends with a clear way to check it.
- Time
- 30 min
- People
- 3–5
- Kind of work
- Understand · Frame
In short
The five whys is a root cause technique: you start with an observed problem, ask why it happens, then ask why that answer is true, and keep going, usually about five times. Each answer needs evidence. A small team can run it in 30 minutes and leave with a likely cause and a way to test it.
What it is
The five whys is a way of digging under a problem. You write down something that has actually gone wrong, such as half the clinic's afternoon slots going unused, and ask why. You take the answer and ask why again. Each step moves you from what you can see towards what is causing it. The method is widely associated with the Toyota production system, where it was used to look past a broken part to the reason it broke.
The number five is a guide, not a rule. Sometimes three whys reach a cause you can act on; sometimes you need seven. What matters is that each answer is supported by something you can point to, such as a log, a record, a quote, an observation. Where the evidence runs out, you stop, name the likely cause and decide how to check it. That last step is what separates the five whys from a confident story.
When to use it
Use it when
- When one specific problem keeps coming back after it has been fixed.
- When you have a symptom in your data and want a likely cause before choosing a solution.
- After an incident, to learn what allowed it to happen.
- When a team is about to jump to a solution and you want to check the problem first.
- On one moment from an experience map that clearly needs explaining.
Skip it when
- When the problem has many interacting causes. A fishbone or problem tree lets you see several at once.
- When the goal is to find who is at fault. The method looks at systems and conditions, not people.
- When you have no evidence at all. Gather some first, or the chain will rest on opinion.
You need
- Time
- About 30 minutes for one problem.
- People
- Three to five people who know the process, including someone who does the work day to day.
- Materials
- A whiteboard or long sheet, sticky notes, the four-field worksheet, and any data or records about the problem.
How to run it
Step 1: Write the problem as an observation
State what you have seen, with a number and a place where you can: 48 percent of afternoon appointment slots at the outpatient clinic went unused last month. Avoid problems that already contain a cause, such as patients are careless.
Step 2: Ask the first why
Ask: why does this happen? Take the most likely answer the group can support and write it under the problem. Next to it, in Evidence, note what supports it: a report, a log, an interview, an observation.
Step 3: Ask why again
Ask why that answer is true. Write the next answer below, with its evidence. Keep each answer to one short, factual sentence. If an answer starts with because people should, rephrase it as a condition you can observe.
Step 4: Record alternative causes
At any step where the group sees two plausible answers, write the second in Alternative cause. You can follow one branch now and come back to the other. This keeps the chain honest.
Step 5: Keep going until the evidence ends
Carry on asking why, typically four to six times. Stop when you reach a cause you can change, or when nobody has evidence for the next answer. Do not push past that point with guesses.
Step 6: Name the likely cause and how to check it
Circle the last supported answer. Agree one concrete way to test it within two weeks, such as pulling a sample of records, observing a shift or trying a small change in one unit.
Step 7: Read the chain backwards
Read from the bottom up with therefore between each line: because reminders are sent at 6 am, therefore they are missed, therefore patients forget. If any step sounds wrong out loud, revisit it.
Worked example
A hospital outpatient clinic finds that nearly half of its afternoon appointment slots went unused last month, while the waiting list grew. The clinic manager, a receptionist, a nurse and a data analyst meet for 30 minutes.
Problem: 48 percent of afternoon slots unused last month. Why? Patients booked into those slots did not attend. Evidence: the appointment system shows booked-but-absent for most of them, not empty slots.
Why did they not attend? Many say they forgot. Evidence: the receptionist's notebook, where she logs reasons given on follow-up calls. Alternative cause: some may have found the time inconvenient. The team writes that down to check later.
Why did they forget, when reminders are sent? The analyst lines up reminder send times against missed slots. All reminders go out at 6 am on the day. Patients with afternoon slots get the message hours before they need it, often before they are awake.
Why 6 am? The reminder job was set to run once a day at the time the system was installed, and was never reviewed. Evidence: the system settings. The team stops here, names the likely cause and agrees a test: send afternoon reminders at 11 am for two weeks in one clinic and compare attendance.
IllustrativeTips and mistakes
Tips
- Have the people who do the work in the room. They usually know the answer to the third or fourth why.
- Write every answer where everyone can see it. Spoken chains drift.
- If an answer blames a person, ask what made that action likely. You will find a condition you can change.
- Keep your data analyst or records close. Many whys can be checked in minutes.
- Run separate chains for separate problems. Two problems in one chain will tangle.
Common mistakes
- Stopping at the first answer that sounds right, often a symptom one step removed.
- Accepting answers with no evidence because the most senior person said them.
- Following one chain only and ignoring an equally likely alternative.
- Treating the final answer as proven instead of as a cause to test.
What you walk away with
You leave with a short chain from the observed problem to a likely cause, each step tied to evidence, plus any alternative causes worth checking and one concrete test to run. That turns a vague complaint into something you can act on. If the chain branches too often, move to a fishbone analysis to see all the cause families at once, or a problem tree to separate causes from consequences.
Questions people ask
Do you always have to ask why five times?
No. Five is a rough guide. Stop when you reach a cause you can change, or when the evidence runs out. Some chains end at three, others need six or seven.
Five whys vs fishbone diagram?
The five whys follows one line deep. A fishbone spreads many possible causes across categories. Use the five whys for a focused problem with a likely single path, and a fishbone when causes seem many and mixed.
Who invented the five whys?
The technique is commonly credited to Sakichi Toyoda and was used widely within Toyota's production system. It has since been adopted across many kinds of organisation.
Tool card
The worksheet your team fills in, one box per field.
- Problem
- Why
- Evidence
- Alternative cause