The 5 Whys is a simple root cause technique: you state a problem, ask “why did this happen?”, answer with a fact, and repeat until you reach a cause you can fix for good. It was popularised by Toyota’s production system and works well because it needs no software, no statistics, and only a few minutes of honest conversation. The number five is a rule of thumb, not a law. Sometimes three questions are enough; sometimes you need seven.
Steps to run a 5 Whys analysis
- Define the problem precisely. Write one factual sentence: what happened, where, when, and how big. “Orders are a mess” is not a problem statement; “14 orders shipped more than 2 days late in September” is.
- Gather the right people. Include those who do the work, not just those who manage it. Three to five people is plenty.
- Ask why, and answer from evidence. Each answer must be something you can check in a record, a log, or by observation, not a guess.
- Keep asking until the answer is a process or system cause. Stop when the next “why” leads outside your control or when fixing the cause would stop the problem recurring.
- Test the chain backwards. Read from the root cause up to the problem, adding “therefore” at each step. If the logic breaks, a step is wrong.
- Agree on actions and owners. A root cause with no action is only an interesting story.
A worked example
Problem: a customer received an order two days late.
- Why was it late? It was picked on day 3 instead of day 1.
- Why was picking delayed? Picking only starts after the order is manually approved.
- Why was approval delayed? The only approver was on leave and nobody else could approve.
- Why could nobody else approve? Approval rights were assigned to one person when the process was set up.
- Why was there no backup? The process has no defined cover for absences and nobody owns reviewing it.
The root cause is a process gap, not a careless employee. The fix is to name a backup approver, set an escalation rule if an order waits more than 24 hours, and give someone ownership of the process. Notice that the first answer (“picked late”) would have led to a very different, and weaker, fix.
Common mistakes
Blaming people
If a chain ends at “Sam forgot”, you have stopped too early. Ask why the process allowed one person’s memory to be the only safeguard. Blame makes people hide information, and then your next analysis starts with bad data.
Stopping at symptoms
“The report was late because the data was late” describes the problem a second time. A genuine root cause is something that, once changed, prevents recurrence. If you could fix the answer and the problem could still return, keep going.
Single-cause bias
Real incidents often have several contributing causes. A linear chain can hide this. If a “why” has two plausible answers, follow both branches and record each as its own chain rather than picking the convenient one.
When to use a fishbone diagram instead
The 5 Whys is best for problems with a fairly clear, single thread: a missed deadline, a repeated error, a one-off failure. When the cause is unclear or the problem is complex, use a fishbone (Ishikawa) diagram. You sort possible causes into categories such as people, process, tools, materials, environment, and measurement, then investigate the likeliest. Many teams combine them: brainstorm with a fishbone, then run the 5 Whys on each promising branch.
Turn findings into tracked actions
Analysis only pays off when something changes. Before the meeting ends, convert each root cause into an action with these details:
- A specific task: “Add a backup approver for order approvals” rather than “improve coverage”.
- One named owner: a person, not a team.
- A due date: realistic, and visible to everyone involved.
- A success check: how you will know it worked, such as zero late shipments from approval delays over the next 30 days.
- A follow-up review: a date to confirm the fix held and the problem has not returned.
Where the action list lives matters as much as the analysis. If it sits in a document nobody reopens, the same problem will be back within months. FulcrumGrid Command Center is one place to keep such actions with owners, due dates, and status in view, so open items from an analysis are reviewed alongside everything else. Any reliable tracker will do the job if it is checked regularly.
Frequently asked questions
What is the 5 Whys method?
It is a root cause technique where you ask “why?” repeatedly, each time answering from evidence, until you reach a process or system cause you can fix. Five is a guideline; the right number is however many it takes.
Do you always need exactly five whys?
No. Stop when you reach a cause that, if fixed, would prevent the problem returning. That may take three questions or more than five.
When should I use a fishbone diagram instead?
Use a fishbone when the problem is complex or the cause is unclear, because it helps you explore several categories of cause at once. You can then apply the 5 Whys to the most likely branches.
How do I avoid blaming people in a 5 Whys?
Ask why the process allowed the mistake, not who made it. If your chain ends with a person’s name or a vague word like carelessness, keep digging into the system around them.
How do I make sure the actions get done?
Give every action one owner, a due date, and a success check, then review the list on a schedule. Keeping it in a shared tracker rather than a one-off document makes follow-up much more likely.
FulcrumGrid Command Center
Keep root cause actions from getting lost
FulcrumGrid Command Center lets you track follow-up actions with owners and due dates alongside your other operations, so the fixes from your 5 Whys sessions actually get done.