Category: Root Cause Analysis Tips

It’s Facebook Live Wednesday! Join TapRooT® at Noon EST

August 15th, 2018 by

Join our Facebook Live session today as TapRooT® professionals Ken Reed and Benna Dortch discuss human factors. As you listen and glean takeaways from this discussion, start making plans to learn even more from the Human Factor Track at the 2019 Global TapRooT® Summit, designed to share best practices and the latest state-of-the-art techniques to improve human performance. That’s only part of what you’ll get through attending the Human Factor Track at the 2019 Summit.

Plan ahead to tune in for next week’s Wednesday with FB Live. Put a reminder on your calendar, in your phone, or a post-it on your forehead to tune in for TapRooT®’s FB Live. Dig in with us as we explore a workplace-relevant topic with takeaways. And, as always, feel free to join the discussion via comments on our Facebook page.

Here’s the scoop for tuning in:

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

When? Today, Wednesday, August 15, 2018

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

Do your own investigation into our courses and discover what TapRooT® can do for you; contact us or call us: 865.539.2139.

Save the date for our upcoming 2019 Global TapRooT® Summit, March 11-15, 2019, in the Houston, Texas, area at La Torretta Lake Resort.

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.

Investigating Even the Smallest Problems using TapRooT®

July 31st, 2018 by

 

Many companies think about using TapRooT® only when something really significant occurs. Things like major environmental releases, or serious injuries, or expensive quality control issues. These are considered Major Investigations in TapRooT®.

Some companies are also using TapRooT® on less complex, lower risk problems. Problems such as a dropped object, a small spill from a container, or a minor first aid case might be investigated using the Simple Investigation process in TapRooT®.

However, what about REALLY simple problems? Does it make sense to perform entire TapRooT® investigations for just a simple problem that you spot on the job site? Actually, TapRooT® is EXCELLENT at helping you quickly find root causes for even small issues, before they become incidents or near misses. Think about the benefits of finding, analyzing, and fixing these tiny problems:

  • They are pretty easy to find
  • They are pretty easy to fix
  • They are pretty inexpensive to fix
  • They have the opportunity to prevent major issues in the future

Chris Vallee and I talked a bit about this on our last TapRooT® Live session.  Take a look here and let us know what you think.

Why Does Blame “Make Sense”?

July 25th, 2018 by

Think about a recent accident …

  • a ship runs aground
  • a refinery has a major fire
  • an oil well has a blowout and explosion
  • a pharmaceutical plant makes a bad batch of drugs and it gets by the QA process and customers are harmed

One thing that you can be sure of in ALL of the accidents above is that:

someone screwed up!

You never have a major accident if all the Safeguards function as designed. And guess what … we depend on human actions, in many cases, as a significant or sometimes as the ONLY Safeguard.

Therefore, when an accident happens, there is usually at least one human action Safeguard that failed.

If you are in a blame oriented organization, the obvious answer is to BLAME the individual (or team) that failed to prevent the accident. If you can find who is to blame and punish them, you can get back to work.

It MAKES SENSE because “if only they had done their job …” the accident would not have happened. Punishing the individual will set an example for everyone else and they will try harder not to make mistakes.

Sure enough, when the same accident doesn’t happen again right away, management believes they fixed the problem with blame and punishment.

I was thinking of this the other day when someone was talking to me about an investigation they had done using TapRooT®. They had recently adopted TapRooT® and, in the past, had frequently blamed people for accidents.

In this case, a worker had made a mistake when starting up a process. The mistake cost the facility over $200,000. The operator thought that she probably was going to be fired. Her apprehension wasn’t reduced when someone told her she was going to be “taprooted.”

She participated in the investigation and was pleasantly surprised. The investigation identified a number of Causal Factors including her “screw up.” But, to her surprise, they didn’t just stop there and blame her. They looked at the reasons for her mistake. They found there were three “root causes” that could be fixed (improvements that could be made) that would stop the mistake from being made in the future.

She came away realizing that anybody doing the same job could have made the same mistake. She saw how the investigation had improved the process to prevent future similar mistakes. She became a true believer in the TapRooT® System.

When you discover the real fixable root causes of human performance related Causal Factors, BLAME DOES NOT MAKE SENSE. In fact, blame is counter productive.

If people see that the outcome of an investigation is usually blame and discipline, it won’t take long until most incidents, if at all possible, become mystery incidents.

What is a mystery incident?

A refinery plant manager told me this story:

Back early in his career, he had been an engineer involved in the construction and startup of a major facility. One day when they were doing testing, the electrical power to some vital equipment was lost and then came back on “by itself.” This caused damage to some of the equipment and a delay in the startup of the plant. An investigation was performed and no reason for the power failure or the reason for the power coming back on could be found. No one admitted to being in the vicinity of the breaker and the breaker was closed when it was checked after the incident.

