Once you’ve gathered all the information you need for a TapRooT® investigation, you’re ready to start with the actual root cause analysis. However, it would be cumbersome to analyze the whole incident at once (like most systems expect you to do). Therefore, we break our investigation information into logical groups of information, called Causal Factor groups. So the first step here is to find Causal Factors.
Remember, a Causal Factor is nothing more than a mistake or an equipment failure that, if corrected, could have prevented the incident from happening (or at least made it less severe). So we’re looking for these mistakes or failures on our SnapCharT®. They often pop right off the page at you, but sometimes you need to look a little harder. One way to make Causal Factor identification easier is to think of these mistakes as failed or inappropriately applied Safeguards. Therefore, we can use a Safeguard Analysis to identify our Causal Factors.
There are just a few steps required to do this:
First, identify your Hazards, your Targets, and any Safeguards that were there, or should have been there.
Now, look for:
- an error that allowed a Hazard that shouldn’t have been there, or was larger than it should have been;
- an error that allowed a Safeguard to be missing;
- an error that allowed a Safeguard to fail;
- an error that allowed the Target to get too close to a Hazard; or
- an error that allowed the Incident to become worse after it occurred.
These errors are most likely your Causal Factors.
Let’s look at an example. It’s actually not a full Incident, but a VERY near miss. This video is a little scary!
Let’s say we’ve collected all of our evidence, and the following SnapCharT is what we’ve found. NOTE: THIS IS NOT A REAL INVESTIGATION! I’m sure there is a LOT more info that I would normally gather, but let’s use this as an example on how to find Causal Factors. We’ll assume this is all the information we need here.
Now, we can identify the Hazards, Targets, and Safeguards:
|Pedestrians (they could have stayed off the tracks)|
Using the error questions above, we can see that:
- An error allowed the Hazard to be too large (the train was speeding)
- An error allowed the Targets to get too close to the Hazard (the Pedestrians decided to go through the fence, putting them almost in contact with the Hazard)
These 2 errors are our Causal Factors, and would be identified like this:
We can now move on to our root cause analysis to understand the human performance factors that lead to this nearly tragic Incident.
Causal Factors are an important tool that allow TapRooT® to quickly and accurately identify root causes to Incidents. Using Safeguard Analysis can make finding Causal Factors much simpler.
Sign up to receive tips like these in your inbox every Tuesday. Email Barb at email@example.com and ask her to subscribe you to the TapRooT® Friends & Experts eNewsletter – a great resource for refreshing your TapRooT® skills and career development.
The last paragraph of the article was:
“Let’s hope that the root cause analysis of the incident will explore the management system related failures that led to the reasons for the degraded emphasis on nuclear safety and security that caused the ‘Pause’ to be needed and not be an example of the blame game that points the finger at workers and low level supervisors and their actions.“
So here is what the Aiken Standard wrote about the SRNS root cause analysis:
“Following a root cause analysis of the incident, Spears said the incident was a result of the work team’s willful procedure violation and its unwillingness to call a time out. As a result, the contractor addressed the job performance of individuals using the SRNS Constructive Discipline Program and took appropriate disciplinary actions, according to SRNS.”
What do you think? Did they look into Management System causes?
If they don’t find and fix the Management System causes … how will they prevent a future repeat of this incident?
In my experience, very seldom is someone a “bad person” that needs to be corrected using a discipline system. Usually, when someone breaks the rules, it is because a culture of rule breaking (or expediency) has taken hold in order to deal with unrealistic goals or unworkable procedures.
I don’t think I have ever seen a team of bad people. If a “team” has gone bad (especially if a supervisor is involved), I would bet that the culture of expediency has been promoted. This bunch was just unfortunate enough to get caught in a serious incident and were handy to blame. No reason to look for any Management System causes.
This is how a culture of expediency exists alongside a culture of blame.
What can you learn from this incident?
One reason you use the TapRooT® System for root cause analysis is to find Management System root causes and fix them so that your management and employees don’t slip into a culture of expediency and blame.
The Wall Street Journal story above raises a great question. How effective is a federal prosecution in improving corporate and employee behavior?
Of course, the article was written by Kurt Mix, the accused, but it seems to raise very valid points that government investigations can go out of control, and that individuals have a very hard time fighting back against “the system.”
Why is the advice of any good attorney to “say nothing” to a criminal investigator before you have an attorney advising you? Because you may not know what serious laws you are breaking by what you see as non-criminal behavior.
Can this “don’t talk” advice make it harder for investigators to find the root causes of an accident? You bet!
So the next time you think that a criminal investigation is the answer to improve safety performance, maybe you should think again.
IOGP SAFETY ALERT
WELL KICK DUE TO LINER TOP SEAL FAILURE
After several attempts and a dedicated leak detection run, the 7” and 5” x 4-1/2” liner were inflow tested successfully to max difference of +10 bar.
Ran completion in heavy brine and displaced well to packer fluid (underbalanced).
Rigged up wireline pressure control equipment to install plug and prong in tubing tailpipe. While RIH with the plug on WL, a sudden pressure increase was observed in the well. Pressure increased to 125 bar on the tubing side.
Attempted to bleed off pressure, but pressure increased to 125 bar immediately.
Continued operation to install plug, pressure up tubing and set production packer.
Performed pump and bleed operation to remove gas from A-annulus. The general gas alarm was triggered during his operation due to losing the liquid seal on the poorboy degasser.
Continued pump and bleed operation until no pressure on tubing and A-annulus side, and the tubing and A-annulus were tested successfully.
What Went Wrong?
Failure of the 5″ liner hanger and 5″ tie-back packer.
Corrective Actions and Recommendations:
Difficult to bleed out gas in a controlled way due to sensitive choke and no pressure readings from poorboy degasser.
When performing pump and bleed operations, line up to pump down one line and take returns in a different line to optimize the operation.
Consider adequacy of the testing of the 5″ liner hanger.
Safety Alert Number: 267
IOGP Safety Alerts http://safetyzone.iogp.org/
Whilst every effort has been made to ensure the accuracy of the information contained in this publication, neither the IOGP nor any of its members past present or future warrants its accuracy or will, regardless of its or their negligence, assume liability for any foreseeable or unforeseeable use made thereof, which liability is hereby excluded. Consequently, such use is at the recipient’s own risk on the basis that any use by the recipient constitutes agreement to the terms of this disclaimer. The recipient is obliged to inform any subsequent recipient of such terms.
This document may provide guidance supplemental to the requirements of local legislation. Nothing herein, however, is intended to replace, amend, supersede or otherwise depart from such requirements. In the event of any conflict or contradiction between the provisions of this document and local legislation, applicable laws shall prevail.
Many people ask “What makes a good RCA?”. This question as stated is difficult to answer due to the fact that “good” is a very subjective term. What is good for one may not be good enough for another and vice versa. But, if we replace one simple word in that question we can make it a much more objective question. By changing that term to “credible” and/or “effective,” now we have a good starting point as both these terms have investigative standards and principles behind them. Let’s start with some definition:
Credible: This term is defined as “able to be believed; convincing.” Let’s focus on an investigation for our example and ask what would make our investigation able to be believed? One simple answer comes to mind, the ability to see the relationship between our Root Causes, our Causal Factors, and our Incident. That “Specific” relationship as we call it is dependent on the data collected in an investigation and ability for your audience to be able to connect those “dots” if you will.
Effective: This term is defined as “successful in producing a desired or intended result”. This focuses on the outcome of an action and what the desired results or end point is. For investigations the outcome or desired result is to implement fixes and Corrective Actions that will in the future reduce the risk of or remove the risk of a reoccurrence. The audience’ ability to see the effectiveness of the Corrective Actions is key.
So if we add both these words together and use them in combination to define an investigation we can now see how to answer the initial question.
Credible Root Cause Analyses
Let’s begin with the word credible and provide some guidance for our TapRooT® Users. When I look at and review any investigation the credibility is established for me in two techniques, the SnapCharT® and the Root Cause Tree®.
Let me put this as simply and as plainly as I can, when building your chart the team should put ALL information into that SnapCharT®. No matter how insignificant something may seem, or how common place something may be it should be on the chart for transparency and for use during the analysis on the Root Cause Tree®. Anytime you make a conscious effort to leave information off the chart you open yourself up for questions and you reduce the ability of your audience to “connect the dots” as mentioned above. This lowers your credibility significantly.
This can also lead to issues when your audience tries to understand the relationship between the Root Causes you have chosen on the Root Cause Tree® and the information on the SnapCharT®. This relationship should be as “transparent” as possible and the audience should not have to work to figure out the relationship. There should be a direct link between data on the chart and the Root Causes from the Root Cause Tree®.
Root Cause Tree®
Once the thorough “transparent” SnapCharT® is completed and the investigation move into the Root Cause Tree® to analyze your Causal Factors, documentation is the key to credibility. Three statements that can kill credibility are: “I believe,” “I think,” and “I am pretty sure,” Each one of these statements provides your audience with doubt as to what you truly know. This is why I always recommend the use of the Root Cause Tree® Dictionary and Analysis Comments in the Root Cause Tree® for documentation. This provides the connection and the defendable path for you and your audience.
As the Tree is analyzed the investigation should have data from the SnapCharT® to confirm each selection on the Root Cause Tree® as well as one or many questions answered as a yes from the Dictionary. Take that data (cut and paste) and put that into the Analysis Comments in the TapRooT® Software to document “why” you answer yes, and to show the audience your reasoning.
We have explored the “Credibility” of analyses so now we need to look at the Effective portion. We concluded that this measure is tied to the effectiveness of the Corrective Actions we present and implement. An analysis by itself cannot be effective without corrective and preventative actions that solve the Root Causes and prevent or reduce the likelihood of recurrence in the future.
When developing our Corrective Actions for the Root Causes we find during our analyses we have to consider the following items for each action:
Implementation: The act of putting the specific action in place in our systems and organization
Verification: This is a short-term measure of implementation. How are we going to ensure that what we proposed as the Corrective Action was implemented properly.
Validation: This is a long-term measure of effectiveness. This plan is based around the question, “What will success look like?” built with a plan to measure the progress (or regression) towards that outcome.
Most companies do a pretty effective job of the Implementation phase, implementing actions for every root cause. But in follow-up to these actions they do nothing; seemingly they wash their hands of the issue and say they are done. Implementation by itself does not ensure success. The two measurements above are very important because the provide some level of oversight for the actions and are a quality control check to make sure the actions hit the mark. If for any reason the Validation shows that the action is not having the desired effect the action needs to be revisited and revised if necessary starting the cycle again.
If Corrective Actions are implemented and not measured you increase the risk of the implementation falling short, or the action itself not actually having a positive impact on your systems and employees.
In the end, the credibility of your analysis is dependent on the data you collect, the quality (not quantity) of the data, and how it is used to confirm any answers found on the Root Cause Tree®. The effectiveness is dependent on the success of the corrective actions implemented and the longer term sustained success of the changes in the system to stop future recurrence. By following the 7-Step Process flow, and the Core techniques highlighter here within the TapRooT® process the system will guide you through these steps and aid you in successfully providing your management with a very Credible and Effective Investigation.
Want to learn more?
Our 5-Day TaprooT® Advanced Root Cause Analysis Team Leader Training provides all of the essentials to perform a root cause analysis plus advanced techniques. You also receive a single user copy of TapRooT® software in the 5-day course. The software combines incident identification, analysis, and dynamic report writing into one seamless process.
I saw an article about a hospital error that injured a patient. The article said they were going to perform a root cause analysis. It’s strange how a simple line in an article can get me WORKED UP.
Why am I WORKED UP? I know that many root cause analyses are BAD. What defines bad root cause analysis?
- The look to place blame.
- They look to cover up mistakes.
- They look for easy answers.
- They jump to conclusions.
- They pick their favorite root causes.
- They don’t improve performance.
That’s a BAD list. But I see it all the time.
In fact, that’s why I started to work inventing TapRooT®. I wanted to solve those problems. And for many TapRooT® Users, we have.
But there still is a long way to go.
There are still people who think that 5-Whys is a good system (some would even say an advanced system) for finding root causes.
Some don’t recognize the drawback of using cause and effect to analyze problems. That there is a tendency to find the answer that you want to find (rather than looking at the evidence objectively).
Some think that just filling out a form is good enough. Somehow this will prevent mistakes and save lives.
WELL I HAVE NEWS FOR THEM … It hasn’t worked for years and it won’t start working tomorrow!
The definition of insanity is to keep doing things the same way and to expect a different result.
Don’t be insane!
It is time to try TapRooT® and see how it can help guide you to the real, fixable causes of problems.
We guarantee our courses.
Here is the guarantee:
Attend the course, go back to work, and use what you have learned to analyze accidents, incidents, near-misses, equipment failures, operating issues, or quality problems. If you don’t find root causes that you previously would have overlooked and if you and your management don’t agree that the corrective actions that you recommend are much more effective, just return your course materials/software and we will refund the entire course fee.
If you are investigating serious problems, then attend a 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Course. Here’s more information about the course: http://www.taproot.com/courses#5-day-root
Here are our upcoming public courses being held around the world:
Found an interesting old (2000) report from the UK HSE about incident/accident investigations. They had a contractor perform surveys about accident/incident investigation tools and results.
TYPE OF INVESTIGATION SYSTEM
It seems that homegrown investigation systems or no system were the most frequently used to investigate accidents/incidents.
With that type of investigation system, it should be no surprise that the three top corrective actions were:
- Tell them to be more careful/aware.
- Training/refresher training
- Reinforce safe behavior (Is that discipline?)
That’s what we found back in the early 1990’s.
Think it has changed any today?
HOW MUCH TIME SPENT INVESTIGATING?
Another interesting fact. How long did people typically spend doing investigations?
- 42% took 5 hours or less
- 35% took 5 to 20 hours
- 18% took over 20 hours
One third of those polled had NO accident/incident investigation training. Most of the rest just had general health and safety training as part of IOSH or NEBOSH courses. Also, most people performing investigations were not dedicated health and safety professionals.
What do you think? Is this similar to your experience at your company?
The report then provided a review of example investigations that the researchers had reviewed. As an expert in root cause analysis, these were awful but typical. many just filled out a form. Others grilled people and decided what they thought were the causes and the corrective actions.
HOW ARE YOU DOING?
Are you 15 years behind with no system, no training, and bad results?
Then you need to attend a TapRooT® Course. See: http://www.taproot.com/courses
Have you started to improve but still have a long way to go? You might want to attend one of our public 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training Courses. See: http://www.taproot.com/store/5-Day-Courses/
Are you good to great but you want to be even better? The plan to attend the 2016 Global TapRooT® Summit in San Antonio, TX, on August 1-5. We’ll be posting more details about the Summit soon.
After an accident, what is the risk that you face if you restart production before you find and fix the root causes of an accident? Starting too soon may risk the chance of another disaster.
Of course, that depends on the risk profile of the accident in question and your operations.
SpaceX is keeping their Falcon 9 rocket grounded for a couple more months after a June explosion of their booster rocket that was carrying supplies to the international space station.
Troubleshooting after the accident points to a failed strut that was holding a bottle of helium in place that, when it failed, caused an over-pressure of the second-stage rocket. See the story here.
Do you analyze the risk of restarting production after an incident or accident? Perhaps this is something your management should consider?
This is not the Friday Joke.
Root cause analysis has become so popular that politicians are now calling for companies to complete a root cause analysis and implement corrective actions.
Massachusetts Governor Charlie Baker wrote a letter to Entergy Nuclear Operations calling on them to “… perform an appropriate root cause analysis …” of safety issues the NRC had announced “… and to complete all necessary repairs and corrective actions.”
The letter was in response to an unplanned shutdown at the Pilgrim nuclear power plant in Plymouth, Massachusetts caused by a malfunctioning main steam stop valve (one of eight valves that is designed to shut off steam from the reactor to the turbine that generates electricity). The valve had failed shut.
For all those not in the nuclear industry, note that in the nuclear industry, a failure of one of eight valves that failed in the safe direction (shut) and that has backup safety systems (both manual and automatic) can get a public letter from the Governor and attention from a federal regulator. Imagine if you had this level of safety oversight of your systems. Would your equipment reliability programs pass muster?
The response from Entergy to the Governor noted that, “We have made changes and equipment upgrades that have already resulted in positive enhancements to operational reliability.” (Note that these fixes occurred in less than a week after the original mechanical failure.)
For more about the story, see: http://www.wbur.org/2015/09/03/baker-pilgrim-nuclear
Note the local NPR story at the link above is inaccurate in its description of the problem and the mechanical systems.
For those interested in improving equipment reliability and root cause analysis, consider attending one of our 3-Day TapRooT®/Equifactor® Equipment Troubleshooting and Root Cause Analysis Courses. See the upcoming course list at:
Now for the biggest question …
When will government authorities start applying root cause analysis
to the myriad of problems we face as a nation and start implementing appropriate corrective actions?
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.
I’m in the process of writing a new set of TapRooT® Books. The first one I’m writing is about investigating simple incidents using the basic tools of TapRooT®.
To give you a sneak preview, if you decide to investigate an incident, the minimum technique to use is a SnapCharT®.
From the initial SnapCharT®, the investigator must decide if the incident is worthy of further effort (can something worthwhile be learned).
What’s next? What do you do if you decide to go beyond the initial SnapCharT®?
You will have to wait for the new book to be released early next year to find out what we are recommending. But I can give you a hint ,,, It won’t be asking why five times!
Do you like quick, simple tips that add value to the way you work? Do you like articles that increase your happiness? How about a joke or something to brighten your day? Of course you do! Or you wouldn’t be reading this post. But the real question is, do you want MORE than all of the useful information we provide on this blog? That’s okay – we’ll allow you to be greedy!
A lot of people don’t know we have a company page on LinkedIn that also shares all those things and more. Follow us by clicking the image below that directs to our company page, and then clicking “Follow.”
We also have a training page where we share tips about career/personal development as well as course photos and information about upcoming courses. If you are planning to attend a TapRooT® course or want a job for candidates with root cause analysis skills, click the image below that directs to our training page and then click “Follow.”
Thank you for being part of the global TapRooT® community!
Monday Accident & Lessons Learned: IOGP SAFETY ALERT- GAS BREAK-OUT FROM OIL-BASED MUD WHILE RUNNING CASINGAugust 10th, 2015 by Mark Paradies
IOGP SAFETY ALERT GAS BREAK-OUT FROM OIL-BASED MUD WHILE RUNNING CASING
- The event took place on a 3000 HP Land Drilling Rig while running 9 7/8” casing in the 12 ¼” hole section of an unconventional well. Well was vertical.
- Well architecture consists of 20” Surface Casing at 945m, 13 3/8” casing at 3348 m at 12 ¼” hole section at 4794m.
- Run 9 7/8” casing to 4793m.
- After landing casing, circulated 9 7/8” casing, increasing pump rates from 0.70 m3/min to 1.45 m3/min and SPP of 450 kPa.At 2000 strokes into bottoms up, returns diverted through the manifold. Maximum gas of 2500 units observed prior to going through MGS.
- Circulate through choke at 1.0 – 1.5 m3/min. Initial casing pressure of 170 kPa and SPP of 570 kPa. Casing pressure spiking at 5800 strokes to 9500 kPa and decreasing to 2100 kPa as bottom up strokes expired.
- Significant amount of gas observed at surface. Approximately 5 m3 of invert drilling fluid was spilled over from open bottom poor boy degasser (MGS) while circulating bottoms up.
- Shut in well & monitored for pressure evaluation.
- Observed increase in SIDPP & SICP.
- Continued to monitor pressure evolution.
- Pressure stabilized at SIDPP 300 kPa & SICP 450 kPa.
- Performed drillers method well kill and stabilized well with mud weight of 1750 kg/m3.
- Well was static prior to bottoms up circulation (some reports noted minor flow when landing mandrel hanger).
- During the bottoms up, returns were diverted to MGS as a precaution for trip gas and because pump pressure was much less than expected.
- The gain was not noticed until the well was circulated once the casing was on bottom.
- The section was drilled with a narrow mud-weight window.
What Went Wrong?
- Gas entered the wellbore while well was static.
- Insufficient hydrostatic pressure to prevent influx of formation fluid.
- Well flow checks were inconsistent prior to tripping to run casing and were not sufficient to indicate potential influx of formation fluid into the well.
- Circulation rate was adjusted to take into account the reduced volume of the annulus associated with the casing as compared to the large annular volume associated with drill pipe to ensure that the annular velocity was the same. However, this still resulted in the gas entrained in the drilling fluids coming to surface at a rate that exceeded the capacity of the MGS.
- Choke was in the 100% open position as it should be when gas arrived at the surface because of concerns about exceeding MAASP. This resulted in maximum flow to the MGS exceeding the off-gassing and flaring capacity of the MGS flare system.
- Possibly drilled too far into the HPHT pressure ramp in 12 ¼” hole section.
Corrective Action & Recommendations:
A definitive HPHT well control procedure will be developed for drilling operations in noted area.
- Review MGS Sizing calculations for maximum anticipated gas rates. Understand capacity of oil based mud to absorb gas.
- Develop a log sheet to better monitor and finger print trip gas, bottom’s up gas, connection gas and background gas to better understand potential behaviour at surface.
- Drilling engineering team initiate and lead researching and acquiring a better way of determining needed mud weight trip margin requirements for making trips to log or run casing, with a better understanding of the fluids system EMW and ECD’s.
safety alert number: 266
IOGP Safety Alerts http://safetyzone.iogp.org/
Whilst every effort has been made to ensure the accuracy of the information contained in this publication, neither the IOGP nor any of its members past present or future warrants its accuracy or will, regardless of its or their negligence, assume liability for any foreseeable or unforeseeable use made thereof, which liability is hereby excluded. Consequently, such use is at the recipient’s own risk on the basis that any use by the recipient constitutes agreement to the terms of this disclaimer. The recipient is obliged to inform any subsequent recipient of such terms.This document may provide guidance supplemental to the requirements of local legislation. Nothing herein, however, is intended to replace, amend, supersede or otherwise depart from such requirements. In the event of any conflict or contradiction between the provisions of this document and local legislation, applicable laws shall prevail.
London office: 209-215 Blackfriars Road, London SE1 8NL, United Kingdom T. +44 (0)20 3763 9700 F. +44 (0)20 3763 9701 E. firstname.lastname@example.org
You have established a good performance improvement program, supported by performing solid incident investigations. Your teams are finding good root causes, and your corrective action program is tracking through to completion. But you still seem to be seeing more repeat issues than you expect. What could be the problem?
We find many companies are doing a great job using TapRooT® to find and correct the root causes discovered during their investigations. But many companies are skipping over the Generic Cause Analysis portion of the investigation process. While fixing the individual root causes are likely to prevent that particular issue from happening again, allowing generic causes to fester can sometimes cause similar problems to pop up in unexpected areas.
6 Reasons to Look for Generic Root Causes
Here are 6 reasons to conduct a generic cause analysis on your investigation results:
1. The same incident occurs again at another facility.
2. Your annual review shows the same root cause from several incident investigations.
3. Your audits show recurrence of the same behavior issues.
4. You apply the same corrective action over and over.
5. Similar incidents occur in different departments.
6. The same Causal Factor keeps showing up.
These indicators point to the need to look deeper for generic causes. These generic issues are allowing similar root causes and causal factors to show up in seemingly unrelated incidents. When management is reviewing incident reports and audit findings, one of your checklist items should be to verify that generic causes were considered and either addressed or verified not to be present. Take a look at how your incident review checklist and make sure you are conducting a generic cause analysis during the investigation.
Finding and correcting generic causes are basically a freebie; you’ve already performed the investigation and root cause analysis. There is no reason not to take a few extra minutes and verify that you are fully addressing any generic issues.
What can you learn from transport aircraft accidents? See the FAA Lessons Learned from Transport Plane Accidents page and find out. See:
The Associated Press reported that the US Department of Justice is warning food companies that they could face civil and criminal charges if they poison their customers.
POISON THEIR CUSTOMERS!
Yes, you read it right.
We are again testing the fine line between accidents and criminal behavior.
How does a company know that they have gone over the line? The FDA stops showing up and the FBI puts boundary tape around your facilities.
Are you in the food business? Think it is time to start taking root cause analysis of food safety incidents seriously? You betcha!
Your company can’t afford a Blue Bell Ice Cream incident. You need to effectively analyze and learn from smaller incidents to stop the big accidents from happening.
What tool should you use for effective root cause analysis? The TapRooT® Root Cause Analysis System.
Why choose TapRooT® Root Cause Analysis?
Because it has proven itself effective in a wide number of industries around the world. That’s why industry leaders use it and recommend it to their suppliers.
Find out more about the TapRooT® System at:
And then attend one of our public courses held around the world.
You can attend at no risk because of our iron-clad guarantee:
Attend a TapRooT® Course, go back to work, and use what you have learned to analyze accidents, incidents, near-misses, equipment failures, operating issues, or quality problems. If you don’t find root causes that you previously would have overlooked and if you and your management don’t agree that the corrective actions that you recommend are much more effective, just return your course materials/software and we will refund the entire course fee.
Get started NOW because you can’t afford to wait for the FBI to knock on your door with a warrant in their hand.
Have you ever seen this video about the 2009 train derailment in Graniteville, SC?
Could have we learned these lessons before people were killed?
The 22-year-old man died in hospital after the accident at a plant in Baunatal, 100km north of Frankfurt. He was working as part of a team of contractors installing the robot when it grabbed him, according to the German car manufacturer. Volkswagen’s Heiko Hillwig said it seemed that human error was to blame.
A worker grabs the wrong thing and often gets asked, “what were you thinking?” A robot picks up the wrong thing and we start looking for root causes.
Read the article below to learn more about the fatality and ask why would we not always look for root causes once we identify the actions that occurred?
Lessons learned from five accidents reported by EU and OECD Countries. See:
Read insights on lessons learned from accidents reported in the European Major Accident Reporting System (eMARS) and other accident sources.
47 accidents in eMARS involving contractor safety issues in the chemical or petrochemical industries were examined. Five accidents were chosen on the basis that a contract worker was killed or injured or was involved in the accident.
What do you think? Leave your comments below.
“Doctor… how do you know that the medicine you prescribed him fixed the problem,” the peer asked. “The patient did not come back,” said the doctor.
No matter what the industry and or if the root causes found for an issue was accurate, the medicine can be worse than the bite. Some companies have a formal Management of Change Process or a Design of Experiment Method that they use when adding new actions. On the other extreme, some use the Trial and Error Method… with a little bit of… this is good enough and they will tell us if it doesn’t work.
You can use the formal methods listed above or it can be as simple for some risks to just review with the right people present before implementation of an action occurs. We teach to review for unintended consequences during the creation of and after the implementation of corrective or preventative actions in our 7 Step TapRooT® Root Cause Analysis Process. This task comes with four basic rules first:
1. Remove the risk/hazard or persons from the risk/hazard first if possible. After all, one does not need to train somebody to work safer or provide better tools for the task, if the task and hazard is removed completely. (We teach Safeguard Analysis to help with this step)
2. Have the right people involved throughout the creation of, implementation of and during the review of the corrective or preventative action. Identify any person who has impact on the action, owns the action or will be impacted by the change, to include process experts. (Hint, it is okay to use outside sources too.)
3. Never forget or lose sight of why you are implementing a corrective or preventative action. In our analysis process you must identify the action or inaction (behavior of a person, equipment or process) and each behaviors’ root causes. It is these root causes that must be fixed or mitigated for, in order for the behaviors to go away or me changed. Focus is key here!
4. Plan an immediate observation to the change once it is implemented and a long term audit to ensure the change sustained.
Simple… yes? Maybe? Feel free to post your examples and thoughts.
Is thinking that you are the best a sign of potential problems? (Especially for “routine” work?)
By any measure, the X-31 was a highly successful flight research program at NASA’s Dryden Flight Research Center, now the Armstrong Flight Research Center. It regularly flew several flights a day, accumulating over 550 flights during the course of the program, with a superlative safety record. And yet, on Jan. 19, 1995, on the very last scheduled flight of the X-31 ship No. 1, disaster struck.
View the video below or read about it here: http://www.nasa.gov/centers/dryden/news/X-Press/stories/2004/013004/new_x31.html
Leave your comments below. Complacency? Leave your comments below.
We can all remember some type of major product recall that affected us in the past (tires, brakes, medicine….) or recalls that may be impacting us today (air bags). These recalls all have a major theme, a company made something and somebody got hurt or worse. This is a theme of “them verses those” perception.
Now stop and ask, when is the last time quality and safety was discussed as one topic in your current company’s operations?
You received a defective tool or product….
- You issued a defective tool or product….
- A customer complained….
- A customer was hurt….
Each of the occurrences above often triggers an owner for each type of problem:
- The supplier…
- The vendor…
- The contractor…
- The manufacturer….
- The end user….
Now stop and ask, who would investigate each type of problem? What tools would each group use to investigate? What are their expertise and experiences in investigation, evidence collection, root cause analysis, corrective action development or corrective action implementation?
This is where we create our own internal silo’s for problem solving; each problem often has it’s own department as listed in the company’s organizational chart:
- Customer Service (Quality)
- Manufacturing (Quality or Engineering)
- Supplier Management (Supply or Quality)
- EHS (Safety)
- Risk (Quality)
- Compliance (?)
The investigations then take the shape of the tools and experiences of those departments training and experiences.
Does anyone besides me see a problem or an opportunity here?
A tragic workplace accident.
A life lost.
You see the resolve on the faces in this video to never lose a co-worker … a friend … to this type of accident again.
What do you think about “paying attention” for preventing potential tragedies such as this? Leave your comments below and let’s share ideas to find and fix root causes.
What can you learn from a 1964 video?
How they viewed human performance was certainly different.
What do we know that helps us do better today?
Could better root cause analysis have helped them then? After all, an engine failure in a helicopter is a serious accident to blame on the pilot.