The 5 Whys: Root-Cause Thinking and Where It Falls Short

When something goes wrong, the first fix that comes to mind usually treats the symptom. Replace the part, resend the order, remind people to be more careful. The problem goes away for a while and then comes back.

The 5 Whys is one of the simplest tools in kaizen for breaking that pattern. You keep asking why a problem happened until you reach a cause you can actually remove. It needs no software and no statistics, which is exactly why it is so widely used, and also why it is easy to use badly. This guide covers where the method comes from, how to run it, and where its limits are.

Where the 5 Whys comes from

The Lean Enterprise Institute (LEI) defines the 5 Whys as "the practice of asking why repeatedly whenever a problem is encountered in order to get beyond the obvious symptoms to discover the root cause." Its best-known illustration comes from Taiichi Ohno, who, in Toyota's own account, helped establish the Toyota Production System. LEI quotes Ohno's example, from a 1988 work, of a machine that stopped working:

1. Why did the machine stop? There was an overload and the fuse blew.
2. Why was there an overload? The bearing was not sufficiently lubricated.
3. Why was it not lubricated? The lubrication pump was not pumping sufficiently.
4. Why was it not pumping sufficiently? The shaft of the pump was worn and rattling.
5. Why was the shaft worn out? There was no strainer attached and metal scraps got in.

As LEI points out, without repeatedly asking why, managers would simply replace the fuse or the pump, and the failure would recur. The real countermeasure is the strainer.

The number five is not the point

LEI is explicit: "The specific number five is not the point." The aim is to keep asking until the root cause is reached and eliminated. A tool published by the Centers for Medicare & Medicaid Services (CMS) for quality improvement teams says the same thing in practical terms: it often takes three to five whys, "but it can take more than five!"

The CMS tool also offers a useful test for when to stop. After each answer, ask: if this were corrected, is it likely the problem would happen again? If the answer is yes, you have found a contributing factor, not a root cause, and you should keep going.

How to run a 5 Whys session

The CMS tool lays out a simple team process, which works in almost any setting:

1. Write a clear, specific problem statement in one sentence.
2. The facilitator asks why the problem happened and records the team's answer.
3. Apply the recurrence test above. If the answer is only a contributing factor, ask why again.
4. Keep going until the team agrees the root cause has been identified.
5. Validate each root cause by asking: if you removed this cause, would the event or problem have been prevented?

Two of its points deserve emphasis. First, include people with personal knowledge of the processes and systems involved. Second, aim for answers that are clear and concise but not so simple that they overlook important details.

It also helps to check each answer against reality. LEI's definition of genchi genbutsu, the Toyota practice of going to see, is about confirming information by personal observation at the source. If an answer is a guess, go and look before you build the next why on top of it.

An everyday example

CMS illustrates the method with a flat tire on the way to work. You got a flat because you ran over nails in your garage. The nails were on the floor because a wet box of nails on the shelf fell apart. The box was wet because the roof leaked during a hard rain. The root cause is the leak. As the tool points out, if you stopped at the second answer and swept up the nails, you would have missed the root cause entirely.

Notice that the chain only took three whys. The method is about depth, not a fixed count.

When the method fits

LEI recommends the 5 Whys for what it calls gap-from-standard problems: situations where there is a known standard and something has deviated from it. That kind of problem-solving focuses on a specific problem definition, setting goals, root-cause analysis, countermeasures, and checks, standards and follow-up.

LEI also classifies the 5 Whys as a logic-based method, one of three broad types of root-cause analysis alongside approaches that examine one variable at a time or many variables at once. Logic-based analysis requires no advanced math, LEI notes, but it does require critical thinking, including inductive, deductive and abductive reasoning. In plain terms: generalize carefully from what you observe, reason from what you know to what should follow, and form hypotheses you can check.

Where it falls short

The 5 Whys is a starting point, not a complete method. The CMS tool itself notes that it "may not always help you to identify the root cause," and suggests a fishbone diagram, which pushes a team to think broadly across categories of possible causes.

Several limits are worth knowing:

• Real problems often have more than one cause. The Agency for Healthcare Research and Quality (AHRQ) explains in its patient safety primer on root cause analysis that multiple errors and system flaws often must intersect for a critical incident to reach the patient, which is why some have suggested replacing the term root cause analysis with "systems analysis." A single chain of whys can hide the other branches. When an answer has two plausible causes, follow both.
• The chain can end at a person. AHRQ notes that a central principle of root cause analysis is to identify underlying problems while "avoiding the trap of focusing on mistakes by individuals." If your last answer is "someone made a mistake," ask what about the system made that mistake easy to make.
• Weak countermeasures. AHRQ cites a 2017 commentary that identified overreliance on weak solutions, such as educational interventions and enforcing existing policies, as one reason root cause analyses fail. Retraining and reminders rarely remove a cause on their own.
• Knowledge limits. The group can only reach causes it knows about, which is another reason to include people who do the work and to go and see.

For serious safety events, such as those in health care, formal root cause analysis processes go well beyond a quick 5 Whys session, and organizations should follow their own required procedures.

Closing the loop

Finding a root cause is only half the job. Treat your countermeasure as a test: predict what should change, try it, and check whether the problem actually stops recurring. If it does, update the standard so the fix becomes part of how the work is done. If it doesn't, the analysis missed something, and you have learned where to look next.

Key takeaways

• The 5 Whys means asking why repeatedly until you reach a cause you can remove, not just a symptom.
• The number five is a guide, not a rule; stop when fixing the cause would prevent recurrence.
• Run it as a team that includes people who know the work, and verify answers by observing.
• Watch for multiple causes, chains that end in blame, and weak fixes like reminders.
• Treat each countermeasure as an experiment and confirm the problem stays solved.

Sources

• Lean Enterprise Institute, 5 Whys
• Centers for Medicare & Medicaid Services, Five Whys Tool for Root Cause Analysis
• Agency for Healthcare Research and Quality, PSNet, Root Cause Analysis (patient safety primer)
• Lean Enterprise Institute, Genchi Genbutsu
• Lean Enterprise Institute, Kaizen: A Resource Guide
• Toyota Motor Corporation, Toyota Production System