Thirty years later they held an unofficial reunion of people who had worked on the project. At dinner, people shared funny stories about others and events that had happened. An electrician shared his story about accidentally opening the wrong breaker (they weren’t labeled) and then, when he heard alarms going off, re-shutting the breaker and leaving the area. He said “Well, I’m retired and they can’t punish me for it now.”

That electrician’s actions had been the cause of the incident. The refinery manager telling the story added that the electrician probably would have been fired if he had admitted what he had done at the time. The refinery manager then added that, “It is a good thing that we use TapRooT® and know better than to react to incidents that way. Now we look for and find root causes that improve our processes.”

Are you looking for the root causes of incidents and improving processes?

Or are you still back in the “bad old days” blaming people when a mistake happens?

If you haven’t been to a TapRooT® Course, maybe you should go now and see how to go beyond blame to find the real, fixable root causes of human error.

See our upcoming TapRooT® Courses by clicking on THIS LINK.

Or contact us to get a quote for a course at your site by CLICKING HERE.

And if your management still thinks that blame and punish is a good idea, maybe you should find a way to pass this article along (without being identified and blamed).

It’s Facebook Live Wednesday! Join TapRooT® at Noon EST

July 25th, 2018 by

Join our Facebook Live session today as TapRooT® professional Ken Reed discusses, How to Use TapRooT® to Analyze a Single, Small Problem. As Ken observes, “Sometimes, there is no need to perform an entire investigation on a tiny problem. You can just take a single Causal Factor through the Root Cause Tree®.”

There is a full spectrum of possible uses of TapRooT® in your improvement programs. Use TapRooT® for:

  • Really large, complex, high-risk incidents (Major Investigations)
  • Smaller, less complex problems (Low-to-Medium Risk Incidents)
  • A very simple problem found, for example, during an audit (single Causal Factor)

We look forward to being with you on Wednesdays! Here’s how to connect with us for today’s Facebook Live:

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

When? Today, Wednesday, July 25

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

Do your own investigation into our courses and discover what TapRooT® can do for you; contact us or call us: 865.539.2139.

Save the date for our upcoming 2019 Global TapRooT® Summit, March 11-15, 2019, in the Houston, Texas, area at La Torretta Lake Resort.

What Are SnapCharT®s and Why Are They Important?

July 23rd, 2018 by

TapRooT®’s systematic process for finding the root causes of problems is used around the world to investigate and fix all categories of mission-critical issues, problems, and potential incidents. The first steps of the TapRooT® process are planning the investigation, collecting information, and understanding what happened. The investigator draws a SnapCharT® to understand what happened and to organize the information about what happened. In this Facebook Live session, you will learn more about the value and vital importance of SnapCharT®s from TapRooT® professionals Benna Dortch and Dave Janney.

Watch the session here in Vimeo.

TapRooT® has special tools—such as the Root Cause Tree® and TapRooT® Root Cause Tree Dictionary—to help investigators find root causes of Causal Factors. Our books and training through our custom courses, software and webinars, and TapRooT® professionals will educate, facilitate, and guide you through investigations into the root causes of human performance problems. Let us know how we may help you. Contact or call us: 865.539.2139.

 

The Best Incident Investigation Performance Indicator

July 18th, 2018 by

NewImage

If an incident investigation and the corrective actions are effective, it will prevent, or significantly reduce the likelihood or consequences of, a repeat incident.

If we want to monitor the effectiveness of our incident investigation, root cause analysis, and corrective action processes, probably the best performance indicator is monitoring the rate of repeat incidents.

If an incident (or even a Causal Factor) is a repeat, it indicates that there was a problem with the previous investigation. For example:

  • Was the root cause analysis inadequate?
  • Were the corrective actions ineffective?
  • Why didn’t management or peer review catch the problem with the previous investigation?

Of course, the question that is tough to answer is … What is a repeat incident (or Causal Factor).

Judging repeat incidents takes some soul searching. The real question is, should have the previous incident investigation prevented the current incident.

Here are two examples:

  • Should the investigation and corrective actions for the Challenger Space Shuttle accident have prevented the Columbia Space Shuttle accident?
  • Should the BP Texas City fire and explosion accident investigation have prevented the BP Deepwater Horizon accident?

You be the judge.

What is the rate for your facility? Do you have 80% repeats? 10%? 0.1%?

Each repeat incident provides a learning opportunity to improve your incident investigation, root cause analysis, corrective action, and incident review processes. Are you using these opportunities to improve your system?

Welcome Marcus Miller!

July 13th, 2018 by

