Category: Root Causes

What’s Wrong with Pharmaceutical Root Cause Analysis?

August 8th, 2018 by

Pharma

I was forwarded a copy of an interesting letter about American and Canadian Standards Boards with certifying bodies rejecting pharmaceutical quality incident reports because of poor root cause analysis. It stated that 90% of the rejections of reports were due to three types of root causes that were unacceptable (and I quote):

  1. Employee Error / Human Error / Operator Error OR anyone else who made an error is not an acceptable root cause – Was the training ineffective?  Was the procedure too vague?
  2. Misunderstood the requirement / Did not know it was a requirement / Our consultant told us this was ok OR any other misunderstandings is not an acceptable root cause.  Was the training effective?
  3. We had a layoff / Mona was on maternity leave / we moved locations / we scaled back production / we are still closing out Wayne’s 40 deviations from the last audit OR most other employee or business conditions are not acceptable root causes  They are DIRECT CAUSES.

The letter proposed four rules to follow with all future submissions:

  1. RULE #1:  The root cause can not be a re-statement of the deviation.  Example:  Deviation – Company XYZ did not document Preventive Actions as required by procedure.  Root Cause – We did not document Preventive Actions as required by the procedure.
  2. RULE #2:  There can not be an obvious “Why” that can be easily answered to the provided root cause – in this case they have not gone deep enough.  Example: Root Cause – The purchasing coordinator made a mistake and did not check to see if the supplier was approved.  Obvious “WHY” Was the training effective?  Did the procedure provide enough detail in this area?
  3. RULE #3:  The root cause can not be a direct cause.  Example:  Deviation – There were a number of internal audits scheduled for 2008 that were not completed.  Root Cause – We had a layoff and we did not have enough Internal Auditors to conduct the audits.
  4. RULE #4:  The root cause is a brief description of the cause of the problem.  We do not want any long stories regarding direct causes or what they are doing well even though this happened or who said what.  This is un-necessary detail and only adds confusion.

Wow! I would have thought this guidance would not be necessary. Are responses to quality incidents really this poor? Or is this letter a fake?

No wonder TapRooT® Users have no problem getting approvals for their root cause analysis. None of these problems would happen with any investigation using TapRooT®.

Why would TapRooT® Users never stop at the three causes listed above? Because they would understand that some are Causal Factors (the start of the root cause analysis) and they would have guidance provided by the Root Cause Tree® Diagram to help them find the real, fixable root causes of human performance and equipment failure related problems. This includes analyzing things like “internal audits not completed”; “human error”; and “misunderstood requirements.”

In addition, the TapRooT® Software helps investigators develop concise custom reports that only includes the details needed to understand what happened, how it happened, the root causes, and the effective corrective actions needed to prevent recurrence.

If you are in the pharmaceutical industry and you want to stop having problems with root cause analysis and want to start having effective investigations, root cause analysis, and fixes for problems, attend our TapRooT® Training and learn how simple advanced root cause analysis is.

Remembering An Accident: Sayano-Shushenskaya Hydroelectric Dam

August 2nd, 2018 by

One of the world’s largest hydroelectric plants, Sayano-Shushenskaya Hydroelectric Dam, suffered a catastrophic failure On August 17, 2009, that lead to the death of 75 people, and the pollution of the Yenisei River with 40 tons of oil spilling into it. So how did a major incident like this happen?

On the day of the accident the dam was undergoing major repairs and upgrades. Nine of the ten turbines were operating at full capacity, even the troublesome  #2 turbine. This turbine had previously been offline because of persistent vibrations and maintenance issues, but it was brought back online the previous night. A fire at the Bratsk Power Station caused a drop in electricity production and the decision was made to run Turbine #2 to help with the electrical shortage.

Just before 8:13 am large vibrations were felt by a technician worker on the roof, and according to his recount of the the incident the vibrations gradually grew into a load raw. Shortly after two massive explosion occurred and turbine #2 shoot through the floor 50 feet into the air, and then it came crashing back down. The water that was spinning the turbine was now gushing out at a rate of 67,600 gallons a second. The gushing water produced massive amounts of pressure that ripped the room apart leading to the roofs collapse.

Eventually the gushing water flooded the lower levels and submerged the other turbines. Unfortunately, the plant’s automatic safety system failed to turn off turbines #7 and #9, which were operating at full capacity. This triggered short circuits that left the plant in total darkness adding to the confusion and mayhem.

Several employees struggled to manually close the pen-stock intake gates, and finally succeed at 9:30 am putting an end to the disastrous incident. Because of communication failures and system failures 75 people lost their lives, many were injured, and 40 tons of oil polluted the Yenisei River. Restoring the damage caused by the explosion took years and it cost US$89.3 million to complete.

(Before & After Photo)

To learn more about the Sayano-Shushenskaya Hydroelectric Dam incident click here.

 

Major disasters are often wake-up calls for how important it is to ensure that they never happen again.

TapRooT® Root Cause Analysis is taught globally to help industries avoid them. Our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training offers advanced tools and techniques to find and fix root causes re-actively and help identify precursors that could lead to major problems.

To learn more about our courses and their locations click on the links below.
5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training
2-Day TapRooT® Root Cause Analysis Essentials Training

Management System

July 11th, 2018 by

Screen Shot 2018 05 24 at 10 02 52 PM

Back in 1985, my boss suggested I (Mark Paradies) look at better ways to analyze and trend root causes. I already understood human factors (from training for my master’s degree from the University of Illinois) and equipment reliability (from my experience in the Nuclear Navy). Therefore, I had a good start on the knowledge I needed to develop a system for root cause analysis.

The very first system I developed had a category (today we would call it a Basic Cause Category) of Leadership.

When I showed the system to my boss and he saw the Leadership category, he said:

“You have to take that out.”

He explained that senior management would go nuts if we said there was a leadership issue. We argued for quite a while. I said that management would just have to accept that they, too, could improve. He explained that I had done such a good job NOT having blame categories in the system that I shouldn’t have a blame category for leadership and that’s how the company’s management would view a Leadership category.

Eventually, he convinced me that we could come up with a better name. He wanted to call it “Organizational Factors.” I said that it should be “Management.” He said that was just as bad as Leadership. He wanted to call it “Systems.” I thought that clouded the responsibility for where the changes needed to be made. Finally I suggested “Management System.” It took a while, but he finally agreed.

After several management presentations and several discussions with senior management, we finally got approval for the “Management System” category.

Little did I know that we had invented a term that would be used around the world.

The first place it spread to was INPO (Institute of Nuclear Power Operation). I had interviewed for a job there and they had tried to hire me but I had already taken another job. However, I stayed in contact with Joe Bishop who was in charge of developing the HPES (Human Performance Evaluation System) system for INPO. When they had a version of the system ready, he sent me a copy for review. I commented that they had missed the Management System causes. Sure enough, my work on Management System made it into INPO’s HPES system.

