Category: Root Cause Analysis Tips

Users Share Best Practices: Allow Leadership To Be A Champion For Your Investigation

November 30th, 2016 by

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.)

Using TapRooT® Safeguard Analysis to Investigate Biopharmaceutical Defects

November 29th, 2016 by

safeguards

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.

Old Fashioned Definition of Root Cause vs. Modern Definition of Root Cause

November 29th, 2016 by

NewImage

When we first started the development of TapRooT® back in the 1980s, we developed this definition of a root cause:

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:

Root Cause
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.

Users Share Best Practices: Practice on the Previous Investigations

November 23rd, 2016 by

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.)

The Blame Culture Hurts Hospital Root Cause Analysis

November 22nd, 2016 by

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.

Screen Shot 2016 11 22 at 11 09 45 AM

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:

http://www.taproot.com/courses

Five Tips for Writing Better Procedures

November 16th, 2016 by

checklist-1622517_1280A 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:

  1. 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.
  2. Be consistent with terminology. Clarify terminology for those who may not be familiar with it and use the same terminology in each step.
  3. Add visual aids like images, diagrams, or sketches to facilitate understanding of the process.
  4. Organize long procedures into sections.  List less than ten steps per section. People lose focus when presented with a procedure with too many steps.
  5. 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).

Users Share Best Practices: Creating A Review Cell For The Incident

November 16th, 2016 by

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.)

Root Cause Tips – All Safeguards are not created equal… or, why do corrective actions fail?

November 9th, 2016 by

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:

Screen Shot 2016-10-07 at 11.48.42 AM

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.

Starting Your Investigations: The Power of the SnapCharT®

November 7th, 2016 by

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:

Initial SnapCharT®

Initial SnapCharT®

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:

Questions to ask

Questions to ask

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!)

 

OSHA/EPA “Fact Sheet” About Root Cause Analysis & Incident Investigation

November 1st, 2016 by

Screen Shot 2016 11 01 at 1 49 05 PM

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:

http://www.taproot.com/store/Courses/

 

 

Prepare your Investigation Results for Management

October 24th, 2016 by

presentation-36911_1280After 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!

Users Share Best Practices: Understanding and Applying TapRooT®

October 24th, 2016 by

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.)

Users Share Best Practices: Adding a Day Two Refresher

October 21st, 2016 by

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.)

Users Share Best Practices: Running a Four Day Course

October 20th, 2016 by

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.)

Users Share Best Practices: Defining Your Focus

October 18th, 2016 by

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.)

Root Cause Tips – Defense in Depth (layers of protection)

October 12th, 2016 by

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®):

Screen Shot 2016-10-07 at 10.43.31 AM

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.

Users Share Best Practices: Including Positives in Your Report

October 10th, 2016 by

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.)

Root Cause Analysis Tip: Investigating a Procedure Problem

September 28th, 2016 by

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:

  1. Get an unused copy of the procedure.
  2. Get the completed, signed-off or checked-off procedure (if sign-off/check-off is required).
  3. Get any reference material/documentation.
  4. Was procedure used?
  5. Was it signed-off properly?
  6. Verify technical accuracy of the procedure (table-top review).
  7. 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.)
  8. 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 …

The Procedure.

ALWAYS ask for a procedure when someone says that a procedure was used. You might get a good laugh too!

Users Share Best Practices: Adding a Union Rep to an Investigation

September 28th, 2016 by

Our 2016 Global TapRooT® Summit was a great success this year! Our attendees helped one another by sharing some of their best practices. Here is Don Marsh discussing his best practice of adding a union rep to each investigation.

(Click post title if video is not displaying.)

Root Cause Analysis Tip: Going Beyond Root Cause Analysis to Fix Company-Wide Problems

September 15th, 2016 by

All TapRooT® Users have experienced the effectiveness of using the Root Cause Tree® and Dictionary to find the specific root causes of a particular incident. They fix these causes and eliminate (or at least reduce) the chance of identical repeat incidents.

Here is the question …

Can we do more?

The answer is … YES!