TapRooT® is growing! We are pleased to welcome Marcus Miller, Vice President of Business Development.

Marcus has hit the ground running, and you may have already read some of his informative healthcare-focused posts on the Root Cause Analysis Blog:

  • Using TapRooT® to Prevent Medicare Payment Reduction (Read post.)
  • QAPI and TapRooT®: The Bridge to Operational Excellence and Quality Care in our Nursing Homes (Read post.)
  • Joint Commission Focuses Surveys to Assess Safety Culture (Read post.)
  • Winners and Losers in Healthcare’s Shift to Value-Based Payments (Read post.)
  • Bias and Blame in Healthcare’s Culture has to Change (Read post.)

We hope you will join us in welcoming him to the TapRooT® team. To learn more about Marcus, click here.

 

 

 

 

Cancel your lunch plans! Join TapRooT® today at noon EST!

July 11th, 2018 by

Join TapRooT® professionals Benna Dortch and Ken Reed today at noon EST for TapRooT®’s Facebook Live discussion.

We look forward to being with you on Wednesdays! Here’s how to connect with us for today’s Facebook Live:

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

When? Today, Wednesday, July 11

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

Recently, on TapRooT®’s Facebook Live, we learned that only through effective listening will you learn to pick up on the “right” questions to ask in your investigations. TapRooT® Instructor Barb Carr gave us a beginning point:”The first question is the only one you need to know going in: ‘Tell me, from start to finish, what you observed the day of the incident.’” Barb also advises that the next step is to “sit back, listen, and identify which follow-up questions need to be asked.”

Since our listening skills develop with practice, everyone can use help becoming better investigators. Use the video and Vimeo below, featuring TapRooT® professionals Benna Dortch and Barb Carr, to review your skills:


Do your own investigation into our courses and discover what TapRooT® can do for you.

If you would like for us to teach a course at your workplace, please reach out here to discuss what we can do for you, or call us at 865.539.2139.

Save the date for our upcoming 2019 Global TapRooT® Summit, March 11-15, 2019, in the Houston, Texas, area at La Torretta Lake Resort.

Ever have trouble with root cause analysis during batch production with impurities?

July 6th, 2018 by

We received the question below in our TapRooT® Root Cause Analysis Users & Friends Group on LinkedIn, please join the discussion with your experiences and best practices.

How would one do a SnapCharT® for intermittent product quality issues that span weeks/months?

The only way to detect the product impurity is to use the product. Even so, the impurity seems random in the same batch or lot, at different weeks or months, with different upstream raw material suppliers, with different personnel. Past root cause analysis was not systematic enough to find the rc. Fixes did not solve.

Investigative Interviewing Series, (Part 3 of 3): Extension Techniques

June 28th, 2018 by

Ever wondered how to get more than one word or one sentence answers from the witnesses you interview? Here’s your answer!

What are extension techniques and why are they so important from TapRooT® Root Cause Analysis on Vimeo.

Practice, Feedback, & Improve (Develop Skills)

June 27th, 2018 by

With any new skill that you learn, you need practice to implant the skill into long term memory. To get better at the skill, you need more practice and feedback (coaching).

The same is true of the skills you learn in a TapRooT® Course. You need to practice your new investigation and root cause analysis skills and get feedback (coaching) on ways to improve what you are doing.

Who will provide you with that feedback? Here are some ideas:

  1. Set up a peer review group. The members of this group should attend the 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training and have experience doing investigations.
  2. Have a senior manager become an expert in root cause analysis and provide feedback on investigations when performing senior manager reviews.
  3. Have experts from System Improvements review your incident investigations as they progress, CONTACT US to find out how to get these reviews scheduled.

If you have only attended the 2-Day TapRooT® Root Cause Analysis Course, consider attending the 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Course. You will get more practice with the essential TapRooT® Techniques and learn the advanced techniques including:

  • Cognitive interviewing techniques
  • Critical Human Action Profile (CHAP)
  • Change Analysis
  • Proactive use of Safeguard Analysis
  • Equifactor® Equipment Troubleshooting

Plus you will discuss human error and ways to improve human performance.

Here is a link to the upcoming public 5-Day TapRooT® Training schedule for courses held around the world:

http://www.taproot.com/store/5-Day-Courses/

For anyone interested in advanced root cause analysis training, CLICK HERE for more information.

Join TapRooT® tomorrow at noon EST for Facebook Live

June 26th, 2018 by

Join us tomorrow when TapRooT® professionals Barb Carr and Benna Dortch discuss the topic, “What are extension techniques and why are they so important?” This is the third part of the investigative interviewing series. In the first installment, Barb discussed a powerful but underutilized technique: building rapport. Last week’s tip presented another powerful interviewing technique: effective listening.

