Category: Root Cause Analysis Tips
From Book1: TapRooT® Root Cause Analysis Leadership Lessons, Copyright 2017. Used by permission.
The diagram below was given to me by a VP at a utility. He thought it was funny. In reality, it was what the workers at that utility thought of the system they lived under.
They were trapped in the Blame Vision.
The Blame Vision seems to be imbedded in human nature. Perhaps it started with the legal system’s adversarial insistence on finding the guilty party. However, when this vision is used on innocent participants trying to get a job done, it often just blames those that are handy or unlucky.
The best thing about the Blame Vision is that identifying the person to blame is fairly easy. Just figure out who touched the item last. Unfortunately when a site is caught up in the Blame Vision, there are many “mystery” incidents (when hidden problems are finally discovered). When asked what happened, employees know to act like Bart Simpson. They emphatically deny any knowledge of the problem with the following standard answer:
I didn’t do it!
Nobody saw me do it!
You can’t prove I did it!
But management with the Blame Vision won’t let this get in their way. If you can’t find the guilty party, an acceptable solution is to arbitrarily punish a random victim. Or you can punish everyone! (That way you are sure to get the guilty party.) We had a saying for this in the Navy:
Why be fair when you can be arbitrary?
A refinery manager told a story that illustrated the effect of the Blame Vision. Early in his career he had been an engineer and was on a team that designed and started up a new process that had eventually gone on to make the company a lot of money. It had been a hard working, close-knit team. Someone decided to organize a twenty-year reunion of all the designers, engineers, supervisors, operators, and mechanics who had worked on the project. At the reunion everyone told stories of their part in the process start-up.
One electrician told an especially interesting story. It seems that during the first plant start-up, electricity to a vital part of the process was briefly lost. This caused a process upset that damaged equipment and cost big bucks. Valuable time was spent trying to track down the cause of the mysterious power failure. Every possible theory was tracked down. Nothing seemed to explain it. The only explanation was that the breaker had opened and then closed itself.
The retired electrician told the rest of the story to all those present at the reunion. It seems that on that day he had been working on a problem on another part of the process. To troubleshoot the problem he needed to open a breaker and de-energize the system. He went to the breaker box that he thought powered the system he was troubleshooting and opened what he thought was the appropriate breaker (the breakers weren’t labeled, but he thought he knew which one to open because he had wired most of the panel). That’s when everything went wrong. He could hear alarms from the control room. He thought that something he had done had caused the problem, so he quickly shut the breaker and left the area to cover up his involvement.
Later, when he was asked if he knew what could cause that breaker to open and shut on its own, he thought about telling the supervisor what had happened. But he knew that if he did, he’d probably be fired. So he said he didn’t know what would cause a breaker to open and shut on its own (technically not a lie). But, since the incident was now long past and he was retired, he thought that the statute of limitations had run out. He admitted his mistake because it was too late to punish him.
If you are trapped at a company or site with the Blame Vision? Don’t give up hope. There are ways to change management’s vision and adopt the Opportunity to Improve Vision. Read more about it in Book 1: TapRooT® Root Cause Analysis Leadership Lessons.
It seems that I’m continually confronted by folks that think 5-Whys is an acceptable root cause analysis tool.
The reason they bring up the subject to me is that I have frequently published articles pointing out the drawbacks of 5-Whys. Here are some examples…
That got me thinking … Have I EVER seen a good example of a 5-Why root cause analysis that I thought was a good example of a root cause analysis? And the answer was “NO.”
So here is my question …
What do you do when you see someone presenting a bad root cause analysis where they are missing the point?
Leave a comment below and let me know the tack that you take … What do you think?
Repeating the same corrective actions over and over again defeats the purpose of a quality root cause analysis investigation. If you spend the time investigating and digging deeper to find the REAL root cause, you should write the most effective corrective actions you can to ensure it was all worth the resources put into it. Instructor & Equifactor® and TapRooT® Expert, Ken Reed, talks about corrective actions and how to make them new and effective for each root cause.
What is your company’s vision? Does your company have a:
- Blame Vision
- Crisis Management Vision
- Opportunity to Improve Vision
The only vision that leads to good root cause analysis is the opportunity to improve vision.
We’ve been helping people “adjust” their vision since Mark Paradies gave a talk about the opportunity to improve vision at the 1990 Winter American Nuclear Society Meeting.
How do you change your vision?
That takes more than the few paragraphs of a blog article to describe. But we did write about it in our newest book:
What’s in the new book?
- A Tale of Two Plants
- What is a Root Cause and How Was TapRooT® Developed to Help You Find Them?
- How Leaders Can Apply TapRooT® to Improve Performance
- What Can TapRooT® Do for You?
- What TapRooT® Books Do You Need to Read?
The new book is designed for senior managers and leaders of improvement programs to help them understand effective root cause analysis and how it fits into a performance improvement program.
Order your copy of the new book by clicking HERE and make sure your vision supports improved performance!
TapRooT® Instructor and Non-Verbal Communication Expert, Barb Phillips, explains how to interpret common body language cues with an example investigative interview. Watch here for some investigative interviewing tips!
Want to know more? Take a TapRooT® Effective Interviewing and Evidence Collection course.
I heard one industry guru say that EVERY loss deserves an investigation and corrective action.
Is it possible?
Is it desirable?
I would say no.
Not every loss needs an investigation and certainly not every loss deserves a root cause analysis.
Because every investigation should have at least a chance of a positive return on the investigation investment. Many losses are too small to get much benefit from an investigation. (This is true even if you take into account the potential for even bigger problems down the road.) Let’s face it, sometimes there just isn’t much to learn from a paper cut!
Why should we avoid wasting our improvement energy on unimportant minor problems?
Because every organization has resource limitations and we should spend our resources wisely. We need to put our effort where it will do the most good.
Therefore, we must target our resources where they will get the most improvement bang for the buck.
The targeting of improvement resources should match management’s goals. This targeting of resources should guide the improvement effort by assigning resources for safety, quality, reliability, productivity, and product improvement. Of course, the division of resources is guided by the company’s risk assessment and market analysis.
Let’s look at an interesting hypothetical example.
At a large chemical company, a budget and level of emphasis has been assigned for safety improvement. How should the company spend this budget? Where should the safety team direct their resources?
The first place to look would be the company’s real accident data. Of course, if the company has poor root cause analysis, the data will not be meaningful. If that is true, the first place to apply resources is to achieving outstanding root cause analysis of significant accidents.
What if this company has been applying advanced root cause analysis for several years and has fairly good accident data. Then they can use that data to determine where their biggest risks are and what type of root causes contribute the most to that risk. That knowledge can help them target their resources.
If a company’s safety improvement programs are fairly ineffective (measured by the fatality count), the majority of the emphasis should be put on the investigation of significant incidents and precursors to significant incidents. These are incidents that cause fatalities and serious injuries and incidents that could have caused a fatality or serious injury if one more Safeguard had failed.
The remaining improvement effort (say 33%) would be applied to proactive improvement. This includes local safety audits, peer observations, management field observations, and outside audits.
As the company improves, their safety performance and the time between significant incidents will improve significantly (do you trend this?). As this happens, effort is shifted from reactive investigations (because there are less of them) to targeted proactive improvement. This tends to cause an excelleration in the improvement progress.
What happens if you don’t have good root cause analysis of significant incidents?
If a company does NOT do a good job investigating and fixing their serious incidents, the proactive improvement efforts tend to be miss-directed. The lessons learned from significant injuries and potential significant injuries are inaccurate. The data produced misdirects the proactive improvement efforts. The significant injuries continue even though the minor incidents targeted by the misdirected proactive improvement efforts tend to improve.
This misdirection of proactive improvement efforts has been written about extensively. Proactive behavior based safety improvement efforts produced good trends in lost time injury data with little improvement in fatality and significant injury data. This should not be a surprise. It is the reason that many companies hit a plateau of improvement for major accidents while having world-class lost time injury rates.
I believe an excellent example of this misdirection of improvement efforts could be seen in the BP Texas City Refinery explosion. Management thought their improvement efforts were working because of a decrease in the LTI rate but the fatality rate (that included contractors) was unchanged (or maybe slightly worse).
Where are you????
Are you trending the time between serious injuries and fatalities?
Is that time increasing significantly?
Do you know how to tell if the time between incidents is increasing significantly?
We can help you learn how to mathematically prove that improvement is occurring (or that things have taken a turn for the worse).
Are your less significant incidents improving without making much impact on your significant injury rate? This is a sign of a misdirected improvement effort and a need to improve your root cause analysis of significant injuries.
We can review your program, point out potential improvements, and teach your folks how to apply the best root cause analysis techniques reactively and proactively to make improvement happen.
We can also help your management understand their impact on improvement. How they directly influence the quality of the root cause analysis. (You can’t have excellent root cause analysis without management understanding and involvement.) Even the best root cause analysis systems can’t succeed unless management asks for the appropriate investigations and provides the resources needed to implement effective performance improvement fixes.
Once all of this is on track, we can help you see how to effectively apply your resources to get the most bang for your improvement buck. This includes targeting of improvement efforts and deciding when a root cause analysis is needed and when the effort should be applied elsewhere.
Call Per Ohstrom or Mark Paradies at 865-539-2139 (or CLICK HERE to contact us) to discuss your improvement efforts and see how we could help focus your program to get the best return on your improvement investment.
I think that TapRooT® Root Cause Analysis might be one of best way to investigate near misses, right?
I received this question from one my students who has continued to stay engaged to keep his company running safe and efficient by applying his TapRooT® Root Cause Analysis Training every day.
As you know, we are able to prevent real incidents by investigating near misses.
I think that TapRooT® RCA might be one of best ways to investigate near misses, right? Would you advise me how to use TapRooT RCA to investigate near misses and give me some examples of near miss investigations done with TapRooT® RCA?
Any comments or advice would be highly appreciated.
Think about it, in most near misses, you are just One Causal Factor from your next major Incident. The Causal Factors found during the investigation are usually not a surprise or the first time that they have occurred at that site or in the company.
The only difference between an incident and a near miss incident root cause analysis is what goes in the circle on the SnapCharT® (sequence of events chart). For example,
Vital to ensure success with a new near miss program implementation, is not to try to investigate all audit findings or catches. You do not have enough resources. Instead start with the high potentials for incidents only.
Wait, why did I just include audit findings? Simple, audits are more than looks for compliance. Processes are put in place to reduce or eliminate hazards (energy), isolate targets from hazards or to ensure responses to hazard and target contact do not make the incident worse. An audit is often the first documented point in time to identify a high potential near miss. Check out our new audit course with root cause analysis to improve your audit capability.
Just like I stated above concerning near misses, all audit findings may not need a root cause analysis, but audit findings with high potentials do.
If your company does not have a High Potential for Injury/Incident/Process Shutdown Program in place today, you will need to do some homework. Here are some simple steps to get started.
- Identify Tasks performed by your employees, contractors, vendors or suppliers, that if done incorrectly could cause Injury/Incident/Process Shutdown. For a jump start, review the following videos for Serious Injuries & Fatalities. For quality defects and process failures take a look at hierarchy of controls for defects.
- Once the potential tasks are identified, develop a triggering process that alerts the need for a root cause analysis.
Second homework item, if not trained in TapRooT® Root Cause Analysis, go to course close to you now.
If in Europe, check out our 5-Day TapRooT® Root Cause Analysis Course in Aberdeen, Scotland – May 22.
If in North America, checkout our 2-Day TapRooT® for Audits Charlotte, NC May 4, 2017 or our 5-Day TapRooT® Galveston, TX May 15, 2017.
Our complete course schedule can be found here.
Have you ever performed an audit and got frustrated when you found the same issues as the last audit? I feel your pain….we all have. Why does this happen so much? Because most companies audit programs look a little like this:
Q: What is missing from this picture?
A: Root Cause Analysis, of course!!
Many companies actually have good programs for FINDING problems without having a good program for FIXING problems. If you want problems fixed, root cause analysis has to be part of it. So on the road to improvement, take a DETOUR to Root Cause Land!
For your program to be effective, it should look more like this:
The best way to do root cause analysis on audits? TapRooT®.
We have a new course, TapRooT® for Audits, that we will be holding in Charlotte, NC on May 4-5. Why not join us? For more information and to register, click HERE
What is the minimum investigation for a simple incident?
Before you can answer this question, you need to decide the outcome you are looking for. For example:
- Do you just want to document the facts?
- Would you be happy with a simple corrective action that may (or may not) be effective?
- Do you need effective corrective actions to prevent repeats of this specific incident?
- Do you want to prevent similar types of incidents?
The answers to these questions depend on two factors that determine risk:
- What were the consequences of this incident and could things have happened slightly differently and had much worse consequences?
- What is the likelihood that this type of incident will happen again?
Of course, before you start an investigation, answering these two questions may be difficult. Before you start an investigation, you don’t really know what happened! But in spite of this lack of knowledge, someone must decide if an incident is worth investigating and the resources to dedicate to the investigation.
I’ve seen simple incidents that, when investigated, revealed complex problems that could have caused a serious accident. Therefore, if a thorough investigation is not performed, the investigator may never know what they could have discovered. That’s why I caution management that something that seems simple may not be simple.
However, some incidents ARE simple. I’ve seen many incidents that people were investigating that were similar to this one:
An employee stumbles, falls, and sprains
his wrist while walking down a flat sidewalk.
He had on simple shoes with adequate tread.
He was not particularly preoccupied
nor was he entirely paying attention to each step
(just normal walking).
How much can be learned by investigating this incident? Probably not much. I would suggest that even though the person sprained his wrist, this incident should not be investigated beyond a simple recording of the facts so that the incident could be recorded for safety records (OSHA logs in the USA) and included in future incident trending.
You might ask:
“But what if the employee had stumbled and fell in front of an oncoming car and the employee killed?”
In that case, because of the consequences, a detailed major investigation would be required.
In either case, the TapRooT® Root Cause Analysis System could be used to complete the investigation.
The TapRooT® Root Cause Analysis System is a robust, flexible system for analyzing and fixing problems. The complete system can be used to analyze and fix complex accidents, quality problems, hospital sentinel events, and other issues that require a complete understanding of what happened and effective corrective actions.
Learn more about when to investigate a simple incident by attending our 2-Day TapRooT® Root Cause Analysis training. Click here to view the upcoming schedule.
It’s nearly impossible to conduct a useful root cause analysis unless you actually have some data to analyze. Many systems seem to think that you can dive right into an analysis before you have a full understanding of what actually happened. During the development of the TapRooT® System, one of the first items of business was to develop an easy way to visualize the problem and document the gathered facts. Thus, SnapCharT® was born.
SnapCharT®s are pretty easy to build. With just three shapes to worry about, and a few simple rules, the SnapCharT® gets you moving in the right direction right from the get-go.
Here are a few tips to help make the SnapCharT® even easier and more useful.
1. Avoid the word “and” in your Events. Events are meant to show a single action that occurred in the course of the incident investigation. Some people have an aversion to having a bunch of Events, and therefore put several actions in each one. For example, if I wanted to document that the driver stopped at the stop sign, looked both ways, and then pulled out into the intersection, I would not want to write this as a single Event. This should be 3 separate (short) Events, one after the other.
The reason this is important is because we want to see if any mistakes are made during each step in the sequence of events. If we put several actions into a single Event, we find it is easy to miss one of these mistakes. On the other hand, with 3 separate Events, I can ask, “Did the driver make a mistake while stopping? Did she make a mistake while looking both ways? Did she make a mistake by pulling forward?” Having separate Events makes it much easier to catch individual problems.
Keep in mind that, later in the investigation, you may find that there were no mistakes made in any of these Events. When you complete your SnapCharT®, it might then make sense to combine some Events to make the final SnapCharT® easier to read. It is OK to combine Events later on; just leave them separate during your initial data-gathering phase.
2. Leave lots of space. Many people tend to cram all their Events close together, I suppose to conserve real estate. Don’t worry about it; leave lots of room between your individual Events. Spread everything out. You’ll be adding Conditions underneath each of these Events, and you’ll almost certainly end up moving everything to make room for these Conditions anyway. Give yourself plenty of room to work at the beginning. If using the software, I usually only put 2 or 3 Events on each page to start out. Later on, once you have all of your Conditions documented and grouped, you can compress everything down a bit and get rid of extra spaces. But even then, don’t try to squeeze everything tightly together. It can make it hard to read, even after everything is set. And you might also find new Conditions that need to be added once you start the root cause analysis.
3. Draw your lines at the very end. It is tempting to start drawing lines early in the process. You want to see those arrows showing your progression from one Event to the next. And you want to arrange your Conditions into neat groups right from the start. Unfortunately, this can cause problems later on. There is a good chance you’ll be adding new Events, changing the order of the Events you have, or regrouping your Conditions into Causal Factor groups. If you have already drawn your lines, you’ll just have to delete them, make your changes, and then draw them back in. And then probably do it again later on.
I normally don’t draw any lines between Events or Conditions until after I’ve identified my Causal Factor groups. My SnapCharT® is probably pretty close to being complete by that point, so I’m reasonably confident that I won’t be making a lot of changes. This can be a tough lesson for those that are REALLY detail oriented (you know who you are!), and just have to have those lines drawn in early in the process. Resist the temptation; it’ll save you some time (and frustration!) later on.
Let me know what you think about these tips. If you have other tips that you’ve found that make it easier and quicker to produce your SnapCharT®s, share the best practices you’ve learned in the comments below.
We hope that you will also consider coming to the 2016 Global TapRooT® Summit, San Antonio, Texas, August 1-5 to share best practices. Click here to learn more about the Summit.
“Don’t collect evidence by accident!”
A phrase that I repeat often while teaching our TapRooT® Root Cause Analysis Method, along with…
Go Out And Look (GOAL)
I know, the phrases above may look like another safety/quality slogan of the day but are they? Maybe they should be the simplest guidance to increase the probability of not losing relative facts after an industrial injury, facility/property damage, environmental release, product defect, customer complaint or near miss/hit to any of the above.
Here is a list of issues that occur by not following the concise instructions above:
- Lost/Missing evidence
- Evidence spoliation (whether intended or not)
- Guessing driven by assumptions tied to past problems
- Regulatory Write Up for delayed incident reporting (extent and magnitude of problem not understand in time by not Going Out And Looking)
Why would any established industry, often overseen by a regulatory agency, have to worry about collecting evidence by accident or GOAL? Don’t many companies have procedures and work instructions on how to manage an industrial accident or regulatory write up? The latter question is where the problem resides. Actually, it starts before a major incident occurs.
Companies are good in many cases at handling major accidents and their evidence collection. What often drives what gets looked at is the company’s Incident Matrix. The matrix in many cases stops employees from Going Out And Looking and encourages last minute evidence collection by accident. Below is a typical matrix.
If the employee has “7 days?” or “as soon as practical”, what does that do to evidence collection delays or GOAL? What does that do to how the employee collects evidence and how the root cause analysis is performed? If the “big problems” have an investigation protocol, do the employees use the same protocol for the unsafe practice issues?
The process you create to manage investigation resources can hurt if not managed correctly.
For more thoughts on collecting evidence and the impact to the business based on your company’s own protocols, read the following….
How many companies are using TapRooT® for their “hard,” “high-risk” incident analyses and using something like 5-Whys for the “simple” stuff? Yep, I thought so. A lot of companies are doing this for various reasons. I’ll get into that more in a minute.
Now, another poll:
How many of you are performing effective root cause analyses on your “important,” “high-consequence” investigations, and performing nearly useless analyses on the “easy” stuff? Of course, you know this is really exactly the same question, but you’re not as comfortable raising your hand the second time, are you?
Those of you that follow this blog have already read why using inferior RCA methods don’t work well, but let me recap. I’m going to talk about 5-Whys specifically, but you can probably insert any of your other, less-robust analysis techniques here:
- It does not use an expert system. It relies on the investigator to know what questions to ask.
- Because of this, it allows for investigator bias. If you are a training person, you will (amazingly enough) end up with “training” root causes.
- The process does not rely on human performance expertise. Again, it relies on the skill of the investigator. Yes, I know, we’re all EXCELLENT investigators!
- It does not produce consistent results. If I give the same investigation to 3 different teams, I always get 3 different sets of answers.
- There is no assistance in developing effective corrective action. When 80% of your corrective actions fall into the “Training” “Procedures” and “Discipline” categories, you are not really expecting any new results, are you?
So, knowing this to be true, why are we doing this? Why are we allowing ourselves to knowingly get poor results?
- These are low risk problems, anyway. It doesn’t matter if we get good answers (Why bother, then?)
- It’s quick. (Of course, quickly getting poor results just doesn’t seem to be an effective use of your time.)
- It’s easy (to get poor results).
- TapRooT® takes too long. Finally, an answer that, while not true, at least makes sense.
So what you’re really telling me is that if TapRooT® were just easier to use, you would be able to ditch those other less robust methods, and use TapRooT® for the “easy” stuff, too.
Guess what? We’ve now made TapRooT® even easier to use! The 7-step TapRooT® process can now be shortened for those “easy” investigations, and still get the excellent results you’re used to getting.
We now teach the normal 7-Step method for major incidents, where you need the optional data-collection tools. However, we are now showing you how to use TapRooT® in low to medium-risk investigations. You are still using the tools that make TapRooT® a great root cause analysis tool. However, we show you how to shorten the time it takes to perform these less-complex analyses.
The 2-Day TapRooT® Incident Investigation Course concentrates on these low to medium-risk investigations. The 5-Day TapRooT® Advanced Team Leader Course teaches both the simple method, but also teaches the full suite of TapRooT® tools.
Don’t settle for poor investigations, knowing the results are not what you need. Take a look at the new TapRooT® courses and see how to use the system for all of your investigations. You can register for one of these courses here.
Our 2016 Global TapRooT® Summit was a great success last year! Our attendees helped one another by sharing some of their best practices. Here Tim Dearman informs the audience how his company keeps subject matter experts in each of their key business units to help during investigations.
(Click post title if the video is not displaying.)
Is it more important to identify where a defect occurred or when the defect become apparent?
Several children in 2016 were left disappointed after their Christmas Gift, Hatchimals, did not hatch.
In a statement to Global News, Spin Master said they have added extra resources to help customers in the wake of a spike in calls.
“While the vast majority of children have had a magical experience with Hatchimals, we have also heard from consumers who have encountered challenges. We are 100% committed to bringing the magic of Hatchimals to all of our consumers,” said a company spokesperson.
“We are committed to doing everything possible to resolve any consumer issues. We sincerely apologize and thank everyone who is experiencing an issue for their patience.”
Which stakeholder was impacted the most in the defective product issue above?
- The child?
- The gift purchaser?
- The distributor, like Amazon?
- The product manufacturer, Spin Master?
While this was just a toy that went bad, think about the same questions for any other product and ask the same question again, “Is it more important to identify where a defect occurred or when the defect become apparent?”
- Cracked syringe for onsulin injection
- Diary product that is expired
- Top-drive gears use on an oil-rig
Benefits of finding and analyzing a defect early in production:
- Company reputation
- Safety to customer
- Less delay between defect occurrence and relative evidence
- The ability to stop the production process immediately
Cons to having the customer report the defect:
- Magnitude of impact to safety and customer business can be greater
- Product fixes are closer to triage and damage control repairs as opposed to identification of root causes
- Degraded company reputation
- Harder to collect how the customer used the product in the field
- Takes more company resources to investigate the problem
- You have to earn the clients’ trust back no matter how well you remedy the problem
Timeliness of defect identification as well as finding the real root causes of the problem is vital for a business’s success and longevity. Recovering from a defect that escaped to the customer no matter what the fix is, becomes a loss of trust. So what are the recommendations to be proactive:
- Identify defect opportunities critical to customer success.
- Mistake-Proof for the critical opportunities when possible.
- Develop visible triggers and indicators at time of occurrence for defects that cannot be prevented 100 percent.
- Track and Trend types of defects, defect occurrence locations, gap between time of occurrence, time of identification and time to complete the corrective action.
- Track repeat occurrences and analyze for the failure of the previous corrective action…. Often related to poor root cause analysis and/or poor corrective action.
For continued discussion on the defect identification and correction, I look forward to your comments. Or even better, I look forward to seeing you in one of our TapRooT® Root Analysis Courses.
Our 2016 Global TapRooT® Summit was a great success last year! Our attendees helped one another by sharing some of their best practices. Here Charlotte Grainger discusses how her company has instituted a program requiring investigators to be recertified every three years.
(Click post title if the video is not displaying.)
I’ve heard many high level managers complain that they see the same problems happen over and over again. They just can’t get people to find and fix the problems’ root causes. Why does this happen and what can management do to overcome these issues? Read on to find out.
Blame is the number one reason for bad root cause analysis.
Because people who are worried about blame don’t fully cooperate with an investigation. They don’t admit their involvement. They hold back critical information. Often this leads to mystery accidents. No one knows who was involved, what happened, or why it happened.
As Bart Simpson says:
“I didn’t do it.”
“Nobody saw me do it.”
“You can’t prove anything.”
Blame is so common that people take it for granted.
Somebody makes a mistake and what do we do? Discipline them.
If they are a contractor, we fire them. No questions asked.
And if the mistake was made by senior management? Sorry … that’s not how blame works. Blame always flows downhill. At a certain senior level management becomes blessed. Only truly horrific accidents like the Deepwater Horizon or Bhopal get senior managers fired or jailed. Then again, maybe those accidents aren’t bad enough for discipline for senior management.
Think about the biggest economic collapse in recent history – the housing collapse of 2008. What senior banker went to jail?
But be an operator and make a simple mistake like pushing the wrong button or a mechanic who doesn’t lock out a breaker while working on equipment? You may be fired or have the feds come after you to put you in jail.
Talk to Kurt Mix. He was a BP engineer who deleted a few text messages from his personal cell phone AFTER he had turned it over to the feds. He was the only person off the Deepwater Horizon who faced criminal charges. Or ask the two BP company men who represented BP on the Deepwater Horizon and faced years of criminal prosecution.
How do you stop blame and get people to cooperate with investigations? Here are two best practices.
A. Start Small …
If you are investigating near-misses that could have become major accidents and you don’t discipline people who spill the beans, people will learn to cooperate. This is especially true if you reward people for participating and develop effective fixes that make the work easier and their jobs less hazardous.
Small accidents just don’t have the same cloud of blame hanging over them so if you start small, you have a better chance of getting people to cooperate even if a blame culture has already been established.
B. Use a SnapCharT® to facilitate your investigation and report to management.
We’ve learned that using a SnapCharT® to facilitate an investigation and to show the results to management reduces the tendency to look for blame. The SnapCharT® focuses on what happened and “who did it” becomes less important.
Often, the SnapCharT® shows that there were several things that could have prevented the accident and that no one person was strictly to blame.
What is a SnapCharT®? Attend any TapRooT® Training and you will learn how to use them. See:
2. FIRST ASK WHAT NOT WHY
Ever see someone use 5-Whys to find root causes? They start with what they think is the problem and then ask “Why?” five times. Unfortunately this easy methods often leads investigators astray.
Because they should have started by asking what before they asked why.
Many investigators start asking why before they understand what happened. This causes them to jump to conclusions. They don’t gather critical evidence that may lead them to the real root causes of the problem. And they tend to focus on a single Causal Factor and miss several others that also contributed to the problem.
How do you get people to ask what instead of why?
Once again, the SnapCharT® is the best tool to get investigators focused on what happened, find the incidents details, identify all the Causal Factors and the information about each Causal Factor that the investigator needs to identify each problem’s root causes.
3. YOU MUST GO BEYOND YOUR CURRENT KNOWLEDGE
Many investigators start their investigation with a pretty good idea of the root causes they are looking for. They already know the answers. All they have to do is find the evidence that supports their hypothesis.
What happens when an investigator starts an investigation by jumping to conclusions?
They ignore evidence that is counter to their hypothesis. This problem is called a:
It has been proven in many scientific studies.
But there is an even bigger problem for investigators who think they know the answer. They often don’t have the training in human factors and equipment reliability to recognize the real root causes of each of the Causal Factors. Therefore, they only look for the root causes they know about and don’t get beyond their current knowledge.
What can you do to help investigators look beyond their current knowledge and avoid confirmation bias?
Have them use the SnapCharT® and the TapRooT® Root Cause Tree® Diagram when finding root causes. You will be amazed at the root causes your investigators discover that they previously would have overlooked.
How can your investigators learn to use the Root Cause Tree® Diagram? Once again, send them to TapRooT® Training.
The TapRooT® Root Cause Analysis System can help your investigators overcome the top 3 reasons for bad root cause analysis. And that’s not all. There are many other advantages for management and investigators (and employees) when people use TapRooT® to solve problems.
If you haven’t tried TapRooT® to solve problems, you don’t know what you are missing.
If your organization faces:
- Quality Issues
- Safety Incidents
- Repeat Equipment Failures
- Sentinel Events
- Environmental Incidents
- Cost Overruns
- Missed Schedules
- Plant Downtime
You need to be apply the best root cause analysis system: TapRooT®.
Learn more at:
And find the dates and locations for our public TapRooT® Training at:
While we probably would not see a frequency chart in real life like the one above, we all have seen or perceived the above rejection reasons after sending in our root cause analysis report to senior management or a regulator. Below are a few reasons that have caused a report or corrective action in a report to be rejected.
1. Rejection Example 1 (FDA):
We have reviewed your firm’s response of February 3, 2010, and note that it lacks sufficient corrective actions.
Specific violations observed during the inspection include, but are not limited, to the following:
1. Your firm has failed to reject drug products that did not meet established standards or specifications [21 C.F.R § 211.165(f)].
In your response, you state that this product is no longer manufactured and that such practices do not represent your company’s current CGMP compliance standards. You have committed to have all current and future investigations reviewed and signed by the Vice President of Quality Operations. However, you did not review your records to ensure that other products that failed to meet AQLs were not distributed. In addition, your response does not include training of the QCU to ensure that they are capable of identifying and ensuring appropriate corrections of these types of discrepancies in the future.
Problem Assessed: Company did not look for extent of condition (generic/systemic issues) or a complete corrective action with follow through.
2. Rejection Example 2 (NRC)
Company failed to correct CAPA 15-171, closed November 30, 2015, for finding 60010. CAPA 15-171 corrective actions required a revision to work instructions to include a pressure setting for contact blocks 60010. After discussions regarding the pressure setting with Company quality inspectors, the NRC inspection team identified that Company had not updated the work instructions.
Problem Assessed: Original finding did not get addressed nor were there any root causes identified for the original issue.
Just like students in a classroom, each report writer learns what the senior executive or regulator expects when writing an investigation report, often through trial and error. Often in some industries it seems that more time is spent writing an investigation report than is spent on the actual investigation.
How can you reduce the number of rejections that you might face while still ensuring a concise root cause analysis with effective corrective actions. Follow the steps below.
1. Do not let the written report criteria drive the root cause analysis itself.
• Perform the root cause analysis using an unbiased process like we do in a TapRooT® investigation.
• Collect the type of information that is required for the written report however do not limit what is collected.
2. Define the criteria for each section of the written report and hold that criteria true when writing a report.
• There should be little overlap in terms such as Causal Factor, Root Cause and Incident. In other words, no gray areas for interpretations.
• When within your control, reduce redundancy in your written report.
3. The written report should be concise and include enough information to be a standalone document as needed for the audience reading it. There should be no doubt when reading a report as to:
• What was the incident
• What led up to the incident
• What was the response to the incident
• What were the causal factors for the incident
• What were the root cause for the incident
• How each root cause will be addressed, whether eliminated or mitigated.
While there will be additional criteria required by the report requester for the writer to meet, the truer one stays to the purpose of an investigation and its documentation, the higher the chance of reducing said incident in the future.
Want to learn how to create a paperless report? Check out our series here.
Our 2016 Global TapRooT® Summit was a great success last year! Our attendees helped one another by sharing some of their best practices. Listen as Robert Oliver talks about how his company uses weekly review boards to examine incidents.
(Click post title if the video is not displaying.)
Our 2016 Global TapRooT® Summit was a great success last year! Our attendees helped one another by sharing some of their best practices. Here Emad Gomaa talks about improving communication between the company and the customers.
(Click post title if the video is not displaying.)
Happy Wednesday and welcome to this week’s root cause analysis tips.
Many companies are ISO certified and some of those that are not have some type of management system. There are too many different systems and standards out there to discuss individually, but one of the common themes is continuous improvement.
Whether you use a commonly known management system or developed your own, one of your goals should be to improve your system/business. When I think of a management system, I think of it as a framework for how you manage your business. Whether required or not, incorporating continuous improvement is a smart thing to do.
While ISO has hundreds of standards, some of the most commonly known are 9000 (Quality) and 14000 (Environmental); coming down the pike soon is 45001 (Safety). There are also numerous industry specific standards. Many of the ISO standards use a common framework that includes the PDCA (plan, do, check, act) cycle. This is where TapRooT® can help.
PDCA is a simple process that has been in use widely since the 1950’s. I do not know many processes that have endured that long. So why? Because it is easy and it works.
As part of PDCA, you have to determine what to fix, how to fix it, and whether it works. Sounds a little like root cause analysis and corrective action, doesn’t it? So if you were going to use PDCA to help solve your problems, what would you use for root cause analysis? If I were you, I would use TapRooT®. Need help with corrective actions? Use the Corrective Action Helper®, SMARTER Matrix, and Safeguards hierarchy. You can incorporate TapRooT® tools into any improvement framework you use.
Also, don’t forget the importance of auditing. This should be part of your management system as well. We’ve taught auditing with TapRooT® for years, but we recently developed a new course specifically for Auditors, TapRooT® for Audits, and wrote a new book, TapRooT® Root Cause Analysis for Audits and Proactive Performance Improvement. The primary topic of the book is auditing, but we also have a short section on PDCA. We’ll be teaching this course in Charlotte, NC in May if you would like to join us. Or, if you are already TapRooT® trained, you can get the book on our store.
Thanks for reading the blog, and best of luck with your improvement efforts.
Our 2016 Global TapRooT® Summit was a great success last year! Our attendees helped one another by sharing some of their best practices. Watch as Megan Lowry talks about the use of fees to improve safety on the airport apron.
(Click post title if the video is not displaying.)
If you’re a TapRooT® User, you know that drawing a SnapCharT® is the first step in your investigation whether it is for a low-to-medium risk incident or a major Investigation. What is a SnapCharT®? It is a timeline of events, a fact-finding tool that helps an investigator understand what happened.
So why is a SnapCharT® essential to evidence collection? Here are three reasons:
- It is an investigator’s duty to support all the facts discovered on the SnapCharT® with evidence. Otherwise, the timeline is simply an assumption of events. One of the primary reasons investigators run into problems determining causal factors is because the sequence of events they developed was not supported by evidence.
- A SnapCharT® is a planning tool for evidence collection. It helps organize and understand what information is readily available and what needs to be collected immediately.
- A SnapCharT® helps an investigator establish a list of potential witnesses to interview. Also, instead of starting interviews with the generic, “Tell me what happened,” investigators can ask questions right off of their SnapCharT®s.
These are only three ideas about how you can use a SnapCharT® for evidence collection. Did you know we offer a 2-day course on all of the advance techniques of evidence collection and interviewing? Learn about it here.
We also have a new book, Evidence Collection and Interviewing Techniques to Sharpen Investigation Skills that will be released soon. Would you like to be added to the waiting list? Contact me at firstname.lastname@example.org and I will let you know as soon as it is added to our online store. Also, please don’t hesitate to contact me if you are interested in holding the course at your facility. As a co-developer of the course, I can answer your questions and help you determine if it’s a good fit.
Our 2016 Global TapRooT® Summit was a great success last year! Our attendees helped one another by sharing some of their best practices. Here is Debra Matson describing how they use opinion makers to improve their RCA performance.
(Click post title if the video is not displaying.)
Many forget that procedures were put in place to prevent a loss of control of a process, or if a regulatory driven requirement to use a procedure, a perceived risk of loss of control of the process. With that concept in mind, we can see in the image above that procedures are a lower and less reliable control in the mistake-proofing hierarchy and that it requires more external quality control assessments and observations.
But this article is not about how much quality control is needed to ensure that workers use a procedure as written to prevent mistakes. Instead, this article is about when workers make a mistake when they followed the mistake-proofing procedure as written. If a procedure is already at a weak level of control, how is it that an issue with writing of, auditing of or use of an ineffective procedure was allowed to exist?
To clarify how TapRooT® Root Cause Analysis defines a procedure, we look at the intent of how it is used and not necessarily what it is called. If a list of steps on how to perform a task is written down and must be read and followed while performing the task, it is a procedure to TapRooT®. For example,
- A metal placard on how to set up the lathe that you require the operator to read every time for set up is a procedure.
- The SOP for putting on your seatbelt listed in the car manual that you only reference occasionally to successfully put your seatbelt on is NOT a procedure.
Not every task needs a procedure as TapRooT® defines so why is this distinction about procedures and non-procedures important? Simple….
.. if the task to be performed cannot be done out of sequence and a step is so critical not to miss and the steps are too numerous to remember successfully, that procedure better meet the needs of the task and the worker.
You must assess the worker’s knowledge and the tools required to be used during the task as it relates to the procedure in use.
Years ago I was asked to analysis a quality defect that occurred on a large product assembly line after workers had cut off too much material. Initially management thought that the two assemblers did not follow the procedure as written and wrote them up per the discipline policy. After further analysis however, the assemblers did use it as written, but the procedure as written did not fulfill the successful implementation of the task. By the way, this procedure had been in use for years. How??
Procedure related root causes identified for why the assemblers cut off too much material from the product while assembling it using the procedure as written were:
- Details Need Improvement – The procedure stated to install a cutting tool but never identified that shims had to be put in plus to center the cutting tool into the assembly prior to cutting the excess material off. The person who did this task for 20 years had just retired and the task was given to two experienced assemblers new to this task.
- Graphics Need Improvement – The picture of the access opening with the tool placed in it included no indication of centering nor any measurements.
There was another root cause that was not due to how the procedure was written but tied to the tool that was specified to be used:
- Tools/instruments Need Improvement – The cutting tool cutouts never perfectly aligned to the access opening in all areas of the assembly. The long term assembler would always use the tool up to a point and then cut by hand using his own measurements and skill.
This then made us look at our audits and tool calibration as this tool and procedure had been inspected numerous times throughout the years but never at the task level. Your take home today:
.. if the task to be performed cannot be done out of sequence, and a step is so critical not to miss, and the steps are too numerous to remember successfully, that procedure better meet the needs of the task and the worker.
If you want to see examples of other poorly written procedures and want to learn how to assess and correct this procedures at the task level, join us at an upcoming 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training Course.
Our 2016 Global TapRooT® Summit was a great success this year! Our attendees helped one another by sharing some of their best practices. Listen as George Kooi describes how their
leadership validates Corrective Actions through approval of the Corrective Actions https://vimeo.com/194840836
(Click post title if video is not displaying.)