From there, the terminology spread throughout the U.S. nuclear industry and to nuclear plants around the world.

Once I started System Improvements in 1988, the terminology started spreading to other industries. Refining, chemicals, oil exploration and production, and other industries. By the early 1990s, TapRooT® was adopted by industry leaders around the world. And the terminology “Management System” went with it.

Then, I began hearing the term at professional society meetings. People started insisting that to find root causes you needed to find “management system” causes. I thought this was interesting. Where had the term “management system” come from?

I researched the term on the internet and couldn’t find any references prior to the meeting I had with my boss back in 1986. In fact, it looked like the terminology had started to be used in the mid-1990s.

I can’t prove it but I think the terminology came from that meeting with my boss, Rod Satterfield. And that is how the Management System terminology got started.

If you would like to learn more about the Management System, all you need to do is read about it in the TapRooT® Root Cause Tree® Dictionary. You will receive a copy of the dictionary and will learn how to use it in any of our TapRooT® 2-Day or 5-Day Courses.

Winners and Losers in Healthcare’s Shift to Value-Based Payments

July 9th, 2018 by

 

Image result for scale budget

The 2010 Affordable Care Act (ACA) was established to shift payment away from the volume of services provided toward the quality of those services. The ACA directed the Department of Health and Human Services to create a budget neutral payment model. CMS (Centers for Medicare & Medicaid Services) published an ACA fact sheet in 2015 that can be found here.

What does budget neutral mean in this case? A very smart healthcare executive explained it to me.  She said that budget neutral means you will have losers and you will have winners. The Department of Heath and Human Services had to put a payment model in place that takes money away from the losers and gives it to the winners so Medicare doesn’t see an increase in costs but still incentivizes providers to focus on quality. If you don’t have positive outcomes, money will be taken away and given to the providers that do show positive outcomes (the winners). So the difference between winners and losers is the quality of their outcomes. TapRooT® should be the quality improvement process healthcare organizations use to ensure they are on the winning side by improving quality and safety which also protects their revenue and margins. To find out more how your organization can improve your outcomes and protect your reimbursement, please contact me at marcus.miller@taproot.com.

Is Blame Built Into Your Root Cause System?

June 6th, 2018 by

Blame

If you want to stop good root cause analysis, introduce blame into the process.

In recent years, good analysts have fought to eliminate blame from root cause analysis. But there are still some root cause systems that promote blame. They actually build blame into the system.

How can this be? Maybe they just don’t understand how to make a world-class root cause analysis system.

When TapRooT® Root Cause Analysis was new, I often had people ask:

“Where is the place you put ‘the operator was stupid?'”

Today, this question might make you laugh. Back in the day, I spent quite a bit of time explaining that stupidity is not a root cause. If you hire stupid people, send them through your training program, and qualify them, then that is YOUR problem with your training program.

The “stupid people” root cause is a blame-oriented cause. It is not a root cause.

Logo color no lines no text copy

What is a root cause? Here is the TapRooT® System definition:

Root Cause
The absence of best practices
or the failure to apply knowledge
that would have prevented the problem. 

Are there systems with “stupid people” root causes? YES! Try these blame categories:
    • Attitude
    • Attention less than adequate
    • Step was omitted due to mental lapse
    • Individual’s capabilities to perform work less than adequate
    • Improper body positioning
    • Incorrect performance due to a mental lapse
    • Less than adequate motor skills
    • Inadequate size or strength
    • Poor judgment/lack of judgment/misjudgment
    • Reasoning capabilities less than adequate
    • Poor coordination
    • Poor reaction time
    • Emotional overload
    • Lower learning aptitude
    • Memory failure/memory lapse
    • Behavior inadequate
    • Violation by individual
    • Inability to comprehend training
    • Insufficient mental capabilities
    • Poor language ability
    • In the line of fire
    • Inattention to detail
    • Unawareness
    • Mindset

You might laugh at these root causes but they are included in real systems that people are required to use. The “operator is stupid” root cause might fit in the “reasoning capabilities less than adequate,” the “incorrect performance due to mental lapse,” the “poor judgment/lack of judgment,” or the “insufficient mental capabilities” categories.

You may ask:

“Couldn’t a mental lapse be a cause?”

Of course, the answer is yes. Someone could have a mental lapse. But it isn’t a root cause. Why? It doesn’t fit the definition. It isn’t a best practice or a failure to apply knowledge. We are supposed to develop systems that account for human capabilities and limitations. At best, a memory lapse would be part of a a Causal Factor.

To deal with human frailties, we implement best practices to stop simple memory lapses from becoming incidents. In other words, that’s why we have checklists, good human engineering, second checks when needed, and supervision. The root causes listed on the back side of the TapRooT® Root Cause Tree® are linked to human performance best practices that make human performance more reliable so that a simple memory lapse doesn’t become an accident.

What happens when you make a pick list with blame categories like those in the bulleted list above? The categories get overused. It is much easier to blame the operator (they had less than adequate motor skills) than to find out why they moved the controls the wrong way. Its easy to say there was a “behavior issue.” It is difficult to understand why someone behaved the way they did. TapRooT® looks beyond behavior and simple motor skill error to find real root causes.

We have actually tested the use of “blame categories” in a system and shown that including blame categories in an otherwise good system causes investigators to jump to conclusions and select these “easy to pick” blame categories rather than applying the investigative effort required to find real root causes.

You may think that if you don’t have categories, you have sidestepped the problem of blame. WRONG! Blame is built into our psyche. Most cause-and-effect examples I see have some blame built into the analysis.

If you want to successfully find the real, fixable root causes of accidents, precursor incidents, quality issues, equipment failures, cost overruns, or operational failures, don’t start by placing blame or use a root cause system with built-in blame categories. Instead, use advanced root cause analysis – TapRooT®.

The best way to learn about advanced root cause analysis is in a 2-Day TapRooT® Root Cause Analysis Course or a 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Course. See the list of upcoming public courses here: http://www.taproot.com/store/Courses/.

Using TapRooT® to Prevent Medicare Payment Reductions

May 30th, 2018 by

 

Medicare has introduced several programs that attempt to link quality of care to payment. That is a tremendous challenge for healthcare providers that are used to the fee-for-service payment model Medicare traditionally used to reimburse providers. For example, in the fee-for-service payment model, healthcare providers bill Medicare for the number of visits and/or tests they order for the patient. If providers did the work and it’s well documented, they could depend on Medicare payment. Medicare is now shifting that fee-for-service payment model to value-based payment models. Healthcare providers will now be reimbursed for providing high quality services, and incur payment reductions for poor patient outcomes.

