Featured Product
This Week in Quality Digest Live
Lean Features
James Chan
Start the transition to preventive maintenance
Mark Rosenthal
The intersection between Toyota kata and VSM
Erin Vogen
Eight steps to simplify the process
Phanish Puranam
Is it time for System 3 thinking by humans?
Jones Loflin
24 tips to make 2024 better than last year

More Features

Lean News
New video in the NIST ‘Heroes’ series
Embrace mistakes as valuable opportunities for improvement
Introducing solutions to improve production performance
Helping organizations improve quality and performance
Quality doesn’t have to sacrifice efficiency
Weighing supply and customer satisfaction
Specifically designed for defense and aerospace CNC machining and manufacturing
From excess inventory and nonvalue work to $2 million in cost savings
Tactics aim to improve job quality and retain a high-performing workforce

More News

Stewart Anderson


Root Cause Analysis: Addressing Some Limitations of the 5 Whys

Because appropriately finding the cause of a problem is crucial to a successful organization

Published: Thursday, December 17, 2009 - 11:03

The 5 Whys is a well-known root cause analysis technique that originated at Toyota and has been adopted by many other organizations that have implemented lean manufacturing principles. Unlike more sophisticated problem-solving techniques, the 5 Whys doesn’t involve data segmentation, hypothesis testing, regression, or other advanced statistical tools; and in many cases can be completed without a data collection plan. By repeatedly asking the question “Why?” at least five times, you can successively peel away the layers of symptoms, which can lead to identifying the root cause of a problem.

The 5 Whys was originally developed by Sakichi Toyoda, founder of Toyota Industries Corporation, and was later used within Toyota Motor Corp. during the development of the Toyota Product System (TPS). At Toyota, 5 Whys is still a critical component of problem-solving training, and the method is still widely applied within the company when problems occur. In his book, Toyota Production System: Beyond Large-Scale Production. (Productivity Press, 1988), Taiichi Ohno, described the 5 Whys as “… the basis of Toyota’s scientific approach… by repeating why five times, the nature of the problem as well as its solution becomes clear.”

Solving problems means identifying the root causes of a problem and then developing and implementing appropriate countermeasures that are designed to eliminate the root causes and prevent their recurrence. Root causes are to be distinguished from causal factors. Causal factors are those factors that contribute to the occurrence of a problem, but are not necessarily the initiating cause of a problem—the root cause. Therefore, causal factors and chains need to be analyzed further to determine their root causes. A robust problem-solving method must be adept at not only identifying a problem’s causal factors, but equally adept at uncovering the root causes that underpin the causal factors.

A major advantage to the 5 Whys technique is that it is relatively easy to use and apply, and its easy application makes it a practical tool for root cause analysis in problem solving. Under a 5 Whys approach, it is possible to get to root causes in a relatively short period of time. However, as we shall see later on this article, ease of use and speed also need to be balanced with the risk of failure from recurrence of the problem should the 5 Whys fail to find the true root cause.

While many companies have successfully used the 5 Whys, the method has some inherent limitations. First, using 5 Whys doesn’t always lead to root cause identification when the cause is unknown. That is, if the cause is unknown to the person doing the problem solving, using 5 Whys may not lead to any meaningful answers. Second, an assumption underlying 5 Whys is that each presenting symptom has only one sufficient cause. This is not always the case and a 5 Whys analysis may not reveal jointly sufficient causes that explain a symptom. Third, the success of 5 Whys is to some degree contingent upon the skill with which the method is applied; if even one Why has a bad or meaningless answer, the whole procedure can be thrown off. Finally, the method isn’t necessarily repeatable; three different people applying 5 Whys to the same problem may come up with three totally different answers.

Other drawbacks to 5 Whys have been cited, including the method’s inability to distinguish between causal factors and root causes, and the lack of rigor where users aren’t required to test for sufficiency the root causes generated by the method.

Even Toyota has admitted some shortcomings with the 5 Whys method. Teruyuki Minoura, Toyota’s former managing director of global purchasing, commented at the 2003 Automotive Parts System Solution Fair held in Tokyo that the 5 Whys requires skill to use well and most important, should be grounded in observation, not deduction:

“When an error occurs, the first thing that needs to be done is fix the error,” says Minoura as he recalls that Ohno used to order them to ask the question ‘Why?” five times over because “that way you’ll find the root cause, and if you get rid of that, it’ll never happen again.”

