Featured Video
This Week in Quality Digest Live
FDA Compliance Features
Robert M. Califf
Progress and potential report
Nina L. Hunter
Progress and potential report
Dara Corrigan
A new path for pharmaceutical inspections in Europe and beyond
Solid record-keeping and document management are key
Michael Causey
It was a busy year for Health and Human Services

More Features

FDA Compliance News
Awards help states implement multiyear produce-safety systems
The future of medical product development?
Manage risk while meeting regulatory requirements and compliance
FDA believes you can use openFDA to create products that promote public health
Company headquarters and 30 jobs in Dayton, operations in Europe, stay in place
Four guidelines for industry offer useful tools for manufacturers

More News








Stewart Anderson

FDA Compliance

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 - 05:00

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 Toyota founder Sakichi Toyoda 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. The architect of the Toyota Production System, 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.”1

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. 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 monozukuri2.”3

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 new 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 TapRooT4and failure mode and effects analysis.

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.


1. Taiichi Ohno Toyota Production System: Beyond Large-Scale Production. (Productivity Press, 1988)

2. A Japanese term that translates as “making things.”

3. From an article on TPS posted on Toyota Motor Manufacturing Kentucky (TMMK) web site

4. TapRoot: Changing the Way the World Solves Problems, by Mark Paradies and Linda Unger (Systems Improvements Inc., 2008)


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.


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.