About | Contact | Support | Blogs | Privacy Statement
By following a structured and disciplined methodology you can achieve a deeper understanding of the root causes of any problem. The “5-Whys” Root-Cause-Analysis (RCA) methodology was invented by the founder of Toyota, used in their manufacturing process, and continues as one of the tools in the modern lean methodologies tool kit.
The “5-Whys” embody the natural curiosity of humans that is obvious in children (and romantics), but somehow lost as we become "responsible" adults. “Why does it get dark at night”? “Well, because, the earth spins away from the sun at night.”. “Why does the earth spin?” “Well, this is kind of hard to explain.” “Why?” (Inevitably, the answer becomes “It’s just the way it is”)
Let’s apply “5-Whys” to a real life example. If you ask anyone familiar with the details of the 1986 space shuttle Challenger disaster, what caused the shuttle accident? They will likely say “the O-rings”. While the “O-rings” is a necessary part of the explanation, it is insufficient in providing a complete picture of what led up to that fateful moment. You may say “that’s all I want to know”, and that’s fine; there’s nothing that says that all of the details must be understood by everyone. But for those who want to know the complete story, “5-Whys” can help.
The [Report of the Presidential Commission on the Space Shuttle Challenger Accident] [2], provides the facts used to develop this example. Though investigators may have used “5-Whys”, there is no specific evidence that this was the selected method. Following is the “5-Whys” analysis tree based on this information.
Note that the structure of the analysis tree consists of a “Why” question followed by a theory that answers that question. Based on that theory, a new “Why” question is formulated and a theory about that question is stated. This process continues for as long as the question remains relevant (5 times is just stretch goal to prevent a premature decision from being made).
It is important that the theory be stated in terms that would enable a “Why” question to follow. For example if the question asked earlier about what caused the accident, and the answer “the O-rings” were left unchallenged, we would be left without any new insight. The challenge should be “what about the O-rings?” and the response might be, “well, they failed”. Now we can ask the question “Why did they fail?” This is where the process usually breaks down. We allow our impatience to outweigh our curiosity, and don’t want to annoy anyone with obvious and obnoxious questions. But as you can see in the analysis, persistence revealed the fact that this was a known problem, and the mission was allowed to proceed anyway.
The explanation in the analysis actually provides a more comprehensive explanation for the O-ring failure, because we also challenged the upstream premises. For example, the question should also be asked “How could an O-ring failure cause the shuttle to explode?”. “This caused a seal failure in the segments of one of the solid rocket motors”. “Go on”. “That caused hot gases to escape onto the external hydrogen tank”. Eureka! Now we have a much richer explanation for the whole episode.
Note that while the “Why” question is used to traverse the tree in a downward direction to get to the ultimate root cause, we can use “Because” to help explain the conclusion from the bottom up. For example: Because there were serious flaws in the launch decision making process, the mission was allowed to proceed with a known design flaw.
With this more comprehensive picture of what really happened, the person who only cared that it was the “O-Ring” that caused the failure, now may want to know more about the decision making process at NASA. In other words, this issue now becomes relevant to them.
The “5-Whys” tool has been criticized, even by former Toyota executives, for being too basic to analyze root causes to the depth needed to ensure causes are fixed. To me, this is like saying:
“I’m disappointed in the new screwdriver set I got for Father’s Day because I can’t use them as chisels”.
Every tool has a purpose as well as limitations and both need to be well understood.
Some things to keep in mind while implementing a “5-Whys” Root Cause Analysis:
This paper talks about a specific technique for performing Root Cause Analysis (RCA). RCA is often is treated as busy work or something that needs to be done to satisfy the VP of Quality. But RCA is only one step towards the broader goal of implementing permanent corrective actions, which is beyond the scope of this discussion. (Additional discussion will be offered to discuss 8D, or 8 steps in problem solving, of which step 4 is RCA).
The important point here is that RCA must be treated as a necessary step in product development and support. You wouldn’t think of shipping a software release if it doesn't pass its testing criteria; nor should the RCA process be short cycled.
I believe this is more of a problem when dealing with processes rather than automated systems. Politics become more of a potential issue in process discussions and agreement on the root causes become more arguable or more subjective. This is where “5-Whys” shows itself as a powerful tool; when you hear “That’s just the way it is” to your why question, you know you’ve stepped on a sensitive issue, but at least you opened the discussion to discover the true root cause.
“5-Whys” is a structured methodology for finding the root cause of a problem, whether in an automated system or a process. The power of this approach lies in the fundamental question “Why”? “What” happened is usually a much easier question to answer than “Why” it happened. But asking too many “tough” questions may cause the team or organization to become annoyed. However with management support and a disciplined execution, “5-Whys” could be one of the most powerful tools in your toolbox.
Links:
[1] http://www.ceptara.com/node/597
[2] http://science.ksc.nasa.gov/shuttle/missions/51-l/docs/rogers-commission/table-of-contents.html
[3] http://www.ceptara.com/taxonomy/term/4
[4] http://www.ceptara.com/taxonomy/term/7
[5] http://www.ceptara.com/taxonomy/term/3