A couple of examples of Medicare’s value-based purchasing programs are:

  1. Hospital Readmissions Reduction Program. The Affordable Care Act authorizes Medicare to reduce payments to acute care hospitals with excess readmissions for patients who were treated for conditions such as heart attacks, hip and knee replacements, pneumonia, COPD and/or Coronary Artery Bypass Graft Surgery.
  2. Hospital Value-Based Purchasing. Medicare adjusts a portion of payments to hospitals at the beginning of each fiscal year based on how well they perform on each outcome measure compared to all hospitals or how much they improve their own performance during a prior baseline period.
  3. Hospital-Acquired Condition Reduction Program. The Affordable Care Act also authorized Medicare to reduce payments to hospitals that are in the bottom 25% for certain quality outcomes and hospital acquired conditions.

The healthcare industry now more than ever needs to develop its skill in proactively identifying the root causes of preventable hospital readmissions and the root causes for poor quality measures that affect payment. TapRooT® is a solution. TapRooT® software and training teaches us to identify the real root causes of problems (not just the problems) and build and execute corrective actions that can ensure patients have better experiences and performance outcomes while protecting against payment reductions that hurt the bottom line.

I’ll never forget the mantra of a friend of mine who was an executive at a non-for-profit organization: You can’t help the poor if you are the poor. If healthcare providers don’t transition from the fee-for-service payments to valued-based payment models, it won’t take a root cause analysis to see why they failed.

Learn how to use proactively in our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training. (View schedule of upcoming courses here.)

“It was such a simple mistake!”

May 14th, 2018 by

mistake

 

 

 

 

 

 

 

 

 

When you have a major incident (fire, environmental release, etc.), your investigation will most likely identify several causal factors (CF) that, if they had not occurred, we probably would not have had the incident.  They are often relatively straight forward, and TapRooT® does a great job identifying those CFs and subsequent root causes.

Sometimes, the simplest problems can be the most frustrating to analyze and fix.  We think to ourselves, “How could the employee have made such a simple mistake?  He just needs to be more careful!”  Luckily, TapRooT® can help even with these “simple” mistakes.

Let’s look at an example.  Let’s say you are out on a ship at sea.  The vessel takes a bit of a roll, and a door goes shut on one of your employees.  His finger is caught in the door as it shuts, causing an injury.  Simple problem, right?  Maybe the employee should just be more aware of where he is putting his hands!  We will probably need more effective fixes if we really want to prevent this in the future.

How can we use TapRooT® to figure this out?  First of all, it is important to fully document the accident using a SnapCharT®.  Don’t skip this just because you think that the problem is simple.  The SnapCharT® forces you to ask good questions and makes sure you aren’t missing anything.  The simple problem may have aspects that you would have missed without fully using this technique.  In this example, maybe you find that this door is different than other doors, which have latches to hold them open, or handles to make it easier to open the door.  Imagine that this door might have been a bathroom stall door.  It would probably be set up differently than doors / hatches in other parts of the ship.

So, what are your Causal Factors?  First, I probably would not consider the sudden movement of the ship as a CF.  Remember, the definition of a CF states that it is a mistake or an error that directly leads to the incident. In this case, I think that it is expected that a ship will pitch or roll while underway; therefore, this would not be a CF. It is just a fact. This would be similar to the case where, in Alaska, someone slipped on a snow-covered sidewalk. I would not list that “it was snowing” as a CF.  This is an expected event in Alaska. It would not be under Natural Disaster / Sabotage, either, since snow is something I should be able to reasonably protect against by design.

In this case, I would consider the pitch / roll of the vessel as a normal occurrence.  There is really nothing wrong with the vessel rolling. The only time this would be a problem is if we made some mistake that caused an excessive roll of the vessel, causing the door to unexpectedly slam shut in spite of our normal precautions. If that were the case, I might consider the rolling of the ship to be a CF.  That isn’t the case in this example.

You would probably want to look at 2 other items that come to mind:

1.  Why did the door go shut, in spite of the vessel operating normally?
If we are on a vessel that is expected to move, our doors should probably not be allowed to swing open and shut on their own. There should be latches / shock absorbers / catches that hold the door in position when not being operated. Also, while the door is actually being operated, there should be a mechanism that does not depend on the operator to hold it steady while using the door. I remember on my Navy vessel all of our large hatches had catches and mechanisms that held the doors in place, EXCEPT FOR ONE HEAVY HATCH. We used to tell everyone to “be careful with that hatch, because it could crush you if we take a roll.” We had several injuries to people going through that hatch in rough seas. Looking back on that, telling people to “be careful” was probably not a very strong safeguard.

Depending on what you find here, the root causes for this could possibly be found under Human Engineering, maybe “arrangement/placement”, “tools/instruments NI”, excessive lifting/force”, “controls NI”, etc.

2. Why did the employee have his hand in a place that could cause the door to catch his hand?
We should also take a look to understand why the employee had his hand on the door frame, allowing the door to catch his finger.  I am not advocating, “Tell the employee to be careful and do not put your hand in possible pinch points.” That will not work too well. However, you should take a look and see if we have sufficient ways of holding the door (does it have a conventional door knob? Is it like a conventional toilet stall, with no handle or method of holding the door, except on the edge?). We might also want to check to see if we had a slippery floor, causing the employee to hold on to the edge of the door / frame for support. Lots of possibilities here.

Another suggestion: Whenever I have what I consider a “simple” mistake that I just can’t seem to understand (“How did the worker just fall down the stairs!?”), I find that performing a Critical Human Action Profile (CHAP) can be helpful.  This tool helps me fully understand EXACTLY what was going on when the employee made a very simple yet significant mistake.

TapRooT® works really well when you are trying to understand “simple” mistakes.  It gets you beyond telling the employee to be more careful next time, and allows you to focus on more human performance-based root causes and corrective actions that are much more likely to prevent problems in the future.

Hazards and Targets

May 7th, 2018 by

Most of us probably would not think of this as a on the job Hazard … a giraffe.

Screen Shot 2018 05 07 at 9 40 49 AM

But African filmmaker Carlos Carvalho was killed by one while working in Africa making a film.

Screen Shot 2018 05 07 at 9 42 38 AM

 Do you have unexpected Hazards at work? Giant Asian hornets? Grizzly bears? 

Or are your Hazards much more common. Heat stroke. Slips and falls (gravity). Traffic.

Performing a thorough Safeguard Analysis before starting work and then trying to mitigate any Hazards is a good way to improve safety and reduce injuries. Do your supervisors know how to do a Safeguard Analysis using TapRooT®?

Cyber Attack Root Cause Analysis

May 4th, 2018 by

(if you can’t see the video, here’s a link)

Yes .. It happened right here in Knoxville! A cyber attack on the county computer system on election night!

What is the root cause? The county is having an outside contractor look into it.

Can you use the TapRooT® Root Cause Analysis System to do a root cause analysis of a cyber security attack. Yes! People have been doing it for decades.

Monday Accidents & Lessons Learned: We’re Not Off the Runway Yet

April 16th, 2018 by