In the TapRooT® System, the next step after determining the specific root causes is to identify the Generic root causes.

What is a Generic root cause?

Generic Cause
The systemic cause that allows a root cause to exist.
Fixing the Generic Cause eliminates whole classes of specific root causes.

These are the causes that are present across the organization. Think of it as looking at the big picture.

If you have a problem with a procedure, what in the procedure writing system is allowing the problem to exist?

If you have a training issue, what in the way you develop and provide training or test people for proficiency is causing problems?

Get the idea?

Sometimes using the Corrective Action Helper® Guide can help you identify Generic Causes.

To do this we use this three step process:

For each root cause identified using the Root Cause Tree® Diagram:

  1. Review the “Ideas for Generic Problems” section of the Corrective Action Helper® Guide for the root causes you have identified.
  2. Ask: “Does the same problem exist in more places?”
  3. Ask: “What in the system is causing this Generic Cause to exist?”

Once you identify the systemic cause (or causes), you fix them!

You then need to do a system wide evaluation to correct all the problems that exist from the old system by implementing the changes recommended for the new system.

Once you complete these corrective actions, you have fixed the immediate issues and made sure that you won’t create new issues in the future.

That’s going beyond simple root cause analysis.

 

Using TapRooT® for Simple Investigations

August 9th, 2016 by

Investigation
It is almost a no-brainer to perform a complete, extensive root cause analysis for high-risk, high-consequence incidents. There are many reasons for this:

– Required by regulators or law
– Required by company policy
– Perceived higher return on investment

However, companies often default to less developed (and therefore less accurate) analyses for lower risk, lower consequence problems. For example, almost everyone will perform a TapRooT® investigation when there is a serious injury; this is a high-consequence incident, and preventing it in the future is perceived to have the highest ROI.  But what about a near miss?  Or maybe someone tripped over an air line on the floor, dropping a repair part and damaging it?  Most companies will either not perform any investigation, or they will default to “easy” methods (5-Why’s, etc.).  Why spend any time on these “simple” incidents?  Let’s just do a quick “analysis” and move on?

While I completely understand this thought process, there are some serious flaws in this thinking.

  1.  Low ROI.  While a particular incident may not have caused a large loss, this dos not mean it automatically deserves no attention.  Maybe tripping over the air line only caused $800 in damage this time.  But what about the other issues that have been caused by poor housekeeping in the past?  What if the person had tripped and fallen over the edge of a platform?  Making a quick assumption like this can allow you to miss potentially serious issues when taken together.  Performing a poor analysis will lead to repeats of the problem.
  2. Poor results of “quick” RCA methods.  Keep in mind that a quick method probably means that you did not gather any information.  You are therefore performing an “analysis” without any data to analyze.  If your analysis method takes 5 minutes, you have probably just wasted 5 minutes of your time.  If you’re going to perform an RCA, make sure it gets to useable and consistent answers.
  3. TapRooT® is only for the big stuff.  This thought often frustrates me.  It is true that you will not perform a TapRooT® investigation in 5 minutes.  However, any method that purports to give you magic answers in a few minutes is not being honest.  See #2 above.  However, that does NOT mean that TapRooT® must take days of your time.  For simple investigations, the results of a TapRooT® investigation may be found in just an hour or so.

So, how do we use TapRooT® for lower risk or low consequence problems?  This year, we have modified the TapRooT® methodology to allow you to use the steps of the process that you need to perform a great investigation on simple problems.  This updated process isn’t really new; it just codifies how we’ve taught you to use TapRooT® in the past for these simpler problems.  We make the process more efficient and give you the opportunity to optionally skip some of the steps.

Here is the new process flow for low to medium risk incidents:

Flowchart with no paragraphs
 

