By Michael Barna, Kepner-Tregoe
Why do people resist doing root cause analysis? “Too time consuming!” “Too expensive!” “Too difficult!”
Work arounds or best guesses are sometimes enough, but in a world of Operational Excellence, Six Sigma precision, Lean workflows, and rapidly changing, high-tech frontiers, root cause analysis expertise is essential to staying competitive and profitable.
We often come into organizations where people have learned to use classic tools for Root Cause Analysis (RCA), most notably The Five Whys and Fishbone (Ishikawa) Diagrams but have found them inadequate for finding the cause of tough problems. KT Problem Analysis provides a process that has proven effective in conducting RCAs for complex problems. Often KT Problem Analysis, Five Whys and Fishbone can be used in varying combinations to improve the RCA process. The key is to use the right RCA tools efficiently to accelerate accurate resolution.
Here are two hacks for improving RCA by combining methodologies to improve this process.
1. Make sure there is a problem that needs solving
Before diagramming a fishbone (seen below) you need a problem statement. But what if you don’t have the right problem statement or in actuality, don’t need to find cause? A Problem Statement names the symptom to be solved, revolving around the entity experiencing the problem and the specific problem that it has. It is not uncommon for problem solvers to have conflicting perceptions of the problem. In other cases, the Problem Statement is either too general or is a statement for which cause is already known.
To minimize confusion around beginning a root cause analysis and to ensure this is an appropriate use of time and resources, use this simple hack.
There are three gatekeeper questions you need to ask:
- Is there a deviation? (i.e. a change in expected, normal performance of something)
- Is cause 100% unknown?
- Do we need to know cause to take effective, meaningful action?
If the answer is no to any of these, RCA is not your best path forward: there are better ways to spend time and resources.
Plenty of situations are not deviations and do not need RCA. A deviation problem occurs when something is not performing as it has in the past. There has been some deviation in performance, and we need to know the cause to resolve it. This can relate to the performance of a thing, like a machine, an IT system, or a person.
Performing RCA is used to identify the cause of a deviation. Understanding that different kinds of problems use different methods and techniques can focus your resources on deviation problems while variation, efficiency and innovation problems are better addressed with other tools and methods. (See: What Happened? Different kinds of problems require different approaches)
To quickly determine if cause is unknown, the Five Whys can help. The Five Whys is an iterative RCA technique that is used to quickly get to cause. Before pursuing a more complex RCA, it is worth using Five Whys to determine if cause is indeed unknown. By asking Why until the answer is: I don’t know, we can ensure that cause is unknown, and we can gather insights that improve the description of the problem.
We also need to ask if we need to know cause. Sometimes a work-around is enough. Using a work around may be a better option than taking the time to find cause, such as when a machine that is scheduled for imminent replacement has a problem.
The gateway questions open the door for RCA. Note how stating: “Number One Filter is Leaking Oil” is an improvement over the initially observed problem, “Oil is on the Floor.” We could get to “Number One filter is leaking oil” by using the 5 Why’s, starting with the initial observation: Oil is on the floor… why?… Because the number one filter is leaking oil… why? … Don’t know… Do we need to know cause to fix this? … Yes.
Hack #1: Use KT’s three gateway questions before pursuing RCA. This eliminates wasted time and allows other types of problems to be addressed in more efficient ways.
2. Describe the problem first
Too often teams working together to find cause will jump to cause based on pet theories that may not be valid. Rather than listing out and categorizing all the potential causes in a Fishbone Diagram, why not just test the causes that some team members favor? The answer is that too often jumping ahead and testing for cause is premature and becomes a huge, expensive timewaster.
To counteract jumping to cause, a better approach is to step back and describe the problem precisely first before using the Fishbone to identify cause. By describing the real problem up front, you may eliminate some pet causes and can better focus the causes in a Fishbone diagram. An accurate problem description helps problem solvers evaluate the causes gathered in a Fishbone diagram by logically testing their validity against the known facts, which can eliminate entire categories of theories that fail to explain the data.
For example, if we know that the number one oil filter is leaking oil, but the number two oil filter does not seem to have this issue, we can take any Fishbone theory proposed and test it by asking the question: “If that is the cause, then how does it explain the fact that only the #1 filter is leaking, while the #2 filter is fine?” If logic dictates that the #2 filter should also be impacted given that particular theory, then it is not something worth investigating any further and we can cross that “bone” off the list. Populating a Fishbone can be an extensive guessing game. A robust, organized problem description minimizes the risk of taking wasteful action by challenging peoples’ guesses and seeing what does or does not hold up in a court of fact.
Hack #2: Before beginning to identify causes, or even worse, before jumping to cause and testing, Describe the Problem based on relevant data.
Troubleshooting teams with good RCA skills take the time to understand a problem before trying to solve it. This begins with hack #1: making sure there is a deviation problem that needs solving before using RCA and hack #2: describing the problem in specific terms based on available data.
About Kepner-Tregoe
For more than six decades, Kepner-Tregoe has empowered organizations through a proven, structured approach to problem solving. As the leader in problem-solving, KT has helped thousands of organizations solve millions of problems through more effective root cause analysis and decision-making skills. Through our unique blend of training and consulting, our clients demonstrate improved efficiency, higher quality and greater customer satisfaction while reducing their costs.