Structuring Your Root-Cause Analysis Meetings for Success

How productive are your organization’s root-cause analysis meetings? To help answer this question, consider the following questions:

1. How often do your root cause meetings begin with objectively gathering data to describe the problem?

2. How often do your root cause meetings begin with exhaustive discussions of possible causes, and end with people leaving to investigate numerous theories?

3. How often do your root cause meetings result with a most probable cause?

If you answered “often,” “not often” and “often,” then your root cause meetings are already likely to be productive, and the results are proof. By contrast, if your answers were “not very often,” “quite often” and “seldom,” then please continue reading, as the contents of this article might stimulate your thinking.

Typically, when asked how much time they allot for these types of meetings, most people answer one hour. If one hour is the average, scheduled timeframe for a root cause meeting, then how should these meetings be structured to maximize what participants take from them? What’s the best way to organize these meetings to minimize participants having to reconvene and return to the same discussions when next steps are unproductive? What’s the best approach when discussions of causes are so exhaustive that meetings don’t accomplish much and must be continued later?

What follows are three common pitfalls of root cause meetings and Kepner-Tregoe’s suggestions for how to avoid them:

Pitfall #1: The meeting begins and people are not clear on the problem being addressed.

Solution: Set a clear theme for the meeting the moment it begins (or communicate it to all stakeholders in advance). This will set the boundaries for discussion and clarify whatever is not in scope, saving time from discussing unrelated topics.

Within the confines of the theme, prepare a list of the issues. If there are multiple problems, then write them into a document. Clarify the symptoms, keeping the focus strictly on what is being observed rather than what is being theorized.

If there is one clear problem, then use of the “5-Why” approach is beneficial to focus on the core issue that is “cause unknown.” When your team has focused exclusively on the specific issue, there is another question that should then be considered:

Must you know the cause to take effective, meaningful action?

Not every problem requires a root-cause analysis. In some cases, a workaround or adaptive action might suffice, in which case the remainder of the meeting might become a decision-making discussion on the best method to fix the issue, rather than an analysis of its diagnosis. Of course, if knowing the cause is unnecessary and you can either fix or live with the symptom, then continuing to talk about root-cause analysis is a waste of time.

Pitfall #2: The meeting continues with an exhaustive discussion about possible causes that prove to be distractions.

Quite often, the stakeholders walk into these meetings with a predefined sense of what they think is happening. People have their “pet causes” and are passionate about pursuing them. After clarifying the problem to be resolved, most people will be keen to speak about their ideas. In one sense, it’s important to allow for some discussion, because, otherwise, the participants will just be waiting for their turn to talk as opposed to actively listening to others, and the results won’t be good. Discussing possible causes, however, can quickly become counterproductive when the discussions become so extensive that they consume the meeting and result in people leaving to take haphazard actions on their theories. In addition, when time is money, root-cause analysis should not be a game of “my cause is better than your cause and I will prove it.” Doing so results in spending much money, often wasting much time in the process, and potentially changing the environment in ways that can make finding the true cause even more difficult.

What percentage of your root cause meetings often reflect the picture painted above?

Solution: If you only planned an hour for the meeting, then allow for some discussion on possible causes, but only to the point where people have dumped what’s on their minds. Create a list of peoples’ theories as they are mentioned, so participants are content their idea has been noted. At this point, once the discussion has reached a standstill and there is silence in the room, stop the conversation and move to clarify the facts known about the problem. Restrain people from leaving prematurely to investigate any theories. Just because a possible cause could logically create the symptom being seen does not mean it’s the true cause at work.

Just think, when during the past have you seen others take unnecessary actions to investigate causes that proved to be false?

Pitfall #3: Teams do not spend enough time gathering facts to describe the problem before jumping to cause.

This doesn’t have to be a rigorous process, but consider the alternative. What’s the potential impact of not taking sufficient time initially to describe the problem you are experiencing?

As mentioned above, from passion for their pet causes, people often gather data to prove that their cause is more likely than another. Indeed, in a test environment, someone could probably create various experiments showing how many theories could trigger the type of symptom being seen. Yet, what first must be understood are the actual conditions present.

Solution: Teams should take at least 15 minutes to parse well-formed, pointed questions that specify and organize the known facts of the problem. If the right experts are already in the room and the data they have is accurate, then this should not require much time and is hugely beneficial. Once the available information has been documented, it is the appropriate time to consider possible causes, but with the intent to evaluate them against the facts.

At Kepner-Tregoe we use a powerful, proven technique for gathering problem data that enables teams to eliminate quickly false causes and use logic to suggest a cause that’s most probable. Our experience has proven this process to be effective in as little as 15 minutes (assuming the inputs people bring are on point), a time period during which teams use available information to guide their discussions on cause and logically plan next steps.

The positive behavior we are trying to promote: Avoid investigating false possible causes by using the facts of the problem to eliminate theories that don’t make sense. The result should be one or two remaining causes based on logical assumptions. From there, teams can discuss what next steps make the most sense.

The negative behavior we are trying to prevent: Gathering as much data as humanly possible and fishing for causes without an understanding what you are seeking. Just think – most organizations have hundreds (if not thousands) of changes happening daily in their environment and examining each of those changes as a possible cause would be a colossal waste of resources. A good description of the problem can swiftly narrow the range of what information must be evaluated to determine the cause, potentially saving hours of unnecessary effort.

When you consider the above and plot it on a meeting itinerary, a productive root cause meeting might look more like this:

Root cause meetings should be logic-driven rather than impulse-driven. Knee-jerk reactions to finding cause rarely help and often make the process unproductive and the problem worse, especially if they arise from people’s assumptions rather than facts. Taking the time to describe clearly the problem is so important; data should support the assumptions or hypotheticals, or are eliminated from consideration. At the end of the day, if people spend any money testing causes, then it should be on those that explain what’s actually occurring.