by Mark on August 2, 2010
Have you ever found that you’re spending time you should be investigating a problem arguing about how to document a problem? Have you spent valuable time in meetings explaining your documentation method or software? Rather than discussing how to prevent the problem from recurring, are you trying to fit the incident into a neat check-box to enter it into your software program?
If you’re nodding “yes” to any of the above, you may need a new root cause analysis method. Remember, the people in the investigation should be focused on the details of the issue, not the method. The focus is on the details of the issue that is being worked. Any discussion about anything besides the incident is a distraction – including the method that’s being used.
If your root cause analysis investigations are being controlled by the program you’re using, the best root cause analysis software for you might be a program you already have – Microsoft Excel. Because Excel isn’t a pre-packaged root cause analysis software, you can use its drawing functions to document your incident in the way that’s best for your organization. Because Excel is so easy to use, with a little bit of practice you can customize it to fit the needs of your organization for each individual incident.
Using Excel to document your root cause analysis investigations allows you to focus on the investigation – not the software or method. Only then will your employees be able to fully focus their attention towards finding the best solutions.
by Aaron on June 18, 2010
For those that have attended a Cause Mapping Workshop, you may recall that we spend a significant amount of time talking about the connection between work process and cause-and-effect. It is fundamental to any problem investigation. After all, if a work process is a series of steps to produce a desired result, then you have problem anytime you don’t get the expected results from your processes. In order to solve the problem, you must identify the causes of the problem. The causes of the problem within your organization will eventually tie back to specific breakdowns in the work process. Specific solutions can then be identified that make specific changes to your processes going forward… also know as continuous improvement.
While the connection between process and cause-and-effect is obvious, organizations typically struggle to use this connection to their advantage during an investigation. As a result, the investigations stop short of where some of the best solutions reside and typically focus only on what they call the human element of the problem. For example, a common conclusion to a problem investigation is simply that a “procedure was not followed”. The proposed solution: “reinforce the procedure” or “retrain on the procedure”. Sound familiar? If it does, then you can probably attest to the solutions’ ineffectiveness at actually solving the problem.
So why do we continually fall back into this trap? We have a tendency to try and simplify the incident investigation which results in generalizing the causes. If you have generic causes, you get generic solutions. It’s at this point that the investigation should be taking the opposite approach and diving into the specific details of the process/procedure that was ineffective. This is easier said than done, but there is a simple tool that can be extremely helpful… a process map. Next week I will discuss how to use a process map to improve your investigations.
Reinforcing a procedure doesn’t do anything to address gaps within. If someone doesn’t follow a procedure, it is important to identify “Why?” the procedure wasn’t followed. Only then will you find that the details aren’t as straightforward as they seem.
