Struggling at root cause analysis? Does it often feel like you’re going in circles to resolve performance issues, continuously going back to refine or implement new corrective actions? Here’s some helpful advice: when engaged in root cause analysis scenarios, don’t initially focus on possible causes, but instead focus on better understanding the problem.
You might be thinking, “But isn’t it important to identify possible causes if we’re ever going to get to root cause?” Of course, identifying possible causes is critical, but over the years providing root cause analysis training and support at PDA events, public sessions, and directly with organizations, the strongest lesson we’ve learned when it comes to root cause analysis, and the most common mistake we see being made over and over again by good, intelligent people, regardless of job function, organization, industry, country, continent, culture, etc. is to focus first on possible causes. Why? The adage
“Let’s not get the cart before the horse” comes to mind. I suspect it’s indicative of human nature: we want to solve the problem as quickly as possible, so intuitively it seems like immediately generating a list of possible causes is a good place to start. Additionally, many organizations implement tight timeframes for root cause analysis… we’ve had some clients require root cause analysis be completed in as little as five business days. The pharmaceutical industry typically uses 30 days. However, there is no regulation which specifically requires this timeline. Yet with these types of pressures, it’s understandable that many of us want to cut to the chase and immediately begin generating a list of possible causes.
Subscribe to our e-Newsletters
Stay up to date with the latest news, articles, and events. Plus, get special offers
from American Pharmaceutical Review – all delivered right to your inbox! Sign up now!
Here’s why we recommend refraining from immediately identifying possible causes: very often we’re trying to identify possible causes for a problem we really don’t understand in any great detail. Typically, we have a little bit of information up front about the problem: some feedback from a few customers, a handful of defective products, data demonstrating process performance is outside of control limits, spec limits, etc. We take the knowledge gleaned from this limited, often unsubstantiated data, and generate our list of possible causes. We then select the one we think is most likely the root cause and implement a corrective action plan. Days…weeks…perhaps months go by…and the situation continues to occur. The next most likely possible cause is selected and addressed…same result. The third most likely possible cause is selected…this time success.
This is what we call the “trial and error” approach to root cause analysis. If this sounds familiar then ask yourself, what is the first tool you typically like to use in a root cause analysis situation? If your answer is a Fishbone (Cause & Effect or Ishikawa) Diagram, perhaps this does describe the routine process used. After all, the Fishbone Diagram is a brainstorming tool designed to help identify possible causes.
To be fair, the approach to root cause analysis described above can and will identify root cause if all issues are identified by shop floor visits and open conversations with all team functions involved. After all, from our experience this is how most people approach root cause analysis, and most of the time we truly do identify root cause.
Sometimes this strategy will even identify root cause quickly. However, from our experience, identifying root cause quickly by using this method is the exception to the rule, not the rule. In fact, we typically find identification of root cause taking weeks or even months longer than it should, depending upon the situation. Additionally, these occasional “quick wins” can have a negative effect on our psyche, as they have the potential to condition us into thinking this is the best approach to root cause analysis, when over time this approach leads to longer, more expensive, more arduous situations with a whole lot more exposure to various risks than necessary. To illustrate, some examples will be provided further into the article.
Instead of initially focusing on possible causes in a root cause analysis situation, we have found that making an additional investment up front to describe, and get everyone involved to develop a common understanding of the problem in greater detail results in more rapid and accurate root cause determination. One of the most effective techniques for doing this is leveraging a structured Is/Is Not Diagram in a systematic manner, see Table 1.
This tool helps a team describe the problem as it compels the users to consider a variety of perspectives regarding what, where, when, and how much the problem is, as well as what the problem is not. While some of these questions would have intuitively been asked without such a tool, chances are many of these perspectives most likely wouldn’t have intuitively been considered or may have been sidelined in the assessments because deep knowledge in an organization would discount a question by responding that a particular point is not a problem because of data available. Use of this tool helps allow for all issues and questions to be surfaced and data to be collected for both what the problem could be and to collect data supporting what the problem is not. The Is/Is Not Diagram when leveraged this way, is the foundation for a data collection plan to verify our initial understanding of the problem, then to expand on that description by determining and collecting additional data that would be helpful in understanding the issue by moving more quickly to the cause and not focusing on the symptom of the problem. For maximum effect, solicit input from people in functions related to the problem (manufacturing, quality, validation, key suppliers, etc.) to ensure the problem is understood consistently and objectively by all parties. These investments in time to gain clarity and will assist in narrowing the scope of the root cause analysis scenario, perhaps even significantly.
Upon completing this assessment using the tool above, then the Fishbone Diagram or other tools and techniques historically leveraged to identify possible causes can be used with more focus and effect. The knowledge gained from the investments in understanding the performance problem in greater detail will be very beneficial in helping generate more specific, as well as higher quality possible causes. Additionally, many of the irrelevant possible causes that would have been considered without the knowledge gained can be discounted more quickly, while being documented in the table for later assessments by regulators and auditors. Therefore, this approach should capture all possible options considered and discounted or supported, providing evidence of the depth of the assessment.
Here’s a real-world example of this concept in action: A few years ago a medical device plant had a decline in the performance of their sterilization process that was creating a loss of capacity approaching $2 million. The plant began their root cause analysis using the fishbone approach, immediately focusing on possible causes. Six weeks passed and no progress had been made while costs and management pressure continued to escalate.
An engineer suggested they try the approach of halting the search for possible causes for a while and instead focus their efforts on better understanding the problem in greater detail. We don’t know why this engineer took a while to speak up; perhaps there was fear that this approach would be perceived as lacking urgency. Whatever the reason for the delay, management consented to trying this approach. The first day a robust problem description was created that significantly deepened their understanding of the issue at a factual level. Within three days their list of possible causes was narrowed down significantly. At that point focused experiments were the conducted that identified three separate technical root causes. Corrective action plans were implemented. This assessment approach resulted in manufacturing being restored, no recurrence of the sterilization failure, and the majority of the loss was averted.
Another real-world example in a different organization was that they were investigating a product failure that was costing $10,000 every time the situation occurred (which occurred every other day). A root cause analysis team was quickly formed and they immediately began generating a list of possible causes based upon their limited understanding of the problem. This analysis lead the team to believe the issue was mostly likely coming from the machine used to make the product. For the next month the line was shut down as they inspected and experimented with every aspect of the machine, only to finally determine this issue couldn’t be caused by the machine. Imagine their frustration at the time, and expense lost! At that point the focus of the root cause analysis shifted to a better understanding and description of the performance problem.
This required additional data collection, but within a week it was determined that this problem must be occurring during shipment of a particular material used in the product.
Upon receipt of their next shipment of this material from their supplier, the root cause was identified, corrective action was implemented that restored performance, and preventive action was taken to minimize similar occurrence in the future.
Over the years we’ve seen countless other examples like this where investigators spent significant amounts of time exploring possible causes that were irrelevant to the root cause analysis scenario because they prioritized the list of possible causes over their understanding of the problem without gaining a common understanding of the problem.
So why do smart, intelligent people continue to approach root cause analysis this way? Several possible causes have been shared throughout the article: it intuitively seems like it’d be faster; there’s organizational pressure to close the root cause analysis quickly; we’ve occasionally had success with this approach. I suspect many of you could come up with other plausible reasons as well. But out of all the root cause analysis best practices we’ve learned over the years, refraining from identifying possible causes until after a robust problem description has been developed has by far been the most helpful technique to establishing a strong foundation for the root cause analysis scenario, ultimately leading to faster, more accurate results.
In conclusion, it is helpful to resist the temptation to immediately begin identifying possible causes when engaged in root cause analysis situations. Invest time in better understanding the problem. Explain to your leadership team why you’d like to make this investment; ask for their support and buy-in. Be patient. Collect objective data that is re-assessed in light of this problem event. This may take more time up front, but I suspect the Fishbone Diagram and other techniques leveraged to identify possible causes will, over time, lead to true root causes more quickly and accurately than before. And if you begin to doubt, ask yourself this simple question: has root cause analysis based upon the limited initial information available consistently resulted in faster, more accurate identification of root cause for you?
Author Biography
Rob Weaver is President of Weaver Consulting, a small enterprise with a global footprint. They focus exclusively on root cause analysis across many industries, including pharmaceutical, medical device, aerospace, defense, financial services, food & beverage, consumer products, automotive, telecommunications, semiconductors, and more.