How productive are your organization\u2019s root-cause analysis meetings? To help answer this question, consider the following questions:<\/p>\n
1. How often do your root cause meetings begin with objectively gathering data to describe the problem?<\/p>\n
2. How often do your root cause meetings begin with exhaustive discussions of possible causes, and end with people leaving to investigate numerous theories?<\/p>\n
3. How often do your root cause meetings result with a most probable cause?<\/p>\n
If you answered \u201coften,\u201d \u201cnot often\u201d and \u201coften,\u201d then your root cause meetings are already likely to be productive, and the results are proof. By contrast, if your answers were \u201cnot very often,\u201d \u201cquite often\u201d and \u201cseldom,\u201d then please continue reading, as the contents of this article might stimulate your thinking.<\/p>\n
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\u2019s 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\u2019s the best approach when discussions of causes are so exhaustive that meetings don\u2019t accomplish much and must be continued later?<\/p>\n
What follows are three common pitfalls of root cause meetings and Kepner-Tregoe\u2019s suggestions for how to avoid them:<\/p>\n
Solution:<\/strong> 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.<\/p>\n 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<\/em> rather than what is being theorized.<\/em><\/p>\n If there is one clear problem, then use of the \u201c5-Why\u201d approach is beneficial to focus on the core issue that is \u201ccause unknown.\u201d When your team has focused exclusively on the specific issue, there is another question that should then be considered:<\/p>\n 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.<\/p>\n Quite often, the stakeholders walk into these meetings with a predefined sense of what they think is happening. People have their \u201cpet causes\u201d 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\u2019s 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\u2019t 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 \u201cmy cause is better than your cause and I will prove it.\u201d 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.<\/p>\n What percentage of your root cause meetings often reflect the picture painted above?<\/p>\n Solution:<\/strong> 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\u2019s on their minds. Create a list of peoples\u2019 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\u2019s the true cause at work.<\/p>\n Just think, when during the past have you seen others take unnecessary actions to investigate causes that proved to be false?<\/p>\n This doesn\u2019t have to be a rigorous process, but consider the alternative. What\u2019s the potential impact of not taking sufficient time initially to describe the problem you are experiencing?<\/p>\n 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.<\/p>\n Solution<\/strong>: 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.<\/p>\n 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\u2019s 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.<\/p>\n 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\u2019t 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.<\/p>\n 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 \u2013 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.<\/p>\n When you consider the above and plot it on a meeting itinerary, a productive root cause meeting might look more like this:<\/p>\n <\/p>\n 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\u2019s 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\u2019s actually occurring.<\/p>\n","protected":false},"excerpt":{"rendered":" How productive are your organization\u2019s 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 […]<\/p>\n","protected":false},"author":17,"featured_media":426,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[],"ppma_author":[],"class_list":["post-25061","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"acf":[],"yoast_head":"\nMust you know the cause to take effective, meaningful action?<\/em><\/h4>\n
Pitfall #2: The meeting continues with an exhaustive discussion about possible causes that prove to be distractions.<\/h4>\n
Pitfall #3: Teams do not spend enough time gathering facts to describe the problem before jumping to cause.<\/h4>\n
\n\n
\n Time<\/strong><\/td>\n Topic being discussed<\/strong><\/td>\n<\/tr>\n \n 0-5 minutes<\/td>\n Introductions and clarify meeting theme<\/td>\n<\/tr>\n \n 5-10 minutes<\/td>\n Clarify the issues and problem to be addressed, use \u201c5 Whys\u201d as needed to dig deeper<\/td>\n<\/tr>\n \n 10-20 minutes<\/td>\n Discuss and list possible causes per peoples\u2019 knowledge and experience<\/td>\n<\/tr>\n \n 20-35 minutes<\/td>\n Gather facts to specify the problem<\/td>\n<\/tr>\n \n 35-50 minutes<\/td>\n Revisit possible causes, eliminate those that fail to explain the facts of the problem and narrow your focus to the few that do<\/td>\n<\/tr>\n \n 50-60 minutes<\/td>\n Plan next steps based on your investigation of the cause that seems to make the most logical sense<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n