However, Minoura emphasized that on-the-spot observation rather than deduction is the only correct way to answer a “Why?” question. “I’m always struck that the five-why method doesn’t seem to be working as well as it should be because there’s been a lack of practical training,” says Minoura. “The reason is that they end up falling back on deduction. Yes, deduction. So when I ask them ‘Why?’ they reel off five causes as quick as a flash by deduction. Then I ask them five whys again for each of the causes they came up with. The result is that they start falling back on deduction again and so many causes come back, that you end up totally confused as to which of them is important.

“Through real training, you’ll be able to discover dozens of problems and also get to their root causes,” adds Minoura. “You’ll be able to make dozens of improvements. If you incorporate all the accumulated knowledge of root causes that you’ve got from always asking ‘Why? Why? Why? … ’ into your equipment, you’re going to have something that no one else can come close to. I don’t think it’s got anything to do with nationality; it all has to do with whether or not you’ve received the proper training. I feel, though, that the tendency to give that kind of training and education forms the basis of Toyota’s approach to monozukuri [a Japanese term that translates as ‘making things’].”

In these comments, Minoura is emphasizing a key point of Toyota’s approach to improving processes: Go see and observe and study the actual process conditions to develop understanding and facts (known simply as “Go and See” in TPS parlance). In many companies, problem solving is a deductive exercise, oftentimes conducted in a meeting room where those doing the problem solving are separated from the actual process where the problem occurred. This separation encourages deductive thinking that is not necessarily grounded in what is actually happening, or happened, at the process. Most important, because it isn’t grounded in observation, where effects and their causes are directly observed, deductive thinking can quickly degenerate into hypothetical thinking. Minoura’s comment about “practical training” also hints at a missing dimension in many problem-solving efforts: going and seeing what is actually happening at a process, rather than conceptually applying tools and techniques to infer what might be happening.

Mike Rother, in his excellent book, Toyota Kata: Managing People for Improvement, Adaptiveness, and Superior Results (McGraw Hill, 2010), surfaces out a related important point in Go-and-See problem solving: distinguishing between where the problem presented itself and where the cause of the problem originates (“point of cause”). Rother emphasizes that Toyota initiates its problem-solving effort by first seeking to understand where in the process flow the cause of a problem may have originated, rather than where it presented itself. Once the point of cause has been narrowed or identified, 5 Whys analysis can proceed much more meaningfully because Go and See can now take place at the process location where the cause occurred.

Three other improvements that I have found useful to the 5 Whys method are: first, gathering factual data and evidence to show that the answer to any “Why?” is plausible and likely; second, coupling the analysis with a risk assessment; and third, developing a timeline of the events that describe how a problem occurred.

With respect to gathering evidence to support the answer to any level of Why, it’s good to avoid the tendency to fall back on deductive reasoning to answer a “Why?” and also to build in a test loop to every level of Why that at least tries to validate the answer through factual evidence. Thus, answering any level of Why should require a Go and See to gather evidence in support of the conclusion. Only after this evidence is gathered and the conclusion supported, should one proceed to ask the next level Why.

Coupling a 5 Whys analysis with a simple risk assessment allows one to reduce the weakness in the method where the real root cause may not be found. If a 5 Whys analysis produces what a team thinks may be the root cause of a problem, but there remains uncertainty as to whether it truly is the root cause, then a risk assessment can help to determine if a more robust root cause analysis method should be employed to take the analysis deeper. One wants to avoid situations where safety is unduly compromised due to the recurrence of a problem because the root cause has not been properly identified in the analysis.

Under this approach, a risk matrix that assesses the consequences of failure is developed should the 5 Whys analysis be incorrect and the problem recur. Where the risk is shown to be low, there is little harm in accepting the conclusion of the 5 Whys process, because the consequences of a recurrence of the problem will be minimal. However, in those cases where the consequences of failure from a recurrence of the problem are high or severe, a team may decide that they need move to a more robust root cause analysis method, or further test or validate the conclusions of the 5 Whys process under controlled conditions.