There are some important points that I wanted to highlight about this new process flow:

  1. You always start with a SnapCharT®.  There is no way to perform any type of analysis unless you first gather some information.  Again, any other process that advocates performing an analysis on the information you received in a quick phone call is not a real analysis.  The SnapCharT® ensures you have the right information to actually look for root causes.
  2. There is an off-ramp right at the beginning.  Once you’ve gathered information in a SnapCharT®, you can then make an intelligent decision as to whether this problem has the potential to uncover significant problems.  You may find, after building your SnapCharT®, that this really was an extremely low potential problem, with minimal consequences.  You will then stop the analysis at that point, put simple corrective actions in place to fix what you found, and then document the problem for later trends.  That’s it.  While most investigations will continue on with the rest of the process, there are some issues that do not require any further analysis and don’t deserve any further resources.
  3. For most investigations, you will continue by identifying Causal Factors, and run those Causal Factors through the Root Cause Tree®.  No different than before.
  4. For these simpler problems, it probably is not worth the effort of looking for generic causes.  We have made this step optional.  It you feel the problem has the potential to be more widespread, you can continue to look for generic issues, otherwise, go straight to corrective actions.
  5. Low to medium risk incidents probably do not need the resources you would normally expend writing full SMARTER corrective actions.  We encourage you to write corrective actions based on the guidance in the Corrective Action Helper®, but writing fully SMARTER fixes is probably not necessary.

For more serious incidents, we would still use the full 7-Step TapRooT® Process that you are familiar with.  However, for lower risk or lower consequence problems, this abbreviated process flow is much easier to use, allowing you to more quickly work through a TapRooT® investigation.  Why use 5-Why’s and get poor results (as expected) just to “save time,” when you can use the simplified TapRooT® process to get MUCH better answers with less effort than before?

The 2-Day TapRooT® Root Cause Analysis Course not covers this simpler method of performing TapRooT® investigations.  Attendees will still be able to perform investigations on any incident, but we stress this more efficient process flow.

Choose a course and register here!

Is Discipline All That Is Needed?

July 6th, 2016 by

You’ve seen it hundreds of times. Something goes wrong and management starts the witch hunt. WHO is to BLAME?

Is this the best approach to preventing future problems? NO! Not by a long shot. 

We’ve written about the knee-jerk reaction to discipline someone after an accident many times. Here are a few links to some of the better articles:

Let me sum up what we know …

Always do a complete root cause analysis BEFORE you discipline someone for an incident. You will find that most accidents are NOT a result of bad people who lack discipline. Thus, disciplining innocent victims of the systems just leads to uncooperative employees and moral issues.

In the very few cases where discipline is called for after a root cause analysis, you will have the facts to justify the discipline.

For those who need to learn about effective advanced root cause analysis techniques that help you find the real causes of problems, attend out 5-Day TapRooT® Root Cause Analysis Training. See: http://www.taproot.com/courses

 

Healthcare: Can’t See the Forest for the Trees

July 5th, 2016 by

black-forest-1476021_1920

My grandmother (with whom I spent many of my childhood weekends) would say to us grandkids, “You can’t see the forest for the trees!” That usually came right after something bad happened or we did something that was not considered “right” by the adults. I always wondered what that meant, I have thought about it for years and I believe from an adult perspective I finally get it… Granny Lillie, if you can hear this, “I FINALLY GET IT!” (I hear her saying, “It is about time……sheesh.”)

As I have worked with healthcare organizations over the past 20 years working to improve performance and improve their systems we always talked about examining failures and finding the causes. Finding the “Whys” is the step necessary for you to fix issues that existed. Those issues that underlie our systems and turn into incidents, accidents and breed adverse behaviors have to be removed following a problem so that we can prevent reoccurrence. This is preached, taught, and required by all organizations in today’s business world. But why do we wait, why do we have to fail to learn? That question has always concerned me. This is where my grandmother fits in…

When as kids we would go out, make decisions to do things that had adverse outcomes, she would always say to us “you can’t see the forest for the trees” and we would just nod our heads and say “ok” then continue on our merry way. Not only would we not learn from our mistakes but we could not see the mistakes and incidents they happened. The correlation in today’s adult world from an organizational perspective relates to making decisions without considering the consequences. The “Trees” from the statement above is the change you are going to make. If you focus on the “Trees” in front of you and do not consider the future beyond that “the Forest” you are taking unnecessary risk and possibly creating problems. Do you “get it”?