NASA’s Aviation Safety Reporting System (ASRS) from time to time shares contemporary experiences to add value to the growth of aviation wisdom, lessons learned, and to spur a freer flow of reported incidents. ASRS receives, processes, and analyzes these voluntarily submitted reports from pilots, air traffic controllers, flight attendants, maintenance personnel, dispatchers, ground personnel, and others regarding actual or potential hazards to safe aviation operations.

We acknowledge that the element of surprise, or the unexpected, can upend even the best flight plan. But, sometimes, what is perceived as an anomaly pales in comparison to a subsequent occurrence. This was the case when an Air Taxi Captain went the second mile to clear his wingtips while taxiing for takeoff. Just as he thought any threat was mitigated, boom! Let’s listen in to his account:

“Taxiing out for the first flight out of ZZZ, weed whacking was taking place on the south side of the taxiway. Watching to make sure my wing cleared two men mowing [around] a taxi light, I looked forward to continue the taxi. An instant later I heard a ‘thump.’ I then pulled off the taxiway onto the inner ramp area and shut down, assuming I’d hit one of the dogs that run around the airport grounds on a regular basis. I was shocked to find a man, face down, on the side of the taxiway. His coworkers surrounded him and helped him to his feet. He was standing erect and steady. He knew his name and the date. Apparently [he was] not injured badly. I attended to my two revenue passengers and returned the aircraft to the main ramp. I secured the aircraft and called [the Operations Center]. An ambulance was summoned for the injured worker. Our ramp agent was a non-revenue passenger on the flight and took pictures of the scene. He stated that none of the workers was wearing a high visibility vest, which I also observed. They seldom have in the past.

“This has been a recurring problem at ZZZ since I first came here. The operation is never [published in the] NOTAMs [for] an uncontrolled airfield. The pilots just have to see and avoid people and animals at all times. I don’t think the person that collided with my wingtip was one of the men I was watching. I think he must have been stooped down in the grass. The only option to [improve the] safety of the situation would be to stop completely until, hopefully, the workers moved well clear of the taxiway. This is one of…many operational deficiencies that we, the pilots, have to deal with at ZZZ on a daily basis.”

We invite you to use the TapRooT® System to find and fix problems. Attend one of our courses. We offer a basic 2-Day Course and an advanced 5-Day Course. You may also contact us about having a course at your site.

How many investigations are enough?

April 16th, 2018 by

 

I’d like you to think about this scenario at work.  You’ve just sent your team to Defensive Driving School, and made sure they were trained and practiced on good driving skills.  They were trained on how to respond when the vehicle is sliding, safe following distances, how to respond to inclement weather conditions, etc.

Now that they’re back at work, how many managers would tell their recently-trained employees, “I’m glad we’ve provided you with additional skills to keep yourself safe on those dangerous roads.  Now, I only want you to apply that training when you’re in bad weather conditions.  On sunny days, please don’t worry about it.”  Would you expect them to ONLY use those skills when the roads are snow-covered?  Or ONLY at rush hour?  I think we would all agree that this would be a pretty odd thing to tell your team!

Yet, that’s what I often hear!

I teach TapRooT® courses all over the world. We normally start off the class by asking the students why they’re at the course and what they are expecting to get from the class. I often hear something that goes like this:

“I’m here to get a more structured and accurate root cause analysis process that is easy for my staff to use and gets repeatable results.  I don’t expect to use TapRooT® very often because we don’t have that many incidents,  but when we do, we want to be using a great process.”

Now, don’t get me wrong, I appreciate the sentiment (we don’t expect to have many serious incidents at our company), and we can definitely meet all of the other criteria.  However, it does get a little frustrating to hear that some companies are going to reserve using this fantastic product to only a few incidents each year.  Doesn’t that seem to be a waste of terrific training?  Why would we only want our employees to use their training on the big stuff, but not worry about using that same great training on the smaller stuff?

There are a couple of reasons that I can think of that we have this misconception on when to use TapRooT®:

  • Some managers honestly believe that they don’t have many incidents.  Trust me, they are not looking very hard! Our people (including ourselves) are making mistakes every day.  Wouldn’t it be nice if we went out there, found those small mistakes, and applied TapRooT® to find solid root causes and corrective actions to fix those small issues before they became large incidents?
  • Some people think that it takes too long to do a good RCA.  Instead, they spend time using an inferior investigation technique on smaller problems that doesn’t fix anything anyway.  If you’re going to take time to perform some type of RCA, why waste any time at all on a system that gives you poor results?
  • Some people don’t realize that all training is perishable.  Remember those defensive driving skills?  If you never practice them, do you ever get good at them?

I recognize that you can’t do an RCA on every paper cut that occurs at your facility.  Nobody has the resources for that.  So there must be some level of “incident” at which makes sense to perform a good analysis.  So, how do we figure out this trip point?

Here are some guidelines and tips you can follow to help you figure out what level of problem should be investigated using TapRooT®:

  • First of all, we highly recommend that your investigators perform one TapRooT® investigation at least every month.  Any longer than that, and your investigation skills start becoming dull.  Think about any skill you’ve learned.  “Use it, or lose it.”
    • Keep in mind that this guideline is for each investigator.  If you have 10 investigators, each one should be involved in using TapRooT® at least monthly.  This doesn’t have to be a full investigation, but they should use some of the tools or be involved in an investigation at least every month.
  • Once you figure out how many investigations you should perform each year to keep your team proficient, you can then figure out what level of problem requires a TapRooT® investigation.  Here is an example.
    • Let’s say you have 3 investigators at your company.  You would want them to perform at least one investigation each month.  That would be about 36 investigations each year.  If you have about 20 first aid cases each year, that sounds like a good level to initiate a TapRooT® investigation.  You would update your company policy to say that any first aid case (or more serious) would require a TapRooT® investigation.
    • You should
      also do the same with other issues at the company.  You might find that your trigger points would be:

      • Any first aid report or above
      • Any reportable environmental release
      • Any equipment damage worth more than $100,000
    • When you add them all up, they might be about 36 investigations each year.  You would adjust these levels to match your minimum number to maintain proficiency.
  • At the end of each year, you should do an evaluation of your investigations.  Did we meet our goals?  Did each investigator only do 4 investigations this year?  Then we wasted some opportunities.  Maybe we need to lower our trip points a bit.  Or maybe we need to do more audits and observations, with a quick root cause analysis of those audit results.  Remember, your goal is to have each investigator use TapRooT® in some capacity at least once each month.
  • Note that all of this should be specified in your company’s investigation policy.  Write it down so that it doesn’t get lost.

Performing TapRooT® investigations only on large problems will give you great results.  However, you are missing the opportunity to fix smaller problems early, before they become major issues.

TapRooT®: It’s not just for major issues anymore!

The Scientific Method In Relation To Root Cause Analysis

April 13th, 2018 by

