Several days ago I was dictating notes to Siri to remember for later. I asked Siri: “Do we do enough to get to the root cause during accident and incident investigations?” as a reminder to work on this article. Instead of adding this question to the notes in my phone, Siri responded: “That’s an interesting question”. I thought, really, that is an interesting question.
Recently, executives from a major oil company in Alberta released the findings of their investigation into a fire and explosion that killed two workers. The conclusion: ‘Human Error’. Really? The company alleges that they could not have done anything differently… What about providing more training before the workers were assigned to work in an area they didn’t normally work in? Or holding supervisors and workers more accountable for the work permitting process? Or assessing how recent layoffs would affect maintenance worker actions?
We cannot be getting to the root cause if the conclusion of an incident investigation is that ‘human error’ is the cause.
So, are we not using the right root cause analysis methods for our investigations?
I believe that there’s no ‘one size fits all’ method when it comes to root cause analysis. I looked at three popular root cause analysis methods, ‘Five Whys’, ‘Fishbone’ and ‘TapRooT™’, and offer some thoughts on what type of incident or problem they work best for.
There is one component that I believe all three methods share: a Timeline or Sequence of Events chart. Regardless of the degree of severity of an incident or problem, there’s something powerful about taking the time to systematically list the sequence of events onto paper. Once this timeline is created, it often becomes very apparent where the mistakes or failures lie. TapRooT™ calls these ‘Causal Factors’, while the Fishbone method uses these as spines that can’t be disproved as a possible cause. The Five Whys method uses these as factual evidence to answer the recurrent question of ‘why?’.
TapRooT™ is a 7-Step Investigative process that is very structured and provides objective guidelines to the investigation team. I use this method when I suspect that there might be a lot of emotion involved in the investigation; the TapRooT™ tree allows the facilitator to keep the investigation team objective. It is a very thorough and comprehensive process. I like to use this method when I suspect clients have already decided what the cause is – sometimes they are correct, but often, other overlooked causes are identified. However, TapRooT™ takes a fair bit of time to apply and requires a licensed facilitator. I find that TapRooT™ is not ideal for equipment failure events, or events where there is a rather simple sequence of events.
If the incident involves sequential events, and the investigation team is experienced and can keep subjectivity at bay, the ‘Five Why’s’ method could work best.. When you’re presented with a problem, the ‘Five Whys’ method repeatedly asks the question, “Why?”. Five is an arbitrary number, but a suitable rule of thumb to adequately get closer to the root cause of your problem. Each time you ask “Why”, you will inevitably be led to another question that will get you closer to your root cause.
Confused? Think about a young child who persistently asks “Why”. You are stuck in traffic, and this child asks, “Mommy, why are we stopped?”
Well, because there’s traffic.
“Why is there traffic?”
Well, because there are a lot of people on the road right now.
“Why?”
Well, because a lot of people are heading downtown around the same time to be at work on time.
“Why?”
Well, most employers want people to start work at the same time every day and to be on time.
“Why?”
Because people need to work to buy houses and food and toys for their children (like you!)
Five “why’s” later, and we have a LOT more information than we did after the first why. You can see how this logic can translate to an incident investigation. We need to dig deep when we ask why something happened, instead of just scratching the surface.
If it’s a multifaceted problem with many intricacies and unknowns, the Fishbone method may be the best. This method allows you to brainstorm possible causes under several categories. Often, we use Methods, Machines (equipment), People (manpower), Materials, Measurement and Environment.
Once all the possible causes are listed, we then systematically prove or disprove each potential cause.
Going back to our traffic example but using the Fishbone method, we could identify many causes for traffic:
Machines:
After brainstorming these possible causes for traffic, we then review each one and prove or disprove it. For example, I might tune into the radio to determine whether an accident occurred, or have my passenger check online to see if a road is closed. If we can disprove enough of the potential scenarios, we will be able to single out the more likely cause(s) for the traffic.
Now, back to which is the best tool to use. If the problem is a sequential event, and the investigation team is experienced and can keep subjectivity at bay, the ‘Five Why’s’ could work best. For an incident involving complex human failures, TapRooT™ is my method of choice. If it’s a multifaceted problem with many unknowns and the investigation team may fall into ruts, the Fishbone method may be the best. All three methods share two essential similarities: an experienced, objective facilitator, and a detailed sequence of events charts.
What methods do you prefer to use for root cause analysis? Why? Comment below!
Next, I will be writing about what the Aviation industry can learn from Oil & Gas when it comes to safety, and vice versa – stay tuned!
Recently, executives from a major oil company in Alberta released the findings of their investigation into a fire and explosion that killed two workers. The conclusion: ‘Human Error’. Really? The company alleges that they could not have done anything differently… What about providing more training before the workers were assigned to work in an area they didn’t normally work in? Or holding supervisors and workers more accountable for the work permitting process? Or assessing how recent layoffs would affect maintenance worker actions?
We cannot be getting to the root cause if the conclusion of an incident investigation is that ‘human error’ is the cause.
So, are we not using the right root cause analysis methods for our investigations?
I believe that there’s no ‘one size fits all’ method when it comes to root cause analysis. I looked at three popular root cause analysis methods, ‘Five Whys’, ‘Fishbone’ and ‘TapRooT™’, and offer some thoughts on what type of incident or problem they work best for.
There is one component that I believe all three methods share: a Timeline or Sequence of Events chart. Regardless of the degree of severity of an incident or problem, there’s something powerful about taking the time to systematically list the sequence of events onto paper. Once this timeline is created, it often becomes very apparent where the mistakes or failures lie. TapRooT™ calls these ‘Causal Factors’, while the Fishbone method uses these as spines that can’t be disproved as a possible cause. The Five Whys method uses these as factual evidence to answer the recurrent question of ‘why?’.
TapRooT™ is a 7-Step Investigative process that is very structured and provides objective guidelines to the investigation team. I use this method when I suspect that there might be a lot of emotion involved in the investigation; the TapRooT™ tree allows the facilitator to keep the investigation team objective. It is a very thorough and comprehensive process. I like to use this method when I suspect clients have already decided what the cause is – sometimes they are correct, but often, other overlooked causes are identified. However, TapRooT™ takes a fair bit of time to apply and requires a licensed facilitator. I find that TapRooT™ is not ideal for equipment failure events, or events where there is a rather simple sequence of events.
If the incident involves sequential events, and the investigation team is experienced and can keep subjectivity at bay, the ‘Five Why’s’ method could work best.. When you’re presented with a problem, the ‘Five Whys’ method repeatedly asks the question, “Why?”. Five is an arbitrary number, but a suitable rule of thumb to adequately get closer to the root cause of your problem. Each time you ask “Why”, you will inevitably be led to another question that will get you closer to your root cause.
Confused? Think about a young child who persistently asks “Why”. You are stuck in traffic, and this child asks, “Mommy, why are we stopped?”
Well, because there’s traffic.
“Why is there traffic?”
Well, because there are a lot of people on the road right now.
“Why?”
Well, because a lot of people are heading downtown around the same time to be at work on time.
“Why?”
Well, most employers want people to start work at the same time every day and to be on time.
“Why?”
Because people need to work to buy houses and food and toys for their children (like you!)
Five “why’s” later, and we have a LOT more information than we did after the first why. You can see how this logic can translate to an incident investigation. We need to dig deep when we ask why something happened, instead of just scratching the surface.
If it’s a multifaceted problem with many intricacies and unknowns, the Fishbone method may be the best. This method allows you to brainstorm possible causes under several categories. Often, we use Methods, Machines (equipment), People (manpower), Materials, Measurement and Environment.
Once all the possible causes are listed, we then systematically prove or disprove each potential cause.
Going back to our traffic example but using the Fishbone method, we could identify many causes for traffic:
Machines:
- It is the daily rush-hour and the road is not designed for the volume
- A road is closed for repair
- There is a concert / parade / event occurring causing congestion
- There was an accident on the road
After brainstorming these possible causes for traffic, we then review each one and prove or disprove it. For example, I might tune into the radio to determine whether an accident occurred, or have my passenger check online to see if a road is closed. If we can disprove enough of the potential scenarios, we will be able to single out the more likely cause(s) for the traffic.
Now, back to which is the best tool to use. If the problem is a sequential event, and the investigation team is experienced and can keep subjectivity at bay, the ‘Five Why’s’ could work best. For an incident involving complex human failures, TapRooT™ is my method of choice. If it’s a multifaceted problem with many unknowns and the investigation team may fall into ruts, the Fishbone method may be the best. All three methods share two essential similarities: an experienced, objective facilitator, and a detailed sequence of events charts.
What methods do you prefer to use for root cause analysis? Why? Comment below!
Next, I will be writing about what the Aviation industry can learn from Oil & Gas when it comes to safety, and vice versa – stay tuned!