What got me thinking about this today came from an article  I read which dealt with an investigation by the State’s Office of Inspector General at a Louisville, KY hospital. This along with the TJC visit which found many problems at the facility prompted concerns. The investigation was prompted by complaints by staff (that survived the downsizing) regarding health and safety issues due to the decreased staffing. After reading the article I immediately began thinking about our Proactive Flow within the TapRooT® process.

Proactive Flow
We talk about being Proactive in place of reactive and one thing I always mention in my classes is using the TapRooT® process to look at the process before a change or implementation and after that implementation to see where there may be gaps or issues that are identified. This proactive approach may raise questions before you commit to change.

Notice that when we get to step 3 in the Proactive flow we take the observed issues or problems and ask the simple question, “What could result from this?” We would pose this question against our view of the future system. Let’s suppose that they had recognized these future conditions:

  1. A reduction in staffing would create a significantly higher workload for existing staff
  2. Hospital maintained customer/patient throughput with reduced staffing
  3. Using traveling nurses with little or no facility or system related training to supplement staffing levels
  4. Reduced staffing could cause difficulty in maintaining the Quality Control standards due to pressure based on census

We can now take this information and use that “What could result from this?” and we could have had this conclusion:

PSafetySnapCharT-ProActive
Now notice that the Significant Issue identified has a dotted line around it meaning it is an assumption, but the possible outcome that could have been recognized (which later became a reality) could have been taken through the Root Cause Tree® and analyzed before it became a reality. And you would have likely come to several areas on the back of the Root Cause Tree®:

a) Training – No Training – Decided not to Train
b) Management System – Standards, Policies and Administrative Controls NI – Not Strict Enough
c) Work Direction – Preparation – Scheduling NI
d) Work Direction – Selection of Worker – Not Qualified

And there certainly could have been others. At this point you have the ability to re-evaluate the changes you are about to make and ensure that the programs put in place following this down-sizing remove these potential problems. This allows you to evaluate the “Forest” behind those “Trees” and ensure the safety of your future patients and staff while working through the “Forest.” If this one hospital had performed this analysis the outcome and where they are today could have been significantly different.

By using this thought process and by being Proactive we can all create safer systems, create a more effective and acceptable working environment, and protect those around us that depend on us… just as Granny Lillie tried to do for us kids so many years ago. Sometimes the simplest, most practical viewpoint is the best. If you have any questions about the TapRooT® process for Proactive assessments please contact me directly at skompski@taproot.com.

You are just one Causal Factor from your next major Incident. Can you prevent it?

July 5th, 2016 by

comic

Words that I hate to hear when asked to help with an investigation: “I am surprised this incident did not happen earlier!” Rarely have I seen an incident where there is not a history of the same problems occurring.  Think of it like a math equation:

X + Y (A) = The Incident

A company’s issues are just waiting for the right math equation to occur at the right time. What are some of the common factors that populate the equation above?

  • Audit Findings (risk or compliance)
  • Near Misses (or some cases, Near Hits)
  • OSHA Non-Recordable(s)
  • Defects (caught before the defect reached the customer)
  • Project Delays
  • Procurement Issues
  • Behavior Based Safety Entries

This list of variables is infinite and dependent on the industry and service or product that your company provides. Should you be required to perform a full root cause analysis on each and every write-up or issue listed above to prevent an Incident? Not, necessarily.

Instead, I recommend that you start looking at what would be a risk to employees, customers, environment, product/service or future company success if you combined any of your issues in the same timeline or process of transactions (in TapRooT® our timeline is called a SnapCharT®). For example, take the 3 issues listed below that have a higher potential of incident occurrence when combined in the right equation.

Issue 1: Audit finding for outdated procedures found in a laboratory for testing blood samples.

Issue 2: Behavior Based Safety Write-up entered for cracked and faded face shields

Issue 3: Older Blood Analyzer has open equipment work orders for service issues.

Combining the 3 items above could cause a contaminated blood sample, exposure of contaminated blood to the lab worker or a failed test sample to the patient.