Did you miss last week’s Facebook Live session with TapRooT® co-founder Mark Paradies and Barb Carr, editorial director at TapRooT®, as they discussed methodologies for root cause analysis in incident investigation? Here’s an opportunity to catch up on the discussion, as Mark and Barb distill the disciplines and factors that historically have been involved in solving complex problems. Also, peruse Mark’s article, Scientific Method and Root Cause Analysis, to supplement this significant learning experience. Feel free to comment or ask questions on our Facebook page.

The Scientific Method In Relation To Root Cause Analysis from TapRooT® Root Cause Analysis on Vimeo

Tune into TapRooT®’s Facebook Live every Wednesday. You’ll be joining TapRooT® professionals as we bring you a workplace-relevant topic. Put a reminder on your calendar or in your phone to watch TapRooT®’s Facebook Live this week for another terrific discussion and for news you can use. We look forward to being with you on Wednesdays!

Here’s the info you need to connect with us for our next Facebook Live:

Where? https://www.facebook.com/RCATapRooT/

When? Wednesday, April 18, 2018

What Time? Noon Eastern | 11:00 a.m. Central | 10:00 a.m. Mountain | 9:00 a.m. Pacific

NOTE: Save the date for 2019 Global TapRooT® Summit: March 11-15, in the Houston, TX area (La Torretta Lake Resort)!

Construction’s Fatal Four – A Better Approach to Prevention

March 26th, 2018 by

In 2016, 21% of fatal injuries in the private sector were in the Construction industry as classified by the Department of Labor. That was 991 people killed in this industry (almost 3 people every day). Among these were the following types of fatality:

Falls – 384 (38.7%)
Struck by Object – 93 (9.4%)
Electrocutions – 82 (8.3%)
Caught-in/between – 72 (7.3%)

Imagine that. Eliminating just these 4 categories of fatalities would have saved over 630 workers in 2016.

Now, I’m not naive enough to think we can suddenly eliminate an entire category of injury or fatality in the U.S. However, I am ABSOLUTELY CERTAIN that, at each of our companies, we can take a close look at these types of issues and make a serious reduction in these rates. Simply telling our workers to “Be careful out there!” or “Follow the procedures and policies we give you” just won’t cut it.

NOTE: In the following discussion, when I’m talking about our workers and teammates, I am talking about ALL of us! We ALL violate policies and procedures every day. Don’t believe me? Take a look at the speedometer on your car on the way home from work tonight and honestly tell me you followed the speed limit all the way home.

As an example, take a look at your last few incident investigations. When there is an incident, one of the questions always asked is, “Did you know that you weren’t supposed to do that?” The answer is almost always, “Yes.” Yet, our teammates did it anyway.

Unfortunately, too many companies stop here. “Worker knew he should not have put his hand into a pinch point. Corrective action, Counseled the employee on the importance of following policy and remaining clear of pinch points.” What a completely useless corrective action! I’m pretty sure that the worker who just lost the end of his finger knows he should not have put his hand into that pinch point. Telling him to pay attention and be more careful next time will probably NOT be very effective.

If we really want to get a handle on these types of injuries, we must adopt a more structured, scientific strategy. I’d propose the following as a simple start:

1. Get out there and look! Almost every accident investigation finds that this has happened before, or that the workers often make this same mistake. If that is true, we should be getting out there and finding these daily mistakes.

2. To correct these mistakes, you must do a solid root cause analysis. Just yelling at our employees will probably not be effective. Remember, they are not bad people; they are just people. This is what people do. They try to do the best job they can, in the most efficient manner, and try to meet management’s expectations. We need to understand what, at the human performance level, allowed these great employees to do things wrong. THAT is what a good root cause analysis can do for you.

3. As in #2, when something bad DOES happen, you must do a solid RCA on those incidents, too. If your corrective actions are always:

  • Write a new policy or procedure
  • Discipline the employee
  • Conduct even MORE training

then your RCA methodology is not digging deep enough.

There is really no reason that we can’t get these types of injuries and fatalities under control. Start by doing a good root cause analysis to understand what really happened, and recognize and acknowledge why your team made mistakes. Only then can we apply effective corrective actions to eliminate those root causes. Let’s work together to keep our team safe.

Root Cause Tip: Luck Versus Being Consistent, Success and Failure Can Come From Both

March 14th, 2018 by

Every best practice can be a strength or a weakness. Even one phrase like “I will ____” can be self-defeating or uplifting. “I will succeed” versus “I will fail.” Both phrases set your compass for success or failure. Okay, so what does philosophy have to do with root cause analysis? Simple….

Practice safe behaviors, build and sustain safe and sustainable processes with good best practices, and success is measured by less injuries, less near-misses, and more efficient processes.

Practice unsafe behaviors, build unsafe but sustainable processes with poor best practices, and success is measured by more injuries, more near-misses, and wasteful business processes. Safety only happens by luck!

Guess what? In many cases, you can still be in compliance during audits but still meet the criteria of “unsafe but sustainable processes with poor best practices . . . measured by more injuries, more near-misses, and wasteful business processes.”

This is why Question Number 14 on the TapRooT® Root Cause Tree® is so important.

Not every Causal Factor/Significant Issue that occurred during an incident or was found during an audit is due to a person just breaking a rule or taking shortcuts. In many cases, the employee was following the rules to the “T” when the action that the employee performed, got him/her hurt or got someone else hurt.

Take time to use the TapRooT® Root Cause Tree®, Root Cause Tree® Dictionary, and Corrective Action Helper® as designed to perform consistently with a successful purpose.

Want to learn more? Attend one of our public TapRooT® Courses or contact us to schedule an onsite course.

Are you planning to attend the 20th Annual IHI/NPSF Patient Safety Congress in Boston?

February 20th, 2018 by


Per Ohstrom and I are looking forward to going to Boston, May 23 – 25, for the 20th Annual IHI/NPSF Patient Safety Congress. If you’re attending, please make a note to stop by the Exhibit Hall and visit us in Booth #316.

Healthcare facilities need multiple levels of analysis to truly identify the causes of patient safety related incidents. We’d love to talk to you about how TapRooT® offers robust data gathering tools and consistent objective root cause analysis to help you build the most effective corrective actions that will address and prevent problems. These tools all working in harmony with your systems will create a much safer environment for patient care.

We hope to see you there!

Root Cause Analysis Tip: Do you perform an incident investigation like you watch the news?

January 31st, 2018 by

If you are like me, you flip channels to see how each news station or news website reports the same issue of interest. Heck, I even look at how different countries discuss the same issue of interest. Take the “Deep Water Horizon Spill of 2010” or was it the “BP Oil Spill of 2010” or was it the “Gulf of Mexico Oil Spill of 2010”? It depends on where you were or what you watched when it was reported. At the end of the day we all often develop Bias Criteria of Trust… often without any true ability to determine which perspective is closer to the truth.

Now there are fancier terms of bias from confirmation bias to hindsight bias, but let’s take a look at some of our news source Bias Criteria of Trust.