Take a read through Barb’s recent articles for more context: Evidence Collection: Top 3 Tips for Improving your Investigative Interviewing Skills Series and Investigative Interviewing Series, (Part 2 of 3): Effective Listening. As always, please feel free to chime in on the discussion in real time. Or leave a comment and we’ll get back to you.

Here’s how to join in for tomorrow’s Facebook Live:

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

When? Tomorrow, Wednesday, June 27

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

Last week on TapRooT®’s Facebook Live in the Effective Listening session, we learned that only through effective listening will you learn to pick up on the “right” questions to ask. Barb gave us a beginning point:”The first question is the only one you need to know going in: ‘Tell me, from start to finish, what you observed the day of the incident.’” Barb also advises that the next step is to “sit back, listen, and identify which follow-up questions need to be asked.”

Since our listening skills develop with practice, everyone can use help becoming better investigators. Use the video and Vimeo below to review your skills:

Investigative Interviewing Series, (Part 2 of 3): Effective Listening

June 21st, 2018 by

Last week, we started our 3-part investigative interviewing series. In the first installment, I discussed a powerful but underutilized technique: building rapport. This week’s tip presents another powerful interviewing technique: effective listening.

Most interviewers approach interviews with the idea that they need to know the right questions to ask. We challenge you to examine how you can possibly know the right questions to ask going into the interview when you haven’t even heard what the interviewee saw or knows.

Only through effective listening will you be able to know the “right” questions to ask. The first question is the only one you need to know going in: “Tell me, from start to finish, what you observed the day of the incident.”

Then, sit back, listen and identify which follow-up questions need to be asked.

How are your effective listening skills? No one is born with them, but you can develop them with practice. Take our listening inventory quiz below and become a better investigative interviewer.

Watch here via video.

So, how do you encourage interviewees to keep talking and give you the whole story? Join us next Wednesday as we discuss extension techniques.

The History of the Definition of a Root Cause

June 20th, 2018 by

 

When I started digging into problem-solving back in 1985, people used the term “root cause” but I couldn’t find a definition for the term. I knew some pretty knowledgable people so I asked them for their definition. They explained what they called a root cause but I found significant variation between these experts’ definitions.

Therefore, David Busch and I (Mark Paradies) started doing research to develop a definition for a root cause. And this is the definition we created back in late 1985 or early 1986:

ROOT CAUSE

The most basic cause(s) that can reasonably be identified
and that management has control to fix.

As TapRooT® was being developed by Mark Paradies and Linda Unger in the early 1990’s, we added to this early definition and the definition was “improved” to:

ROOT CAUSE

A root cause is
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.

That definition was starting to be a mouthful.

Some have added our terminology “management system” into the definition to show that the most basic cause must be a management system cause. We never really thought that was necessary.

By 2005, Linda Unger and Mark Paradies realized that the definition that they had developed for a root cause made an incident investigation look negative. We were looking for causes of problems. People would get into arguments about “management’s ability to fix a problem” when what we really meant was that the problem was fixable. We needed a better definition that was focused on improvement. Therefore, in 2006, we published this version of a definition of a root cause:

ROOT CAUSE

A Root Cause is
the absence of a best practice
or the failure to apply knowledge
that would have prevented the problem.

What is the difference between our old (and some would say industry standard) definition and our 2006 definition?

The new definition focuses more on the positive. We are searching for best practices and knowledge to prevent problems. We aren’t looking for people to blame or management failures. We are going to find ways to perform work more reliably. This is a focus on improvement.

One more note … The new definition is rather absolute. The words “would have prevented” should probably also include the phrase “or significantly reduced the likelihood of” because, in real life, it is probably impossible to guarantee that a problem will be prevented from EVER happening again. But we have’t modified the definition because we wanted the emphasis to remain as definite as possible even though we realize that a 100% guarantee probably is NOT possible.

So, now when you see the definition of a root cause and it looks very similar to the first two definitions, you will know who the original authors were and where the ideas came from.

You will also know that there is a more advanced definition that focuses on improvement.

TapRooT® Users have always been a step (or maybe many steps) ahead of other problem solvers. Even when it comes to the definition of a root cause.

Want to learn more about the TapRooT® Root Cause Analysis System? Attend one of our courses:

http://www.taproot.com/courses

TapRooT® Users – Use It ALL

June 13th, 2018 by

NewImage

I had an interesting question from a TapRooT® user the other day.

“When will you be adding something to TapRooT® to deal with human performance issues?”

I had to stop and think. Of course, our whole design effort was to make TapRooT® the world’s best system for analyzing and fixing problems due to human error. But I realized that we had made the use of TapRooT® so transparent that this user, and probably others, didn’t know what they had.

