Lesson 10 of 23 · 8 min read

The 5 Whys in depth: evidence, branches and when to stop

In Lean: 5 Whys: branches, evidence, when to stop

Builds on: Go and see how the work is really done, Write the problem down before solving it

In one minute

The 5 Whys is a way to find the root cause of a problem by asking why it happens, then why that answer happens, until you reach something your team can change. Lesson 5 followed one chain; real problems often have two causes at once, and every "because" in a chain is a claim that can be wrong. So check each link against the work itself, follow each branch the facts support, and stop where your team can make a change that keeps that branch from coming back. A short chain you have checked is worth more than a long one you have guessed.

The idea

Every "because" is a claim

Each answer in a chain says that one thing caused another. Before you build on it, test it with two questions.

  • Did we see it? Point to the evidence: the emails, the log, the system setting, the items you followed in lesson 8. "Everyone knows" is not evidence.
  • Is it enough? Would this cause, on its own, produce what the line above describes? If you counted twelve late items and this cause explains five, something else explains the other seven.

A link that fails the first test is a guess: go and look before asking the next why. A link that fails the second points to a second branch. Checking each answer against the work (in Lean: verifying the cause) is slower than talking, and it is the step most often skipped.

When one why has two answers

Many office problems have two causes running at once. If both answers are supported, do not pick the more convenient one. Split the chain and ask why down each branch separately, until each reaches its own cause (in Lean: branches of the 5 Whys). Keep each branch as its own chain. If you work on one chain at a time, record the second as a friction of its own so it is not lost. When branches compete for attention, start with the one that explains more of what you counted.

When the possible causes are many, some teams first sketch them all on one drawing shaped like a fish skeleton, grouped under headings such as method, tools, information and environment (in Lean: fishbone diagram, also called an Ishikawa diagram). The sketch only lists candidates. Evidence decides which ones are causes.

A fishbone: every place a cause could hideWrite the problem at the head, then list possible causes under each heading before you choose a chain of whys to follow.

Illustrative example, not real data

Fishbone diagram for an office problemA fishbone diagram. The problem, supplier invoices paid late, sits at the head. Six bones lead into the spine, one per place to look for causes: People: Cover not trained; One approver only. Process: Approvals batched; Rework loops back. Tools: Systems disagree; Form skips fields. Information: Details missing; Old template used. Policy: Three sign-offs; Rule hard to find. Environment: Month-end peak; No shared view.Supplier invoicespaid latePeopleCover not trainedOne approver onlyProcessApprovals batchedRework loops backToolsSystems disagreeForm skips fieldsInformationDetails missingOld template usedPolicyThree sign-offsRule hard to findEnvironmentMonth-end peakNo shared viewFishbone diagram for an office problemA fishbone diagram. The problem, supplier invoices paid late, sits at the head. Six bones lead into the spine, one per place to look for causes: People: Cover not trained; One approver only. Process: Approvals batched; Rework loops back. Tools: Systems disagree; Form skips fields. Information: Details missing; Old template used. Policy: Three sign-offs; Rule hard to find. Environment: Month-end peak; No shared view.Supplier invoicespaid latePeopleCover not trainedOne approver onlyProcessApprovals batchedRework loops backToolsSystems disagreeForm skips fieldsInformationDetails missingOld template usedPolicyThree sign-offsRule hard to findEnvironmentMonth-end peakNo shared view
  • The bones are places to look, not answers. Check each possible cause against the work before you build on it.
  • Under People, write what the process asks of people, never a name.

When to stop

Lesson 5's rule still holds: stop at something the team can change. Longer chains need two refinements.

  • Stop where your reach ends. If the next why leads to the annual budget, a law or another company's system, step back to the last answer your team can act on, such as how you hand work to that system. Then tell whoever owns what lies beyond.
  • Test the stop. Ask: if we changed this, would this branch stop coming back? If the honest answer is "only partly", a link or a branch is missing.

Example

Illustrative example, not a real company.

Problem statement: payslips should be right first time; in the last three monthly runs, fourteen payslips needed a correction after payday.

  • Why? The salary change behind each one was missing or wrong in the payroll system at cut-off. Checked: all fourteen trace back to such a change.
  • Someone suggests the payroll system is unreliable. Checked: it paid exactly what had been entered. Link dropped.

"Missing or wrong" is two answers, so the chain splits.

Branch A, missing changes. Why? Six change emails reached payroll after cut-off. Why? The cut-off date moves each month and appears nowhere managers look. Checked: it is on the payroll team's own calendar only. Stop: the team can publish the dates where managers see them.

Branch B, wrong changes. Why? Eight changes were keyed from free-text emails that could be read two ways, such as a monthly or a yearly amount. Why? There is no form for salary changes, so any wording is accepted. Checked: all eight emails. Stop: a form with required fields is within the team's reach.

Six plus eight explains all fourteen. Neither branch ends at a person: anyone keying an unclear email could misread it.

Common mistakes

  • Ending at a person, at "lack of time", or at a guess. Lesson 5's three still apply, and long chains make a guess easier to hide.
  • A fix dressed as a cause. "Because we have no workflow tool" or "because of a lack of training" names a solution. Ask what actually goes wrong without it.
  • A chain that drifts or circles. Each step sounds reasonable, but by the fourth why the chain is about another problem, or back where it began. Read it backwards against your problem statement.

Words to know

  • Checking each answer against the work (in Lean: verifying the cause): confirming every link with evidence.
  • Two causes behind one problem (in Lean: branches of the 5 Whys): a chain that splits where a why has two supported answers.
  • A sketch of possible causes (in Lean: fishbone or Ishikawa diagram): candidates to check, not conclusions.
  • The cause you can change (in Lean: root cause): one per branch.

Check your understanding

3 questions. Answer them all, then check. You can try again as often as you like; nothing about your attempts is kept.

Question 1 of 3You counted twenty late refunds. One link says: because refunds above a limit need finance approval. Checking, you find eight of the twenty were above the limit. What does this tell you?
Question 2 of 3Three teams stopped their chains at these points. Which stopping point is flawed?
Question 3 of 3Which of these chain answers are fixes dressed as causes? Select all that apply.

Choose all that apply.

Loading…

Try it on your own work

Describe one recurring task that wastes your time, and see these ideas applied to it.

Worksheet for this lesson: 5 Whys Template (free download, no sign-up).

Where this comes from

The 5 Whys comes from the Toyota Production System. Confirming each cause with evidence and following more than one branch belong to the structured problem solving that grew around it, and the fishbone diagram comes from the Japanese quality movement.