So here is the question to stop and ask….. do you do the same thing when you start an investigation, perform root cause analysis or troubleshoot equipment? It is very easy to say YES! We tend to trust interviews and reports using the same criteria above before we actually have the evidence. We also tend to not trust interviews and reports purely because of who and where they came from, without evidence as well!

Knowing this…..

Stop the urge to not trust or to overly trust. Go Out And Look (GOAL) and collect the evidence.

Got your interest? Want to learn more? Feel free to contact me or any of our TapRooT® Instructors at info@taproot.com or call 865.539.2139.

Where Do You Get Ideas To Improve Root Cause Analysis?

4 Signs You Need to Improve Your Investigations

Monday Accidents & Lessons Learned: Sandwiched in a Singapore Chain Collision

December 25th, 2017 by

In Singapore, a car was crushed by two trailers after a passenger bus hit the one behind him, causing a chain collision that left 26 people injured. Read more here.

See TapRooT® Explore How They’re Changing the Way the World Solves Problems

December 14th, 2017 by

We’re pleased to announce that Mark Paradies’  interview on Worldwide Business with kathy ireland® is scheduled to air on Fox Business Network as sponsored programming.

CLICK HERE to view the recent press release.

Please reference the broadcast information below. You may also reference the channel finder below for market by market air times.

Air Date
December 17, 2017
Network and Time
Fox Business Network – 5:30pm EST
Channel Finder
http://www.foxbusiness.com/channel-finder.html

My 20+ Year Relationship with 5-Why’s

December 11th, 2017 by

I first heard of 5-Why’s over 20 years ago when I got my first job in Quality. I had no experience of any kind, I got the job because I worked with the Quality Manager’s wife in another department and she told him I was a good guy. True story…but that’s how things worked back then!

When I was first exposed to the 5-Why concept, it did not really make any sense to me; I could not understand how it actually could work, as it seemed like the only thing it revealed was the obvious. So, if it is obvious, why do I need it? That is a pretty good question from someone who did not know much at the time.

I dived into Quality and got all the certifications, went to all the classes and conferences, and helped my company build an industry leading program from the ground up. A recurring concept in the study and materials I was exposed to was 5-Why. I learned the “correct” way to do it. Now I understood it, but I still never thought it was a good way to find root causes.

I transferred to another division of the company to run their safety program. I did not know how to run a safety program – I did know all the rules, as I had been auditing them for years, but I really did not know how to run the program. But I did know quality, and those concepts helped me instill an improvement mindset in the leaders which we successfully applied to safety.

The first thing I did when I took the job was to look at the safety policies and procedures, and there it was; when you have an incident, “ask Why 5 times” to get your root cause! That was the extent of the guidance. So whatever random thought was your fifth Why would be the root cause on the report! The people using it had absolutely no idea how the concept worked or how to do it. And my review of old reports validated this. Since then I have realized this is a common theme with 5-Why’s; there is a very wide variation in the way it is used. I don’t believe it works particularly well even when used correctly, but it usually isn’t in my experience.

Since retiring from my career and coming to work with TapRooT®, I’ve had literally hundreds of conversations with colleagues, clients, and potential clients about 5-Why’s. I used to be somewhat soft when criticizing 5-Why’s and just try to help people understand why TapRooT® gets better results. Recently, I’ve started to take a more militant approach. Why? Because most of the people I talk to already know that 5-Why’s does not work well, but they still use it anyway (easier/cheaper/quicker)!

So it is time to take the gloves off; let’s not dance around this any longer. To quote Mark Paradies:
“5-Why’s is Root Cause Malpractice!”

To those that are still dug in and take offense, I do apologize! I can only share my experience.

For more information, here are some previous blog articles:

What’s Wrong With Cause-and-Effect, 5-Why’s, & Fault Trees

Comparing TapRooT® to Other Root Cause Tools

What’s Fundamentally Wrong with 5-Whys?

Human Factors Issue in USS John S McCain Crash Not Specifically Identified in Navy Report

November 3rd, 2017 by

The report issues by the US Navy had enough details to identify a human factors issue in the steering system of the USS John S McCain. However, the report identified the main issue as a training problem. I think they missed a significant human factors issue in this investigation. The following details explain what I mean.

Here is a quote from the report:

“At 0519, the Commanding Officer noticed the Helmsman (the watchstander steering the ship) having difficulty maintaining course while also adjusting the throttles for speed control. In response, he ordered the watch team to divide the duties of steering and throttles, maintaining course control with the Helmsman while shifting speed control to another watchstander known as the Lee Helm station, who sat directly next to the Helmsman at the panel to control these two functions, known as the Ship’s Control Console. See Figures 3 and 4. This unplanned shift caused confusion in the watch team, and inadvertently led to steering control transferring to the Lee Helm Station without the knowledge of the watch team. The CO had only ordered speed control shifted. Because he did not know that steering had been transferred to the Lee Helm, the Helmsman perceived a loss of steering.”

McCainHelm

“Steering was never physically lost. Rather, it had been shifted to a different control station and watchstanders failed to recognize this configuration. Complicating this, the steering control transfer to the Lee Helm caused the rudder to go amidships (centerline). Since the Helmsman had been steering 1-4 degrees of right rudder to maintain course before the transfer, the amidships rudder deviated the ship’s course to the left.Additionally, when the Helmsman reported loss of steering, the Commanding Officer slowed the ship to 10 knots and eventually to 5 knots, but the Lee Helmsman reduced only the speed of the port shaft as the throttles were not coupled together (ganged). The starboard shaft continued at 20 knots for another 68 seconds before the Lee Helmsman reduced its speed. The combination of the wrong rudder direction, and the two shafts working opposite to one another in this fashion caused an un-commanded turn to the left (port) into the heavily congested traffic area in close proximity to three ships, including the ALNIC. See Figure 5.”

McCainCollision

“Although JOHN S MCCAIN was now on a course to collide with ALNIC, the Commanding Officer and others on the ship’s bridge lost situational awareness. No one on the bridge clearly understood the forces acting on the ship, nor did they understand the ALNIC’s course and speed relative to JOHN S MCCAIN during the confusion.Approximately three minutes after the reported loss of steering, JOHN S MCCAIN regained positive steering control at another control station, known as Aft Steering, and the Lee Helm gained control of both throttles for speed and corrected the mismatch between the port and starboard shafts. These actions were too late, and at approximately 0524 JOHN S MCCAIN crossed in front of ALNIC’s bow and collided. See Figure 6.”

McCainCollision2

Also, from the report:

“Because steering control was in backup manual at the helm station, the offer of control existed at all the other control stations (Lee Helm, Helm forward station, Bridge Command and Control station and Aft Steering Unit). System design is such that any of these stations could have taken control of steering via drop down menu selection and the Lee Helm’s acceptance of the request. If this had occurred, steering control would have been transferred.”