They might not know that TapRooT® can them help fix:

  • human errors
  • human performance issues
  • company culture problems
  • behavior issues
  • management system failures
  • simple incidents
  • complex accidents
  • audit findings

TapRooT® can be used reactively (after an accident) or proactively (before a major accident). The application of TapRooT® is really flexible.

We’ve made this flexibility and applicability completely transparent. You don’t have to be a human performance expert (a Certified Ergonomist – like I am) to use the system and get great results.

We’ve made difficult analysis so easy that people don’t know all the power they have.

How can a TapRooT® User learn more about what they have?

  1. Read the blog and the weekly TapRooT® Friends & Experts Newsletter. Sign up for the newsletter HERE.
  2. Join the TapRooT® LinkedIn discussion group HERE.
  3. Attend advanced TapRooT® Training – the 5-Day TapRooT® Advanced Team Leader Training.
  4. Attend the annual Global TapRooT® Summit.
  5. Read TapRooT® Root Cause Analysis Leadership Lessons.

That’s a good start and two of the ideas are free.

Get as much as you can from the tools and processes that you already know – TapRooT®.

And if you have any questions, leave them as a comment here or contact us by CLICKING HERE.

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

Press Release – Sweating the Small Stuff: Why TapRooT® Is Upping Its Game to Precursors

June 4th, 2018 by

System Improvements Inc. is pleased to announce an update to its brand language, action, and service regarding investigative initiatives. TapRooT®’s precursor initiative calls for small investigation at the early recognition – if not the earliest – of a problem or failure, since most incidents have warning signs and events that predate the incident.

To learn more about precursors and what it means click on the link below.

View Press Release

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

Why do we still have major process safety accidents?

May 30th, 2018 by

I had an interesting argument about root cause analysis and process safety. The person I was arguing with thought that 5-Whys was a good technique to use for process safety incidents that had low consequences.

Let me start by saying that MOST process safety incidents have low actual consequences. The reason they need to be prevented is that they are major accident precursors. If one or more additional Safeguards had failed, they would become a major accident. Thus, their potential consequences are high.

From my previous writings (a sample of links below), you know that I consider 5-Whys to be an inferior root cause analysis tool.

If you don’t have time to read the links above, then consider the results you have observed when people use 5-Whys. The results are:

  • Inconsistent (different people get different results when analyzing the same problem)
  • Prone to bias (you get what you look for)
  • Don’t find the root causes of human errors
  • Don’t consistently find management system root causes

And that’s just a start of the list of performance problems.

So why do people say that 5-Whys is a good technique (or a good enough technique)? It usually comes down to their confidence. They are confident in their ability to find the causes of problems without a systematic approach to root cause analysis. They believe they already know the answers to these simple problems and that it is a waste of time to use a more rigorous approach. Thus, their knowledge and a simple (inferior) technique is enough.

Because they have so much confidence in their ability, it is difficult to show them the weaknesses in 5-Whys because their answer is always:

“Of course, any technique can be misused,
but a good 5-Whys wouldn’t have that problem.”

And a good 5-Whys is the one THEY would do.

If you point out problems with one of their root cause analyses using 5-Why, they say you are nitpicking and stop the conversation because you are “overly critical and no technique is perfect.”

Of course, I agree. No technique is perfect. But some are much better than others. And the results show when the techniques are applied.

And that got me thinking …

How many major accidents had precursor incidents
that were investigated using 5-Whys and the corrective
actions were ineffective (didn’t prevent the major accident)?

Next time you have a major accident, look for precursors and check why their root cause analysis and corrective actions didn’t prevent the major accident. Maybe that will convince you that you need to improve your root cause analysis.

If you want to sample advanced root cause analysis, attend a 2-Day or a 5-Day TapRooT® Course.

The 2-Day TapRooT® Root Cause Analysis Course is for people who investigate precursor incidents (low-to-moderate consequences).

The 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Course is for people who investigate precursor incidents (low-to-moderate consequences) AND perform major investigation (fatalities, fires, explosions, large environmental releases, or other costly events).

See the schedule for upcoming public courses that are held around the world HERE. Just click on your continent to see courses near you.

“People are SO Stupid”: Horrible Comments on LinkedIn

May 23rd, 2018 by

 

 

How many people have seen those videos on LinkedIn and Facebook that show people doing really dumb things at work? It seems recently LinkedIn is just full of those types of videos. I’m sure it has something to do with their search algorithms that target those types of safety posts toward me. Still, there are a lot of them.

The videos themselves don’t bother me. They are showing real people doing unsafe things or accidents, which are happening every day in real life. What REALLY bothers me are the comments that people post under each video. Again concentrating on LinkedIn, people are commenting on how dumb people are, or how they wouldn’t put up with that, or “stupid is as stupid does!”

