Category: Root Cause Analysis Tips
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 email@example.com 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.)
Whether analyzing customer complaints, process defects or safety findings, the use of 5 Whys for problem-solving has been in place for many years; if you are still using it for low risk issues, below are links to additional articles to help you be more effective in its use:
This blog article, however, is to understand what many mean when asking why or how it is perceived when asked why during problem solving. I thought I would make it easy and define what why means using the Oxford Dictionary. I asked myself why after I did that!
– Expressing surprise or indignation: Why, that’s absurd!
– Used to add emphasis to a response: You think so? Why, yes.
– For what reason or purpose: Why did he do it?
– [with negative] Used to make or agree to a suggestion: Why don’t I give you a lift?
– (with reference to a reason) on account of which; for which: The reason why flu jabs need repeating every year is that the virus changes.
– The reason for which: Each has faced similar hardships, and perhaps that is why they are friends.
– A reason or explanation: The whys and wherefores of these procedures need to be explained to students.
– Old English hwī, hwȳ ‘by what cause’, instrumental case of hwæt ‘what’, of Germanic origin.
Interestingly enough, the origin appears to be more representative of problem solving than any of the new definitions that appeared in the online Oxford dictionary. The majority of the new definitions appear to miss the mark in problem-solving.
Take the Interrogative adverb, “Why did he do it?” This can easily be perceived as blame waiting for an excuse of why he did it. Once the problem solver gets the excuse, then the investigation is complete. Especially if you are interviewing the person involved in the problem.
Why as a noun, defined as a reason or explanation, is often inferred to mean this is why the person was supposed to follow the rules, but it does not allow or encourage the rule to be reevaluated if it does not work as intended or is just plain wrong.
The exclamation why is one we should all relate to, “I’ll keep asking why until you change your tune.”
As an effective problem solver, review the definitions of why listed above and ask yourself, “Am I using why in problem solving the way it was originated or not? Have I stopped at why when I should have gone further into true effective root causes?”
Finally ask yourself, “Have I made these mistakes asking why on moderate to high level problems?”
If the answer is “yes” to the questions above, stop asking why and join us in one of our upcoming TapRooT® root cause analysis courses.
Here is a video that discusses some root cause tips, common problems with root cause analysis, and how TapRooT® can help. I hope you enjoy!
Like what you see? Why not join us at the next course? You can see the schedule and enroll HERE
Happy Wednesday and welcome to this week’s root cause analysis tips column. This week we will talk about Causal Factors.
The TapRooT® Definition of a Causal Factor is:
“A mistake, error, or failure that directly leads to (or causes) an Incident or fails to mitigate the consequences of the original error.”
This definition is one major thing that distinguishes TapRooT® from some other methods. We don’t just find the first thing that went wrong, we find EVERTHING that went wrong. I’ve had people say to me that “but if I fix the first problem the incident would not have happened.” That is actually true, but if I only focus on the first thing that went wrong (which is sometimes the most obvious), then I do not address everything else that is wrong with my system. It also allows people to fall into the trap of determining “the causiest causal factor” and ignoring everything else.
Consider this diagram:
So when looking for Causal Factors, I find the first error/failure (initiating error), and they look for chances to stop/catch/mitigate. Each time I fail to stop/catch/mitigate, it is a new Causal Factor.
You will also notice that we could have an initiating error later in the timeline was well. It could be completely unrelated but allowed the hazard to reach the target.
Here is an example:
*Someone turns the wrong valve and allows a hazard (this is an initiating error).
*A second check of the valve configuration was not completed as required (a chance to stop/catch the first error).
*Someone lights a cigarette in an unauthorized area (another initiating error).
*Emergency response team did not arrive for 30 minutes (chance to mitigate the consequences).
Each one of these would be a Causal Factor.
Defining Causal Factors does not have to be difficult. The more you do it, the more comfortable you will be. I find that the concept of stop/catch/mitigate can really be helpful in making sure you find ALL the problems that led to an incident.
So thanks for visiting our blog. I hope you don’t have an incident anytime soon, but if you do, I hope you find the information helpful. If you’re interested in learning more about identifying causal factors and finding the root causes of incidents, register for our 2-Day TapRooT® Root Cause Analysis Training.
Our 2016 Global TapRooT® Summit was a great success this year! Our attendees helped one another by sharing some of their best practices. William McClung describes how they allow leadership to be a champion for their investigation.
(Click post title if video is not displaying.)
After Mark Paradies presented a talk on root cause analysis at the 2016 PDA/FDA Joint Regulatory Conference, a question was asked,
“How can we use TapRooT® Root Cause Analysis specifically to help solve “biological” driven problems that occur during biopharmaceutical product processing?”
The group had many general questions during his talk titled, “Identification of True Root Cause – and Impact to the Quality System,” and liked the points that he made. The question above however made me wonder why some industries or some industry-specific issues appear more complex than others when it comes to problem solving.
We use Safeguard Analysis to help identify the factor hazard/safeguards/target during our TapRooT® Root Cause Analysis. We look for errors of loss of control in these factors to find if these changes impacted the big problem that we are investigating. We also look for these changes formally by using a Change Analysis Table, taught in our 5-Day Courses. The linked Safeguard Analysis article above walks you through a near miss incident with a fast moving train and people. Once you identify your Hazards, your Targets, and any Safeguards we ask simple questions such as:
– was there an error that allowed a Hazard that shouldn’t have been there, or was larger than it should have been;
– was there an error that allowed a Safeguard to be missing;
– was there an error that allowed a Safeguard to fail;
– was there an error that allowed the Target to get too close to a Hazard; or
– was there an error that allowed the Incident to become worse after it occurred.
So here is the complexity question, what makes a near miss with a train incident different or a biopharmaceutical product processing near miss more complex to investigate than a train incident? Can we use the same root cause process for both types of problems?
Let’s walk through how we can turn the complex into the simple.
Simplifying the Issue:
In safety investigations, either the target got hurt or almost hurt. If the target got hurt, how badly?
In biopharmaceutical investigations, either it is a True Batch Failure, a False Batch Failure, a Safety Compromised or a Non-Standard Efficacy issue.
The similarity between seeming complex productions verses a train incident? Either a hazard got to the Batch (target) knowingly or unknowingly and was the loss of control caught in time?
The other questions would be….
1. How easy would it be to document the process of transactions that occurred during the Batch Process?
2. How easy would it be to identify the hazards of say…moisture, catalyst issues, enzyme or bacteria controls for the Batch Process? Simply, did they get the recipe right?
3. Finally, once identified, can the SME’s identify the error opportunities listed above?
If you are in the Biopharmaceutical Industry whether from the GCP or GMP side, give us a call or just sign up for a course and apply it.
When we first started the development of TapRooT® back in the 1980s, we developed this definition of a root cause:
The most basic cause (or causes)
that can reasonably be identified
that management has control to fix
and, when fixed, will prevent
(or significantly reduce the likelihood of)
the problem’s recurrence.
The modern definition of a root cause, which was proposed in 2006 by Mark Paradies at the Global TapRooT® Summit and really isn’t so new, is:
The absence of best practices
or the failure to apply knowledge
that would have prevented the problem.
This modern definition of a root cause leads to this definition of root cause analysis:
Root Cause Analysis
The search for the best practices
and/or the missing knowledge that
will keep a problem from recurring.
Since most people (including, in the past, me) say that root cause analysis is the search for why something failed, this reversal of thinking toward looking for how to make something succeed is truly a powerful way of thinking. The idea changes the concept of root cause analysis.
Even though a decade had passed since proposing this new definition, I still have people ask:
“Why did you change the definition? I liked it like it was!“
Therefore, I thought that with the new TapRooT® Books coming out, I would explain our reasoning to show the clear advantage of the modern definition.
The modern definition focuses on the positive. You will search for best practices and knowledge. You aren’t looking for people to blame or management faults. Yes, a best practice or knowledge is missing, but you are going to find out how to do the work more reliably. Thus, the focus is on improvement … the opportunity to improve vision!
The same thing can be said about the old fashioned definition too. But the old definition focused on cause. The difference in the definitions is a matter of perspective. Looking up at the Empire State Building from the bottom is one perspective. Looking down the Empire State Building from the top is quite another. The old definition looked at the glass as half empty. The new definition looks at the glass as half full. The old definition focuses on the “cause.” The modern definition focuses on the solution.
This shift in thinking leads people to a better understanding of root causes and how to find them. When it is combined with the Root Cause Tree® and Dictionary, the thinking revolutionizes the search for improved performance.
The concept of looking for ways to improve has always been a part of the TapRooT® System. It is the secret that makes TapRooT® such a powerful tool. But the modern definition – the new perspective – makes it easier to explain to others why TapRooT® works so well. TapRooT® is a tool that finds the missing knowledge or best practices that are needed to solve the toughest problems.
One last note about the modern definition: In the real world, absolutes like “will prevent” can seldom be guaranteed. So the root cause definition should probably be augmented with the additional phrase: “or significantly reduce the likelihood of the problem’s recurrence.” We chose not to add this phrase in the definition to keep the message about the new focus as strong as possible. But please be aware that we understand the limits of technology to guarantee absolutes and the ingenuity of people to find ways to cause errors even in well-designed systems.
That’s the reasons for the definition change. You may agree or disagree, but what everyone finds as true is that TapRooT® helps you find and fix the root causes of problems to improve safety, quality, productivity, and equipment reliability.
Attend a TapRooT® Course and find out how TapRooT® can help your company improve performance.
Our 2016 Global TapRooT® Summit was a great success this year! Our attendees helped one another by sharing some of their best practices. Here Rajesh Malik talks about how his company encourages students to go back and apply what they learned in the TapRooT® course to their previous investigations.
(Click post title if video is not displaying.)
If you don’t understand what happened, you will never understand why it happened.
You would think this is just common sense. But if it is, why would an industry allow a culture to exist that promotes blame and makes finding and fixing the root causes of accidents/incidents almost impossible?
I see the blame culture in many industries around the world. Here is an example from a hospital in the UK. This is an extreme example but I’ve seen the blame culture make root cause analysis difficult in many hospitals in many countries.
Dr. David Sellu (let’s just call him Dr. Death as they did in the UK tabloids), was prosecuted for errors and delays that killed a patient. He ended up serving 16 months in high security prisons because the prosecution alleged that his “laid back attitude” had caused delays in treatment that led to the patient’s death. However, the hospital had done a “secret” root cause analysis that showed that systemic problems (not the doctor) had led to the delays. A press investigation by the Daily Mail eventually unearthed the report that had been kept hidden. This press reports eventually led to the doctor’s release but not until he had served prison time and had his reputation completely trashed.
If you were a doctor or a nurse in England, would you freely cooperate with an investigation of a patient death? When you know that any perceived mistake might lead to jail? When problems that are identified with the system might be hidden (to avoid blame to the institution)? When your whole life and career is in jeopardy? When your freedom is on the line because you may be under criminal investigation?
This is an extreme example. But there are other examples of nurses, doctors, and pharmacists being prosecuted for simple errors that were caused by systemic problems that were beyond their control and were not thoroughly investigated. I know of some in the USA.
The blame culture causes performance improvement to grind to a halt when people don’t fully cooperate with initiatives to learn from mistakes.
TapRooT® Root Cause Analysis can help investigations move beyond blame by clearly showing the systemic problems that can be fixed and prevent (or at least greatly reduce) future repeat accidents.Attend a TapRooT® Root Cause Analysis Course and find out how you can use TapRooT® to help you change a blame culture into a culture of performance improvement.
Foe course information and course dates, see:
A poorly written procedure can lead to unsafe work, reduced productivity, and organizational failures. A few tips can help you avoid these pitfalls. Procedures are action-oriented. They outline steps to take, and the order in which to take them. They are instructional, and may be used in training and orientation. Well-written procedures are solid, precise, factual, short, and to the point.
Here are five tips for writing better procedures:
- Avoid phrases like “as necessary,” “as applicable,” or “may include” because phrases like these are confusing. When would it be necessary? When is it applicable? When may it include something? Be clear, specific, and to the point.
- Be consistent with terminology. Clarify terminology for those who may not be familiar with it and use the same terminology in each step.
- Add visual aids like images, diagrams, or sketches to facilitate understanding of the process.
- Organize long procedures into sections. List less than ten steps per section. People lose focus when presented with a procedure with too many steps.
- Avoid using pronouns. Poor: “Turn it to the left.” Good: “Turn Lever A3 to the left.”
One reference that we recommend in the TapRooT® Corrective Action Helper® Guide is Procedure Writing: Principles and Practices, (1999) by Douglas Wieringa, Christopher Moore, and Valerie Barnes, published by Battelle Press, Columbus, Ohio.
Learn more in our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training (Click here to view course list).
Our 2016 Global TapRooT® Summit was a great success this year! Our attendees helped one another by sharing some of their best practices. Here Michael Miraglia details how his company creates what they call a “review cell” to investigate an incident.
(Click post title if video is not displaying.)
Happy Wednesday and welcome to this week’s Root Cause Analysis Tips. The topic this week is strength of safeguards.
We teach a lot of great stuff in our TapRooT® courses. In fact, our 5-day course is over 400 slides. In my opinion, this concept is the most important, and this is my favorite slide:
The diagram shows that the best corrective action is to remove the hazard; if we cannot do that, maybe we can reduce it (chemical substitution, for example).
If we can’t do a #1, possibly we can move the target away from the hazard (moving a desk in the warehouse away from forklift traffic, for example).
We keep moving down the list from strongest to weakest. But we start at the top.
So here is my question: If I were to pull out of random stack of investigations from any company, anywhere, what kind of corrective actions do you think I would see? What about your company? If you said 5’s and 6’s, you now know the reason that you have repeat incidents.
Please do not misunderstand me; I am not saying training and supervision are not needed, what I am saying is they are weaker safeguards. They can be good corrective actions and sometimes are the only ones feasible, but we should always start at the top of the matrix and work our way down.
In my last column I talked about layers of protection. Pretty simple, more layers means more protection. However, since all Safeguards are not equal, many layers of weak safeguards does not equal a few layers of strong ones.
If you just did this one thing in your company, I am confident that you would improve a great deal. Remember, corrective actions are the output of your investigation. You can do a great job on the investigation, but if you have weak corrective actions, you are WASTING YOUR TIME.
So please think about it. Thanks for visiting the blog, and enjoy your week.
Beginning your investigation can sometimes be quite a challenge. Deciding on who to talk to, what documents you need, what questions you need to ask, etc. can lead to feeling slightly overwhelmed. As General Creighton Abrams said,
When eating an elephant, take one bite at a time.
In other words, you just need to get started with the first step, and then methodically work your way through to the end.
In TapRooT®, that first bite is the SnapCharT®. The rest of your investigation is going to depend on the data you gather in that SnapCharT®, so it is critical that you begin in a simple, methodical manner.
Let’s say you get that initial notification phone call (usually at 3:00 am). You don’t get much information. Maybe all you know is, “Ken, we had a pipe rupture this morning during a hydrostatic test. Looks like the mechanics didn’t know what they were doing. They had hooked up a test pump to the piping, started the pump, and almost immediately ruptured the piping. We’ve cleaned up the water, and no one was hurt. We need you to investigate this.” This is a pretty common initial report. Not a lot of data, some opinions thrown in, and a request for answers. Without a structured process, most investigations would now start off with some interviews, asking pretty generic questions. It would be really nice if we could start off with some detailed, intelligent questions.
This is where the SnapCharT® comes in. Once you receive that initial phone call, just build your SnapCharT® with the information you have. It honestly won’t have much data, but that’s OK; it’s only your starting point:
However, with this initial SnapCharT®, it is now easier to visualize what you already know, and what you still need to know. For example, I’d have a lot of questions about the pump, the mechanics themselves, recovery actions, etc. I’d use the Root Cause Tree® to help me figure out what questions to ask. I’d take each Event and ask, “What do I already know about this Event, and what questions do I have about it?” These would all be added to the SnapCharT®. It might look more like this:
Keep in mind that these questions were developed before I even went to the scene or questioned anybody about the facts. I still need to interview people, but I now have a much better set of questions to begin my investigations. Many more questions will arise as I ask this initial set of questions, but I’ll feel much better prepared to start talking to people about the issue.
The SnapCharT® is a simple yet effective tool to help the investigator get started with the investigation. It may seem like an inconsequential step, easy to dismiss. However, using the SnapCharT® as your very first tool, before you start gathering data, can greatly speed up the investigation. It allows you to start on the right path, with a set of intelligent questions to ask. Once you have this moving, you’ll find the rest of the investigation falls into place in a logical, easy to follow format. ALWAYS START WITH A SNAPCHART®!
LEARN MORE about TapRooT® essentials in our 2-day course (View schedule and register!)
Above is the start of an OSHA/EPA Fact Sheet titled: “The Importance of Root Cause Analysis During Incident Investigation.”
OSHA and EPA want companies to go beyond fixing immediate cause (which may eliminate a symptom of a problem) and instead, find and fix the root causes of the problems (the systemic/underlying causes). This is especially important for process safety incidents.
The fact Sheet explains some of the basic of root cause analysis and suggests several tools for root cause analysis.
UNFORTUNATELY, many of the tools suggested by the fact sheet are not really suited to finding and fixing the real root causes of process safety incidents. They don’t help the investigator (or the investigative team) go beyond their current knowledge. Thus, the suggested techniques produce the same ineffective investigations that we have all seen before.
Would you like to learn more about advanced root cause analysis that will help your investigators learn to go beyond their current investigative methods and beyond their current knowledge to discover the real root causes of equipment reliability and human performance related incidents? These are techniques that have been proven to be effective by leading companies around the world.
Yes? Then see: http://www.taproot.com/products-services/about-taproot
And choose one of our upcoming public TapRooT® Courses to learn more about the TapRooT® Root Cause Analysis System. See:
After you’ve concluded a TapRooT® investigation, preparing your investigation results for management doesn’t have to be a chore. If you have TapRooT® software, you can avoid creating a Powerpoint completely! Learn how here.
If you prefer to add content to a PowerPoint, the TapRooT® tools that helped you complete your investigation will also help you create a presentation that gets their attention. Here is a simple guideline of what content to add from your TapRooT® investigation:
- After your introduction slide, clearly and simply state the incident and the determined results in two to three sentences.
- On the next slide, present a small section of your SnapCharT® that explains the incident. For most incidents, it will include four to six Events (Squares) leading up to the incident, as well as the the incident (Circle), and one or two Events that occurred after the Incident. Only present the first line of the SnapCharT® (the Events) on this slide.
- Then add slides with visuals. You have already documented evidence through photographs and videos and maybe even sketched arrangement/placement in Steps 1 and 2 of the TapRooT® 7-Step Major Investigation Process. You can use these items as Powerpoint visuals. But how many should you use? Use the visuals that most clearly support your results – just a few will suffice depending on the complexity of the incident.
- Then present slides that contain each section of your SnapCharT® that includes a Causal Factor – one Causal Factor section per slide. Include Events and Conditions this time. Write the Root Cause next to each Causal Factor determined. Do not present the Root Cause Tree. Why? Because then you are providing a pick-list for management to analyze and they have not put in the hours analyzing the SnapCharT® and finding supporting evidence.
- Finally, create a slide that presents your Corrective Actions in an easy-to-read column or table format. For example, list the Root Cause in Column 1, the Corrective Action in Column 2 and who will implement the Corrective Action (and the deadline for implementation) in Column 3.
To practice preparing and presenting results to management, sign up for our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training. You can even bring a real incident from your facility!
Our 2016 Global TapRooT® Summit was a great success this year! Our attendees helped one another by sharing some of their best practices. Brent Cothran describes how his company trains all new employees on the TapRooT® process.
(Click post title if video is not displaying.)
Our 2016 Global TapRooT® Summit was a great success this year! Our attendees helped one another by sharing some of their best practices. Watch Randy Karasti describe how adding a refresher at the beginning of the second day of training has helped their organization.
(Click post title if video is not displaying.)
Our 2016 Global TapRooT® Summit was a great success this year! Our attendees helped one another by sharing some of their best practices. Larry Perkinson shares how his company teaches a four day TapRooT® course that includes a day dedicated to exams. What a great idea!
(Click post title if video is not displaying.)
Our 2016 Global TapRooT® Summit was a great success this year! Our attendees helped one another by sharing some of their best practices. Here Steven Sandlin discusses his best practice of defining the focus. What is the minimum threshold that drives an investigation?
(Click post title if video is not displaying.)
Happy Wednesday and welcome to this week’s Root Cause Analysis Tip.
The topic this week is the concept of “Defense in Depth.” You may have also heard terms such as Barrier Analysis or LOPA (layer of protection analysis). In TapRooT®, we use the term Safeguards.
Take a look at this diagram (courtesy of Mark Paradies, the creator of TapRooT®):
What the diagram depicts is an incident where several layers of protection have been breached. You may have also heard of Reason’s “Swiss Cheese Model.” In these models we can see that we only have incidents when all layers are breached. So the amount of layers and strength of those layers determine if (and how often) we have incidents. It is also why sometimes things go wrong but we do not have an incident; because one or more layers worked.
So our goal in developing processes is to make sure we have enough layers and that the layers are functioning the way we want. Remember that every Safeguard has a hole in it, it is not infallible. So we want to make the holes as small as possible.
The same applies to corrective actions. Do we need new layers? How can we strengthen existing layers?
The concept is easy. What is difficult is determining just how much is enough.
Risk really is the main driver of that in my view, but business realities come into play as well. The easy ones are the ones on either side of the spectrum. For example, something is fairly difficult but low risk – probably all you need is a procedure and some training (we refer to these as Quasi-Safeguards).
If something is difficult AND high risk, we need a lot of layers, and hopefully many of them are engineering controls.
The hard ones are the ones in the middle; a process is very easy and there is very little chance of a problem… BUT, the risk is very high – in this case determining what you need can be very difficult.
In my November column, I will talk about the strength of Safeguards.
In closing, I urge you to think about Defense in Depth when developing processes. Audit them to make sure the layers are functioning. And if you do have an incident think about Safeguards and Defense in Depth when developing your corrective actions.
Have you been to our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training? Learn more about advanced techniques like Safeguards Analysis, Change Analysis, Critical Human Action Profile (CHAP) and Cognitive Interviewing.
Thanks for visiting the blog, and enjoy your week.
Our 2016 Global TapRooT® Summit was a great success this year! Our attendees helped one another by sharing some of their best practices. Watch Matt Deluhery discuss his best practice of including positives found during an investigation. These include noting safeguards that worked as well as individuals that stepped up during the recovery process.
(Click post title if video is not displaying.)
TapRooT® Users … What do you do when you think there may be a problem with a procedure that contributed to a Causal Factor that led to an Incident?
Here’s a tip from the soon to be published book: TapRooT® Root Cause Analysis for Major Investigations.
To investigate problems in the Procedures Basic Cause Category:
- Get an unused copy of the procedure.
- Get the completed, signed-off or checked-off procedure (if sign-off/check-off is required).
- Get any reference material/documentation.
- Was procedure used?
- Was it signed-off properly?
- Verify technical accuracy of the procedure (table-top review).
- Verify usability of the procedure by performing a field walk-through. (Consider performing a Critical Human Action Profile, Appendix F, and reviewing potential human factors problems at the same time.)
- If problems are found, consider looking for generic causes in the procedure writing and review system.
That’s the start of the guidance provided in the book that will be published in November. Watch for our notice about the release and get your copy for guidance investigating all of the Basic Cause Categories on the back side of the TapRooT® Root Cause Tree®.
My favorite procedure related story was and investigation where the team doing the investigation said that the person who was injured was using a procedure. I asked to see it. They said:
“You want to see the procedure?“
I said “Yes.”
They sent someone off to get it.
They came back with a brown paper grocery bag.
They handed it to me.
I said, “What’s this?”
They said, “the procedure.”
I looked in the bag. There was nothing inside.
They said, “No look on the outside of the bag.”
There were hand written notes on the outside of the bag. Mainly equipment part numbers. That was …
ALWAYS ask for a procedure when someone says that a procedure was used. You might get a good laugh too!