“When taking control of steering, the Aft Steering Helmsman failed to first verify the rudder position on the After Steering Control Console prior to taking control. This error led to an exacerbated turn to port just prior to the collision, as the indicated rudder position was 33 degrees left, vice amidships. As a result, the rudder had a left 33 degrees order at the console at this time, exacerbating the turn to port.”

“Several Sailors on watch during the collision with control over steering were temporarily assigned from USS ANTIETAM (CG 54) with significant differences between the steering control systems of both ships and inadequate training to compensate for these differences.”

“Multiple bridge watchstanders lacked a basic level of knowledge on the steering control system, in particular the transfer of steering and thrust control between stations. Contributing, personnel assigned to ensure these watchstanders were trained had an insufficient level of knowledge to effectively maintain appropriate rigor in the qualification program. The senior most officer responsible for these training standards lacked a general understanding of the procedure for transferring steering control between consoles.”

The Navy report concludes that this problem was related to training. Although training may have been an issue, training was made much more difficult (complex) by a poorly human factored design. The design didn’t consider the user.

In my experience (I was a 1st Lieutenant on a cruiser – the USS Arkansas, CGN-41), Seaman who are Boatswains Mates are the least technically inclined sailors on the ship. These are the people who stand this type of watch. The job of guiding a long heavy ship, turning it, and keeping it on course using a rudder mounted on the stern can be a thing of beauty when an experienced helmsman knows what they are doing. But not everyone standing the watch is that good. Obviously this sailor was having trouble compensating for current (obvious when you see how far he was steering off the ordered track in Figure 6 above).

On the ships that I served aboard (30 years ago), the steering and helm systems appeared quite simple. There was only one console on the bridge to steer from and only one place on the bridge to indicate the ships speed input that was communicated to the throttleman in the engine room. You could shift steering to aft steering, but this was mainly a process of them manually taking over from the bridge. You would then communicate helm orders via sound powered phones.

Also, speed orders could be manually communicated from the lee helm to the throttleman in engineering via sound powered phones.

In the old days, the lee helm was always manned and there would be no “shifting of controls” as occurred in this collision. Instead, if the helmsman was having problems, the Boatswain Mate of the Watch (the supervisor of these watch stations) could step in to provide advice, or, if needed, take over for the less experienced helmsman. In theory, the Boatswain Mate of the Watch was a more experienced helmsman and could be counted on to correct any problem the helmsman had experienced.

However, on these modern cruisers there is an addition order of difficulty. They have made the Navy ships much more like commercial ships that can be steered from various locations. Also, the two jobs of helmsman and lee helmsman can be performed by a single individual. In theory, this can reduce the number of watch standers and perhaps make the steering of the ship easier.

I think the reality is quite different. The computerized controls have reduced the control that a helmsman has and added complexity that can lead to errors. I would like to do a complete human factors review of the system, but I would bet that the steering modes, locations of control, and the controls used to change control locations are not obvious and, thus, contributed to this accident. That is a human factors problem … NOT a training problem.

This is just one specific example of the lack of thorough root cause analysis that I saw in the US Navy report on the collision (that I wrote about yesterday). It shows the need for better US Navy root cause analysis to fix the real system problems.

If you would like to learn a system that includes an expert system to help investigators identify human factors issues, attend one of our 5-Day TapRooT® Advanced Root Cause Analysis Training Courses. See our upcoming public course dates and locations by CLICKING HERE.

Monday Accident & Lesson Learned: Forklift driver jailed after fatal accident

October 23rd, 2017 by

A forklift driver was jailed after two bundle of steel bars fell from his forklift and killed a man. The article alleges that what the driver did “was against safety practices that he was taught during training.” Click here to read the story about the incident on The Straits Times.

USS Fitzgerald & USS John S McCain Collisions: Response to Feedback from a Reader

August 30th, 2017 by

NewImage

Here is an e-mail I received in response to my recent articles about the Navy’s collision root cause analysis:

As a former naval officer (and one who has navigated the infamous Strait of Malacca as Officer of the Deck on a warship bridge twice), I read your post with interest and wanted to respond.  You understandably criticize the Navy for taking disciplinary action early on in the investigation process, but you fail to understand the full scope of the military’s response to such incidents.  Yes, punishment was swift – right or wrong from a civilian perspective, that’s how the military holds its leaders accountable.  And make no mistake: The leadership of USS Fitzgerald is ultimately responsible and accountable for this tragedy.  (Same goes for the most recent collision involving USS John S. McCain, which also led to the ‘firing’ of the Commander of the 7th Fleet – a Vice Admiral nonetheless.)  That’s just how the military is, was, and always will be, because its disciplinary system is rooted in (and necessary for) war fighting.  

But don’t confuse accountability with cause.  No one in the Navy believes that relieving these sailors is the solution to the problem of at-sea collisions and therefore the ONLY cause.  I won’t speculate on causal factors, but I’m confident they will delve into training, seamanship, communications, over-reliance on technology and many other factors that could’ve been at work in these incidents.  It’s inaccurate and premature for anyone outside the investigation team to charge that the Navy’s root cause analysis began and ended with disciplinary actions.  How effective the final corrective actions are in preventing similar tragedies at-sea in the future will be the real measure of how effective their investigation and root cause analysis are, whether they use TapRooT, Apollo (my company uses both) or any other methodology.

I appreciate his feedback but I believe that many may be misunderstanding what I wrote and why I wrote it. Therefore, here is my response to his e-mail:

Thanks for your response. What I am going to say in response may seem pretty harsh but I’m not mad at you. I’m mad at those responsible for not taking action a decade ago to prevent these accidents today.

 

I’m also a previously qualified SWO who has been an OOD in some pretty tight quarters. The real question is … Why haven’t they solved this problem with prior accidents. The root causes of these collisions have existed for years (some might say over a decade or maybe two). Yet the fixes to prior accidents were superficial and DISCIPLINE was the main corrective action. This proves the Navy’s root cause analysis is inadequate in the past and, I fear, just as inadequate today.

 
These two ships weren’t at war and, even if they were, blaming the CO and the OOD almost never causes the real root causes of the issues to get fixed. 
 
I seem pretty worked up about this because I don’t want to see more young sailors needlessly killed so that top brass can make their deployment schedules work while cutting the number of ships (and the manning for the ships) and the budget for training and maintenance. Someone high up has to stand up and say to Congress and the President – enough is enough. This really is the CNO’s job. Making that stand is really supporting our troops. They deserve leadership that will make reasonable deployment and watch schedules and will demand the budget, staffing, and ships to meet our operational requirements.
 
By the way, long ago (and even more recently) I’ve seen the Navy punishment system work. Luckily, I was never on the receiving end (but I could have been if I hadn’t transferred off the ship just months before). And in another case, I know the CO who was punished. In each case, the CO who was there for the collision or the ship damage was punished for things that really weren’t his fault. Why? To protect those above him for poor operational, maintenance, budget, and training issues. Blaming the CO is a convenient way to stop blame from rising to Admirals or Congress and the President.
 