In critical-to-life settings, or settings that require mitigating a high risk of failure from recurrence of a problem, those leading the problem-solving effort will likely need to use more robust methods than the 5 Whys. Examples of industries where the 5 Whys alone will likely be inadequate as a root cause analysis method include nuclear, health care, aviation, and aerospace. In these cases, users will need to move to more rigorous root cause analysis methods, including failure mode and effects analysis (FMEA) and TapRooT, a systematic process, software, and training for finding the real root causes of problems. Check out the book, TapRoot: Changing the Way the World Solves Problems, by Mark Paradies and Linda Unger (Systems Improvements Inc., 2008).

Developing a timeline of how the events in a problem unfolded is useful for identifying the timing and progression of causal factors, as well as being a helpful way for describing and communicating how a problem occurred. Many problems can be described as an ordered sequence or continuum of events that eventually resulted in a failure or abnormal condition occurring and presenting itself. Some of these events will be causal factors. Once the sequence of events in time has been established, each causal factor in the sequence can then be subjected to analysis using 5 Whys or other root cause analysis tools, thus allowing the user to build up an extensive fault tree for each causal factor.

As I noted in my previous column, a defining characteristic of Toyota is the degree to which the company induces and elicits daily contribution across its work force for continuous improvement through problem solving and learning. The 5 Whys method is an important enabler of this contributive effort—the method’s simplicity lends itself to widespread deployment and ease of use by all employees when abnormal conditions present themselves. Other problem-solving methodologies, while perhaps more robust, tend to be placed into the hands of problem-solving specialists and teams, reducing the total contributive effort for confronting and dealing with problems. 

Finally, a note about countermeasures. A countermeasure may be defined as an action (or group of actions) designed and deployed to negate the root causes of a problem.  Countermeasures are not corrections taken to address the symptoms of a problem. Thus, reworking a defective part is not a countermeasure. True countermeasures are actions or interventions taken at the system or process level that address and negate the root causes of a problem. True countermeasures are preventive in nature. If the root causes have been identified, and the countermeasure design and deployment effective, the root cause, by definition, cannot recur. In all cases, avoid workarounds and superficial fixes that leave the underlying causes untreated.


About The Author

Stewart Anderson’s picture

Stewart Anderson

Stewart Anderson is a partner with Anderson Lyall Consulting Group, a Toronto-based consulting and advisory firm that helps firms develop their competitive advantage. Anderson’s background and expertise includes competitive strategy and value chain engineering. He has advised companies in the manufacturing, service, and contract manufacturing industries. Anderson is completing his bachelor of arts in economics and he is a certified trainer in lean manufacturing principles and techniques.


Updated Reference

Enjoyed the article. Here is a link to the most recent TapRooT® Books (a series) that have been published in 2015-2018. See: http://www.taproot.com/store/Books/. For low to medium risk investigation the book to see is: http://www.taproot.com/store/TapRooT-and-reg-investigation-Essentials-Book-set.html. For major investigations, the book to see is: http://www.taproot.com/store/TapRooT-and-reg-Major-Investigations-Book-Set.html. Or you can get them as a set at: http://www.taproot.com/store/TapRooT-and-reg-minor-to-Major-Investigations-Book-Set-NEW-MAJENG-11.html.



5-Why Limitations

Excellent article, especially the part about using deductions to fill out the 5-Whys. I see that all the time.

You lost me on the last paragraph. You talk about countermeasures as actions to negate the root causes but not the symptoms. Based on that definition, the common term would be corretive action. I'm not sure the purpose of using a word different word than the one that's been in use for decades. I can't see any difference between corrective action and countermeasures. Can you expand on that?

Root Cause Analysis with 5 Whys + A good well written Process

My experience has been that in trying to solve problems using root cause and the 5 whys  will always work if you have a well written process description document

that everyone will use to guide their activities,  and when you find that root cause or causes you make sure the document gets rewritten and that everyone is retrained on

the solution after being tested and verified.   Too often this does not happen amongst all of the celabration.   

Root Cause Analysis

Good article! I have been working on an article that, hopefully, will help teams avoid some of these pitfalls and still get some good utility out of root cause analysis. I have recently begun avoiding the term "root cause" in favor of "leverage point;" mostly because of the issue with interactions.
One bad thing about reading it online, though, was that for some reason a popup ad came up and couldn't be closed, so I had to read around that ad.


Rip. thanks for the feedback on the pop-up. A handful of people experienced the same problem and we think it has been fixed.