Question: After every significant incident we complete the “5 Why” process. This is supposed to help us identify more accurate root causes that will help us find better solutions to prevent recurrence except, it rarely does either thing. Most of the participants haven’t gotten a lot of training in this process and are afraid to discuss the hard truths about why incidents often occur and even worse, their solution to almost everything is to “perform retraining”. How can we move past this and start to get some value out of this process?
When companies experience a lot of recurring incidents or just incidents in general, it’s not uncommon for them to want to do things to improve that situation. One of the most common things companies will do is to adopt post-incident activities like the Root Cause Analysis and/or the 5 Why. When done well, these activities can spawn much-needed discussions that can lead to enduring change but, like with anything else they have to be implemented the right way. When they aren’t, they will quickly become busy work that takes up time without providing anything of value in return. And, if a company has a good number of incidents this could mean a lot of wasted time which will eventually lead to a general disdain for the entire process. Now, while we can’t answer for your situation specifically, we can provide some insight and a few suggestions to help you get the most of out your post-incident analysis activity.
Planning
The key to a smooth implementation is proper planning and that planning begins with deciding what you want to do, how you want to do it, and who should help in that endeavor. To get the ball rolling, here are a few basic questions you will need to answer:
- Do you want to adopt a full Root Cause Analysis (RCA) program that uses software or do you want a simple 5 Why process that requires only minimal training—or do you want both?
- When will you require them to be conducted? After every incident or only after incidents of a certain type and/or severity?
- How will you evaluate the effectiveness of the finished product?
- How will you ensure the process stays intact and on track?
- Who will be required to attend training and lead the process after qualifying incidents happen?
These are just a few of the things you need to iron out before you jump in and get going. We know that figuring these things out might be more than you were looking to do but anything that’s worth doing is worth doing well, isn’t it?
In your case, since you’ve already started with this process and are already seeing what happens when things maybe aren’t implemented as well as they should be, it might be time to stop what you’re doing and start over. At the very least you’ll be showing the workforce that you’re aware the process isn’t providing as much value as it could and are interested and willing to do what’s necessary to make it work, which is always a good thing.
RCA, 5 Why or Both?
We’re not going to get into the individual merits of the different types of post-incident analysis methods but we are going to offer you a suggestion that we strongly encourage you to give some serious thought to—and that’s implementing more than one type of post-incident analysis and doing so based on incident types and/or severity. Many companies will only require an RCA or a 5 Why after serious or significant incidents and never for smaller incidents like near misses or incidents that only required basic first aid—but those are the very incidents that will often yield the most valuable information. So, to capture some of this really important data, our suggestion is to implement an RCA process for significant incidents that require off-site care or some other threshold that works for you and to implement a basic 5 Why process for everything else.
We know this sounds like a lot of work but in the long run, it’s actually going to be less work for those who have to perform these activities. Having separate processes for different types of incidents means more serious incidents get more serious attention and less serious incidents are still analyzed but with a much simpler process.
Setting Boundaries
Once your process is set up and implemented, you’re going to want to set a few boundaries to keep certain things out of the process—like placing blame and making things personal. This is really important because one of the things that can often derail everything is turning the process into the blame game and making it personal. When this happens, you’ll start to see a change in participation from meaningful to superficial—with outcomes to match.
To prevent this from happening, it’s critical to keep the focus on the action and not the person. By doing this, you’re separating the personal aspect of things and reducing the possibility of placing blame on one person. And let’s be honest, if a poor decision is the true root cause of an incident, you can bet it’s being perpetrated by more than one person. So, any solutions implemented to help prevent that same poor decision from being made again will provide the most benefit.
Another important boundary that needs to be established is the solution generation process. Without some ground rules in place, you’ll end up with a bunch of solutions that sound good on paper but that won’t be sufficient to prevent a recurrence. One such “solution” we’d like to specifically discuss that’s often used but that isn’t really a solution is “re-training”.
Why are we picking on re-training? Because providing re-training on the same thing you’ve already trained someone on (possibly more than once) isn’t going to be any more effective than it was the first time. For example, if a worker has an incident on a forklift and you pull them off the forklift and provide them with retraining sure, you’re meeting the federal training requirements for powered industrial vehicles—but how is a second or third round of training going to prevent them from doing the same thing again? The answer is that it’s not. In this situation, it’s highly possible that the root cause you decided on wasn’t really the true root cause, and going back to the drawing board to find the actual root cause may be the best idea.
No matter what boundaries or ground rules you decide on for solution generation, make sure they include preventing recurrence because after all, that’s why you’re generating solutions, to begin with, isn’t it?
Evaluating for Improvement
Periodically evaluating your process is going to be what keeps it healthy and in good shape. A regular review of the process that includes sitting in on an actual RCA or 5 Why as it’s being performed will help make sure things are still being performed as required and that the process is still effective. Additionally, it will also open the door to ideas for improvement and as everyone knows, worker buy-in is always a good way of getting people more interested in participating in activities.
If during the evaluation process you happen to discover problems with how things are being performed or if you find other areas of concern, it’s important to provide correction immediately. When this happens, it’s also important to remember that it may mean you have to modify how often you’re evaluating the process and possibly attend a few additional sessions to make sure that the corrections you’ve provided are being taken seriously.
Another type of evaluation you might consider adding especially if you’ve implemented a full Root Cause Analysis program is a process to evaluate or even score every completed RCA. By setting up an internal evaluation or scoring process, you’re essentially providing “quality specs” for your RCAs and making sure that each one meets those specifications. This kind of evaluation also helps keep the process uniform between locations or shifts.
Final Thoughts
No matter which type of post-incident analysis activity you’re performing, it’s important to have a plan, do some training, set boundaries, and regularly evaluate how it’s going. By doing this you’ll not only be continuously improving your process but you’ll also be ensuring this activity doesn’t become busy work and provides some actual value to your operation.