If the cautions about your future combination of known issues are not heeded then please do not acted surprised after the future Incident occurs.

Want to learn about causal factors? It’s not too late to sign up for our Advanced Causal Factor Development Course, August 1-2, 2016, San Antonio, Texas.

Can Healthcare Benefit from Procedure Usage?

June 27th, 2016 by

chemotherapy-448578_1280

Don’t think checklists are useful in healthcare? Read on!

I was teaching a class (not in the healthcare arena) and had some interesting discussions around the use of procedures during work. First let’s recap the TapRooT® Definition of a procedure:

A procedure is a written step-by-step description of how a particular task is to be performed that is read and followed during performance of the work by the person performing the work.

A checklist is considered a procedure in our system. For this company there were two perceptions regarding procedures and their uses:

  1. Those are only necessary if there are people who are not knowledgable on the task.
  2. Those procedures always make work more difficult.

Now, I have heard these comments before from folks in the healthcare field when the work procedure is used not for a medical “procedure” but when it is used as a checklist. Many doctors and nurses don’t like having to follow a specific path towards medical treatment. And I agree because each human is different, each course of treatment is different, and every scenario is different that it is more difficult to set procedures for every medical treatment. But can tasks and scenarios benefit from the use of checklists within healthcare?

The following article talks about the use of checklists and examined 10,700 surgical procedures. The results although only showing small decreases did show that the implementation of quality checklists dealing with Surgical Safety reduced the following:

Length of Stay from 10.4 to 9.6 days
30-day Readmission Rates from 14.6 to 14.5%
90-day Death Rates from 2.4 to 2.2%

Small numerical changes equate to large numbers in the overall scheme of healthcare. From a 2010 National Hospital Discharge Survey and the National Center for Health Statistics showing some 51.4 million inpatient surgeries performed, that means that we can reduce the number of readmissions by 51,400 patients, and the 90-day death rate means we lower the number of deaths by 102,800 patients. Now I am not sure if you agree but that is a SIGNIFICANT impact on patient care. Those are numbers that could provide pause for those who don’t think checklists can be used in healthcare!

Now going back to our two objections above, let’s now think about why procedures, when implemented and designed properly, can improve performance.

Those are only necessary if there are people who are not knowledgeable on the task.

Procedures can be built to contain a level of information that can be helpful to both experienced and non-experienced practitioners. The idea that just because you have a lot of experience that you cannot make a mistake is unacceptable today. We are fallible, we are human, so why can’t we accept help? I believe it is perception, see comment 2 above:

Those procedures always make work more difficult.

Perception is reality and if people don’t believe or understand why you implement these checklists and don’t implement them effectively then this is understandable.
Here is what checklists help you do:

  1. Not rely on short-term memory
  2. Become more consistent in an approach to a job
  3. Remind and caution against unsafe behaviors
  4. Document the way work is “expected” to be performed

These four items alone are work an additional 2-3 minutes of time it takes to address and use the checklist, don’t you think?

From the numbers above, and the possible impact on patient care the use of checklists where reasonable is a very simply and effective way to raise the level of performance of your staff and have a very positive impact on patient care. If you would like more information on this or other topics around the TapRooT® system and how it impacts human and equipment performance please feel free to contact me at skompski@taproot.com.

Connect with Us

Filter News

Search News

Authors

Barb PhillipsBarb Phillips

Editorial Director

Chris ValleeChris Vallee

Six Sigma

Dan VerlindeDan Verlinde

Software Development

Dave JanneyDave Janney

Safety & Quality

Gabby MillerGabby Miller

Communications Specialist

Ken ReedKen Reed

Equifactor®

Linda UngerLinda Unger

Vice President

Mark ParadiesMark Paradies

Creator of TapRooT®

Steve RaycraftSteve Raycraft

Technical Support

Success Stories

Our Acrylates Area Oxidation Reactor was experiencing frequent unplanned shutdowns (trips) that…

Rohm & Haas

We initially started using TapRooT® in 2002 in order to improve the quality…

OCEANEERING
Contact Us