Here are a couple examples I pulled up in about 5 minutes of scrolling through my LinkedIn feed.  Click on the pictures to see the comments that were made with the entries:

 

 

 

 

 

 

 

 

 

 

 

Click on picture to watch Video

 

 

 

 

 

 

 

These comments often fall under several categories.  We can take a look at these comments as groups

“Those people are not following safety guideline xxxx.  I blame operator “A” for  this issue!”

Obviously, someone is not following a good practice.  If they were, we wouldn’t have had the issue, right?  It isn’t particularly helpful to just point out the obvious problem.  We should be asking ourselves, “Why did this person decide that it was OK to do this?”  Humans perform split-second risk assessments all the time, in every task they perform.  What we need to understand is the basis of a person’s risk assessment.  Just pointing out that they performed a poor assessment is too easy.  Getting to the root cause is much more important and useful when developing corrective actions.

“Operators were not paying attention / being careful.”

No kidding.  Humans are NEVER careful for extended periods of time.  People are only careful when reminded, until they’re not.  Watch your partner drive the car.  They are careful much of the time, and then we need to change the radio station, or the cell phone buzzes, etc.

Instead of just noting that people in the video are not being careful, we should note what safeguards were in place (or should have been in place) to account for the human not paying attention.  We should ask what else we could have done in order to help the human do a better job.  Finding the answers to these questions is much more helpful than just blaming the person.

These videos are showing up more and more frequently, and the comments on the videos are showing how easy it is to just blame people instead of doing a human performance-based root cause analysis of the issue.  In almost all cases, we don’t even have enough information in the video to make a sound analysis.  I challenge you to watch these videos and avoid blaming the individual, making the following assumptions:

  1.  The people in the video are not trying to get hurt / break the equipment / make a mistake
  2.  They are NOT stupid.  They are human.
  3.  There are systems that we could put in place that make it harder for the human to make a mistake (or at least make it easier to do it right).

When viewing these videos in this light, it is much more likely that we can learn something constructive from these mistakes, instead of just assigning blame.

Root Cause Tip: Repeat-Back Strengthens Positive Communication

May 17th, 2018 by

Misunderstood verbal communication can lead to a serious incident.

Risk Engineer and HSE expert, Jim Whiting, shared this report with us recently highlighting four incidents where breakdowns in positive communications were factors. In each circumstance, an operator proceeded into shared areas without making positive communication with another operator.

Read: Positive communication failures result in collisions.

Repeat-back (sometimes referred to as 3-way communication) can reinforce positive communication. This technique may be required by policy or procedure and reinforced during training on a task for better compliance.

Repeat-back is used to ensure the information shared during a work process is clear and complete. In the repeat back process, the sender initiates the communication using the receiver’s name, the receiver repeats the information back, and the sender acknowledges the accuracy of the repeat back or repeats the communication if it is not accurate.

There are many reasons why communications are misunderstood. Workers make assumptions about an unclear message based on their experiences or expectations. A sender may choose poor words for communication or deliver messages that are too long to remember. The message may not be delivered by the sender in the receiver’s primary language. A message delivered in the same language but by a worker from a different geographical region may be confusing because the words do not sound the same across regions.

Can you think of other reasons a repeat-back technique can be helpful? Please comment below.

Avoid Big Problems By Paying Attention to the Small Stuff

May 16th, 2018 by

Almost every manager has been told not to micro-manage their direct reports. So the advice above:

Avoid Big Problems By Paying Attention to the Small Stuff

may sound counter-intuitive.

Perhaps this quote from Admiral Rickover, leader of the most successful organization to implement process safety and organizational excellence, might make the concept clearer:

The Devil is in the details, but so is salvation.

When you talk to senior managers who existed through a major accident (the type that gets bad national press and results in a management shakeup), they never saw it coming.

A Senior VP at a utility told me:

It was like I was walking along on a bright sunny day and
the next thing I knew, I was at the bottom of a deep dark hole.

They never saw the accident coming. But they should have. And they should have prevented it. But HOW?

I have never seen a major accident that wasn’t preceded by precursor incidents.

What is a precursor incident?

A precursor incident is an incident that has low to moderate consequences but could have been much worse if …

  • One of more Safeguards had failed
  • It was a bad day (you were unlucky)
  • You decided to cut costs just one more time and eliminated the hero that kept things from getting worse
  • The sequence had changed just a little (the problem occurred on night shift or other timing changed)

These type of incidents happen more often than people like to admit. Thus, they give management the opportunity to learn.

What is the response by most managers? Do they learn? NO. Why? Because the consequences of the little incidents are insignificant. Why waste valuable time, money, and resources investigating small consequence incidents. As one Plant Manager said:

