Tuesday, February 14, 2012

Five Why "Nots": 5 Reasons Why Reliability Engineers Should Use More Than 5 Whys for Root Cause Analysis

First of all let's talk about what Five Whys is before we mention what it is not. It is a problem solving tool used in many facilities and is commonly associated with Lean, Six Sigma and Kaizen implementations. The technique was originally developed by Sakichi Toyoda and was used within the Toyota Motor Corporation during the evolution of its manufacturing methodologies. The method is quite simple really and involves asking "why" multiple times until the individual believes that they have reached the process cause of the problem. This sometimes (but not always) means you will stop at the fifth "why" hence the name.
While I like five whys as an "on the floor" problem solving tool I cringe when people call it root cause for five reasons:
1. There really is no such thing as "root cause" a more correct phrase would be "root causes” because there are almost always conditions and actions that come together to manifest the failure. 5 whys as it is most often used only addresses one branch of the causal chain either the condition or the action.
2. By only following one causal chain you do not get the opportunity to analysis all the contributing causes and look for the lowest cost solution that eliminates or mitigates the risk to an acceptable level.
3. The results from 5 Whys are not repeatable. Different people using 5 Whys come up with different causes for the same problem. It is all based on their existing knowledge, and experience.
4. Five Whys many times is just used to prove what the practitioner already thought instead of looking at other possibilities. 5 Whys investigators are plagued by an inability to go beyond their current knowledge which leads to them not identifying causes that they do not already know.
5. My experience tells me that Engineers that use five whys solely do more investigations due to problem reoccurrence. They are sometimes celebrated for their ability to do 27 RCA investigations per month but when you look at the list 18 are problems that they should have taken the time to do a true analysis the first time and they would not be focusing on them again. Using the 5 why method causes a tendency for investigators to stop at symptoms rather than going on to lower-level root causes. This leads to reoccurrence of the problem.
So as I mentioned earlier Five Whys is a great tool for shop floor trouble shooting but if you are going to focus on root causes then you may want to consider the more advanced root cause analysis tools. I would suggest that root cause tools like logic tree or fault tree will identify more of the contributing factors and decreases the chances of failure reoccurrence. To see how to make a simple transition from 5 Whys to logic tree check out this single point lesson here. 
Good luck solving your problems and I hope you have fun doing so!


  1. Shon,
    Although I do agree with your first point, there are always multiple causes to any malfunction. However, the 5-why analysis tool was introduced and should be used to help the techs and operators on the shop floor to not only make a repair but to think about what may have caused the malfunction in the first place.
    Anyone who uses the 5-why method as their single tool for "root cause analysis" as a rule is missing out on some opportunities.
    My point being, the 5-why was never intended to be the only RCA method out there. Most methods or tools are much too clumsy to be used in the plant. Most of them require a group and an office and maybe even a computer to use.
    That is why the 5-why analysis is so widely used. It is simple. It can be taught easily. Anyone can use it and use it quickly, and it will without a doubt lead to issues that may not have been thought about if it wasn't used.
    It gets my vote for the first step in cause elimination.

  2. Randall,
    Great points. I agree it is a great tool for "on the floor" but not as your only tools in a Reliability Engineer's tool belt. When I teach RCA methods I always build off of the five why by simply branching it into a fault tree and then by adding logic symbols (and and or) we can transition that to logic tree. This Transitional Method is covered in more detail in a single point lesson here.