That’s why I doubt there will be a real root cause analysis of these accidents. If there is, it will require immediate reductions in operation tempo until new training programs are implemented, new ships can be built, and manning can be increased to support the new ships (and our current ships). How long will this take? Five to 10 years at best. Of course it has taken over 20 years for the problem to get this bad (it started slowly in the late 80s). President Trump says he wants to rebuild the military – this is his chance to do something about that.
 
Here are some previous blog articles that go back about a decade (when the blog started) about mainly submarine accidents and discipline just to prove this really isn’t a recent phenomenon. It has been coming for a while…. 
 
USS Hartford collision:
 
 
 
 
USS Greeneville collision:
 
 
USS San Francisco hits undersea mountain:
 
 
USS Hampton ORSE Board chemistry cheating scandal:
 
 
I don’t write about every accident or people would think I was writing for the Navy Times, but you get the idea. Note, some links in the posts are missing because of the age of these posts, but it will give you an idea that the problems we face today aren’t new (even if they are worse) and the Navy’s top secret root cause system – discipline those involved – hasn’t worked.
 
Are these problems getting worse because of a lack of previous thorough root cause analysis and corrective actions? Unfortunately, we don’t have the data to see a trend. How many more young men and women need to die before we take effective action – I hope none but a fear it will be many.
 
Thanks again for your comment and Best Regards,
 
Mark Paradies
President, System Improvements, Inc.
The TapRooT® Folks

I’m not against the Navy or the military. I support our troops. I am against the needless loss of life. We need to fix this problem before we have a real naval battle (warfare at sea) and suffer unnecessary losses because of our lack of preparedness. If we can’t sail our ships we will have real problems fighting with them.

NewImage

Interesting Story – Was Quarry Employee Responsible for His Own Death?

August 24th, 2017 by

Jim Whiting, one of our TapRooT® Instructors in Australia, set me this article:

MCG Quarries blames Sean Scovell, 21, for his own death in 2012

NewImage

Read the article. What do you think? Where does self responsibility end and management responsibility start? What would your root cause analysis say?

Is There Just One Root Cause for a Major Accident?

July 26th, 2017 by

NewImage

Some people might say that the Officer of The Deck on the USS Fitzgerald goofed up. He turned in front of a containership and caused an accident.

Wait a second. Major accidents are NEVER that simple. There are almost always multiple things that went wrong. Multiple “Causal Factors” that could be eliminated and … if they were … would have prevented the accident or significantly reduced the accident’s consequences.

The “One Root Cause” assumption gets many investigators in trouble when performing a root cause analysis. They think they can ask “why” five times and find THE ROOT CAUSE.

TapRooT® Investigators never make this “single root cause” mistake. They start by developing a complete sequence of events that led to the accident. They do this by drawing a SnapCharT® (either using yellow stickies or using the TapRooT® Software).

They then use one of several methods to make sure they identify ALL the Causal Factors.

When they have identified the Causal Factors, they aren’t done. They are just getting started.

EACH of the Causal Factors are taken through the TapRooT® Root Cause Tree®, using the Root Cause Tree® Dictionary,  and all the root causes for each Causal Factor are identified.

That’s right. There may be more than one root cause for each Causal Factor. Think of it as there may be more than one best practice to implement to prevent that Causal Factor from happening again.

TapRooT® Investigators go even one step further. They look for Generic Causes.

What is a Generic Cause? The system problem that allowed the root cause to exist.

Here’s a simple example. Let’s say that you find a simple typo in a procedure. That typo cause an error.

Of course, you would fix the typo. But you would also ask …

Why was the typo allowed to exist?

Wasn’t there a proofing process? Why didn’t operators who used the procedure in the past report the problem they spotted (assuming that this is the first time there was an error and the procedure had been used before)?

You might find that there is an ineffective proofing process or that the proofing process isn’t being performed. You might find that operators had previously reported the problem but it had never been fixed.

If you find there is a Generic Cause, you then have to think about all the other procedures that might have similar problems and how to fix the system problem (or problems). Of course, ideas to help you do this are included in the TapRooT® Corrective Action Helper® Guide.

So, in a major accident like the wreck of the USS Fitzgerald, there are probably multiple mistakes that were made (multiple Causal Factors), multiple root causes, some Generic Causes, and lots of corrective actions that could improve performance and stop future collisions.

To learn advanced root cause analysis, attend a public TapRooT® Courses. See the dates and locations here:

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

Or schedule a course at your facility for 10 or more of people. CLICK HERE to get a quote for a course at your site.

Where did you eat last weekend? (or, why do companies continue to not learn from their mistakes?)

July 24th, 2017 by

Happy Monday. I hope everyone had a good weekend and got recharged for the week ahead.

Every few weeks, I get a craving for Mexican food. Maybe a sit-down meal with a combo plate and a Margarita, maybe Tex-Mex or maybe traditional. It’s all good.

Sometimes, though, a simple California Style Burrito does the trick. This weekend was one of those weekends. Let’s see, what are my choices…? Moe’s, Willy’s, Qdoba, Chipotle?

Chipotle? What??!!!

Unfortunately, Chipotle is back in the news. More sick people. Rats falling from the ceiling. Not good.

It seems like we have been here before. I must admit I did not think they would survive last time, but they did. What about this time? In the current world of social media we shall see.

For those of us in safety or quality, the story is all too familiar. The same problem keeps happening. Over and Over…and Over

So why do companies continue to not learn from mistakes? A few possible reasons:

**They don’t care
**They are incompetent
**They don’t get to true root causes when investigating problems
**They write poor corrective actions
**They don’t have the systems in place for good performance or performance improvement

TapRooT® can help with the last three. Please join us at a future course; you can see the schedule and enroll HERE

So, what do you think? Why do companies not learn from their mistakes? Leave comments below.

By the way, my Burrito from Moe’s was great!

Connect with Us

Filter News

Search News

Authors

Angie ComerAngie Comer

Software

Anne RobertsAnne Roberts

Marketing

Barb CarrBarb Carr

Editorial Director

Chris ValleeChris Vallee

Human Factors

Dan VerlindeDan Verlinde

VP, Software

Dave JanneyDave Janney

Safety & Quality

Garrett BoydGarrett Boyd

Technical Support

Ken ReedKen Reed

VP, Equifactor®

Linda UngerLinda Unger

Co-Founder

Mark ParadiesMark Paradies

Creator of TapRooT®

Michelle WishounMichelle Wishoun

Licensing Paralegal

Per OhstromPer Ohstrom

VP, Sales

Shaun BakerShaun Baker

Technical Support

Steve RaycraftSteve Raycraft

Technical Support

Wayne BrownWayne Brown

Technical Support

Success Stories

Reporting of ergonomic illnesses increased by up to 40% in…

Ciba Vision, a Novartis Company

Four years ago I was an incident investigator, an incident reviewer, and an investigation techniques…

Hydro One
Contact Us