If we investigated  every incident, we would do nothing but investigate incidents.

Therefore, a quick and dirty root cause analysis is performed (think 5-Whys) and some easy corrective actions that really don’t change things that are implemented.

The result? It looks like the problem goes away. Why? Because big accidents usually have multiple Safeguards and they seldom fail all at once. It’s sort of like James Reason’s Swiss Cheese Model…

SwissCheese copy

The holes move around and change size, but they don’t line up all the time. So, if you are lucky, you won’t be there when the accident happens. So, maybe the small incidents repeat but a big accident hasn’t happened (yet).

To prevent the accident, you need to learn from the small precursor incidents and fix the holes in the cheese or add additional Safeguards to prevent the major accidents. The way you do this is by applying advanced root cause analysis to precursor incidents. Learn from the small stuff to avoid the big stuff. To avoid:

  • Fatalities
  • Serious injuries
  • Major environmental releases
  • Serious customer quality complaints
  • Major process upsets and equipment failures
  • Major project cost overruns

Admiral Rickover’s seventh rule (of seven) was:

The organization and members thereof must have the ability
and willingness to learn from mistakes of the past.

And the mistakes he referred to were both major accidents (which didn’t occur in the Nuclear Navy when it came to reactor safety) and precursor incidents.

Are you ready to learn from precursor incidents to avoid major accidents? Then stop trying to take shortcuts to save time and effort when investigating minor incidents (low actual consequences) that could have been worse. Start applying advanced root cause analysis to precursor incidents.

The first thing you will learn is that identifying the correct answer once is a whole lot easier that finding the wrong answer many times.

The second thing you will learn is that when people start finding the real root causes of problems and do real root cause analysis frequently, they get much better at problem solving and performance improves quickly. The effort required is less than doing many poor investigations.

Overall you will learn that the process pay for itself when advanced root cause analysis is applied consistently. Why? Because the “little stuff” that isn’t being fixed is much more costly than you think.

How do you get started?

The fastest way is by sending some folks to the 2-Day TapRooT® Root Cause Analysis Course to learn to investigate precursor incidents.

The 2-Day Course is a great start. But some of your best problem solvers need to learn more. They need the skills necessary to coach others and to investigate significant incidents and major accidents. They need to attend the 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training.

Once you have the process started, you can develop a plan to continually improve your improvement efforts. You organization will become willing to learn. You will prove how valuable these tools are and be willing to become best in class.

Rome wasn’t built in a day but you have to get started to see the progress you need to achieve. Start now and build on success.

Would you like to talk to one of our TapRooT® Experts to get even more ideas for improving your root cause analysis? Contact us by CLICKING HERE.

Root Cause Analysis Tip: Why Did The Robot Stop? (Comparing 5-Why Results with TapRooT® Root Cause Analysis Results)

May 9th, 2018 by

Find the Root Cause

I hear people say that 5-Whys is a good root cause analysis system for “simple” incidents. So, I thought I would show a simple incident that was provided as an example by a very experienced 5-Why user and compare it to the analysis that would be performed using TapRooT®.

Taiichi Ohno, the father of the Toyota Production System and the creator of the 5-Why method of root cause analysis, is the source of the example – a robot failure. He used the example to teach employees the 5-Why technique while he was at Toyota. Here is the example as he described it…

1.    Why did the robot stop?

–    The circuit has overloaded, causing a blown fuse.

2.    Why did the circuit overload?

–    There was insufficient lubrication on the bearings, so they locked up.

3.    Why was there insufficient lubrication on the bearings?

–    The oil pump on the robot is not circulating sufficient oil.

4.    Why is the pump not circulating sufficient oil?

–    The pump intake is clogged with metal shavings.

5.    Why is the intake clogged with metal shavings?

–    Because there is no filter on the pump.

For Mr. Ohno, that was the end of the root cause process: Install a filter and get back to work. But this isn’t even the start of the root cause analysis process in TapRooT®.

Let’s look at this incident using TapRooT® and see how 5-Whys compares to the advanced TapRooT® Root Cause Analysis System.

TapRooT® Root Cause Analysis

TapRooT® is more than a tool. It is a systematic process with embedded tools to help an investigator find and fix the root causes of a problem. It starts with either the TapRooT® 5-Step Process for low-to-medium risk incidents or the the TapRooT® 7-Step Process for major investigations. The 5-Step Process is shown below…

To start investigating the problem, one gathers evidence and draws a SnapCharT® (shown below being drawn by a team in a TapRooT® 2-Day Root Cause Analysis Course).

Notice that the 5-Whys that Mr. Ohno asked in the example above turned out to be mainly the sequence of events leading up to the failure in the  SnapCharT® (shown below).

The SnapCharT® makes the example event easier to understand than the 5-Why example above. Plus, the SnapCharT® goes beyond the 5-Whys by indicating that there was no low oil pressure alarm.

In TapRooT®, if the investigator decides that there is more to learn, the investigator continues to collect evidence (grows the SnapCharT®) to expand his/her understanding of what happened. A good TapRooT® Investigator would have several areas to look at.

First, what happened to the filter? Was it forgotten during maintenance or was it never designed into the system?

Next, where did the metal shavings come from? Metal shavings in a lube oil system are unusual. What was the source?

The new information provides a fairly complete understanding of what happened and is shown on the SnapCharT® below.

Notice that in TapRooT®, we complete the collection of evidence about what caused the metal filings and what caused the filter to be missing. These were significant issues that were left out of the 5-Why analysis. This type of omission is common in 5-Why analyses – even when experts apply 5-Whys. Thus the problem isn’t with the investigator or their training – it is embedded in the 5-Why system.

Causal Factors

Once one understands what happened, the third step is to identify the Causal Factors that, if eliminated, would have stopped the accident from occurring or reduced the seriousness of the incident. A simple technique called Safeguard Analysis is used to do this. The four Causal Factors for the Robot Stops incident were identified as:

  1. Mechanic A uses cloth to cover openings in system.
  2. Mechanic A does not report metal shaving contamination.
  3. Mechanic B does not install oil filter.
  4. Operator does not know oil pressure is low.

Where Mr. Ohno only had one root cause, TapRooT® has already identified four Causal Factors. Each of these Causal Factors could have multiple root causes so TapRooT® is already highlighting one of the weaknesses of 5-Whys: that it usually focuses on a single cause and misses additional causes (and the needed corrective actions for those root causes that aren’t identified).

TapRooT® Root Causes

In fourth step of the TapRooT® 5-Step Process, each Causal Factor is analyzed using the Root Cause Tree® to guide the investigator to the Causal Factor’s root causes. The tree is described in detail in the TapRooT® Book (CLICK HERE for info).

For this example, we won’t show the entire analysis of all four Causal Factors using the Root Cause Tree® and Dictionary. For people who would like to know more about the 15-question Human Performance Troubleshooting Guide and the way the tree is used to help investigators find causes beyond their current knowledge, we recommend  attending a 2-Day or 5-Day TapRooT® Course.

However, we will describe the analysis of the Causal Factor “Operator doesn’t know oil pressure is low.”

This starts out on the tree as a Human Performance Difficulty that leads us to the Human Performance Troubleshooting Guide. When asking the 15 Questions, two questions get a “yes” for this Causal Factor and guide us to the Human Engineering, Procedures, and Training Basic Cause Categories on the back side of the Root Cause Tree®.

Copyright © 2015 by System Improvements, Inc.
Used by permission. Duplication prohibited.

In analyzing these categories, no causes are found in the Procedures or Training Basic Cause Categories. However, two root causes are found to be applicable in the Human Engineering Basic Cause Category (above).

Thus, it was determined that if the operator needed an oil pressure display/alarm (displays NI root cause) to make the detection of a problem possible (errors not detectable root cause). If the display/alarm had been present, then the robot could have been stopped and fixed before damage to the bearings had occurred. Thus, the incident would have been made significantly less severe.

The corrective action for these two root causes would be to install a bearing lube oil pressure indicator and a low bearing lube oil pressure alarm to notify the operator of impending equipment problems before the bearing would lock up.

After analyzing just one Causal Factor using the TapRooT® Root Cause Tree® we have found that even an expert like Taiichi Ohno could miss important root causes when using 5-Whys. But there is more. There are still three more Causal Factors to analyze (and then Generic Causes – an optional technique in the 5-Step Process).

Why would you use a root cause tool with known, proven weaknesses? Why would you risk lives, your corporate reputation, and large sums of money on an inferior approach to problem solving? If something is worth fixing, it is worth fixing it right! Learn and apply TapRooT® Advanced Root Cause Analysis to find the real root causes of problems and effectively fix them. Attend an upcoming course to learn more.

A tip for ensuring accuracy of your investigation findings

May 4th, 2018 by

Gary Gardner shares an idea at the 2018 Global TapRooT Summit.

 

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

An improvement plan was developed and implemented. Elements of the improvement plan included process…

Exelon Nuclear

If you are a TapRooT® User, you may think that the TapRooT® Root Cause Analysis System exists to help people find root causes. But there is more to it than that. TapRooT® exists to: Save lives Prevent injuries Improve product/service quality Improve equipment reliability Make work easier and more productive Stop sentinel events Stop the …

Contact Us