Category: Root Cause Analysis Tips

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 Thursday 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 or 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.

 

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.

How to Keep Your Investigators Proficient

April 26th, 2018 by

Why work harder when you can work smarter? Ken and Benna discuss great ideas about keeping your investigation team sharp. It’s easier than you think with a few simple guidelines.

How many precursor incidents did your site investigate last month? How many accidents did you prevent?

April 25th, 2018 by

A precursor incident is an incident that could have been worse. If another Safeguard had failed, if the sequence had been slightly different, or if your luck had been worse, the incident could have been a major accident, a fatality, or a significant injury. These incidents are sometimes called “hipos” (High Potential Incidents) or “potential SIFs” (Significant Injury or Fatality).

I’ve never talked to a senior manager that thought a major accident was acceptable. Most claim they are doing EVERYTHING possible to prevent them. But many senior managers don’t require advanced root cause analysis for precursor incidents. Incidents that didn’t have major consequences get classified as a low consequence event. People ask “Why?” five times and implement ineffective corrective actions. Sometimes these minor consequence (but high potential consequence incidents) don’t even get reported. Management is letting precursor incidents continue to occur until a major accident happens.

Perhaps this is why I have never seen a major accident that didn’t have precursor incidents. That’s right! There were multiple chances to identify what was wrong and fix it BEFORE a major accident.

That’s why I ask the question …

“How many precursor incidents did your site investigate last month?”

If you are doing a good job identifying, investigating, and fixing precursor incidents, you should prevent major accidents.

Sometimes it is hard to tell how many major accidents you prevented. But the lack of major accidents will keep your management out of jail, off the hot seat, and sleeping well at night.

Screen Shot 2018 04 18 at 2 08 58 PMKeep Your Managers Out of These Pictures

That’s why it’s important to make sure that senior management knows about the importance of advanced root cause analysis (TapRooT®) and how it should be applied to precursor incidents to save lives, improve quality, and keep management out of trouble. You will find that the effort required to do a great investigation with effective corrective actions isn’t all that much more work than the poor investigation that doesn’t stop a future major accident.

Want to learn more about using TapRooT® to investigate precursor incidents? Attend one of our 2-Day TapRooT® Root Cause Analysis Courses. Or attend a 5-Day TapRooT® Root Cause Analysis Course Team Leader Course and learn to investigate precursor incidents and major accidents. Also consider training a group of people to investigate precursor incidents at a course at your site. Call us at 865-539-2139 or CLICK HERE to send us a message.

Are you ready for quality root cause analysis of a precursor incident?

April 17th, 2018 by

Many companies use TapRooT® to investigate major accidents. But investigating a major accident is like closing the barn door after the horse has bolted.

What should you be doing? Quality investigations of incidents that could have been major accidents. We call these precursor incidents. They could have been major accidents if something else had gone wrong, another safeguard had failed, or you were “unlucky” that day.

How do you do a quality investigation of a precursor incident? TapRooT® of course! See the Using the Essential TapRooT® Techniques to Investigate Low-to-Medium Risk Incidents book.

NewImage

Or attend one of our TapRooT® Root Cause Analysis Courses.

Evidence Collection: Two things every investigator should know about scene management

April 17th, 2018 by

You may not be part of scene management when an incident occurs at your facility but there are two things every investigator should know:

  1. Hazards that are present in the work area and how to handle them. It’s impossible to anticipate every accident that could happen but we can evaluate hazards that are present at our facilities that could affect employees and the community at large to structure a scene management plan.
  2. Priorities for evidence collection. The opportunity to collect evidence decreases over time. Here are a few things to keep in mind during, and immediately following, scene management.
    • Fragile evidence goes away.
    • Witnesses forget what they saw.
    • Environmental conditions change making it hard to understand why an incident occurred.
    • Clean-up and restart begins; thus, changing the scene from its original state.

Learn more by holding our 1-Day Effective Interviewing & Evidence Collection Training at your facility. It is a standalone course but also fits well with our 2-Day TapRooT® Root Cause Analysis Training. Contact me for details: carr@taproot.com.

 

You’re invited to Facebook Live for Wednesday lunch

April 16th, 2018 by

We invite you to tune into TapRooT®’s Facebook Live every Wednesday. You’ll be joining TapRooT® professionals as we bring you a contemporary, workplace-relevant topic. Put a reminder on your calendar, in your phone, or stick a post-it on your forehead 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 how to connect with us for Wednesday’s 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

If you missed 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, you can catch up on the discussion via the Vimeo below. You may want to 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

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

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

Where to Start When Finding Root Causes

April 11th, 2018 by

I had someone ask me the other day …

”Where do I start when finding root causes?”

To me, the answer was obvious. You need to understand what happened BEFORE you can understand why it happened.

That’s why the TapRooT® System starts by developing a SnapCharT® of what happened.

Here is a simple example.

Someone sprains their ankle while walking to their car in the parking lot.

What is the root cause.

You might think the obvious answer is …

“They didn’t have their eyes on path!”

But you are jumping to conclusions! You don’t know what happened. So start here…

NewImage

You are starting to develop the story of what happened. You keep working on the story until you have clearly defined Causal Factors …

SprainSnapwCF

That’s a lot more information! It isn’t as simple as “eyes on path.”

Now you are ready to start identifying the root causes of each of the four Causal Factors.

So, that’s where you need to start to find root causes!

Scientific Method and Root Cause Analysis

April 4th, 2018 by

Screen Shot 2018 03 26 at 2 15 18 PM

I had someone tell me that the ONLY way to do root cause analysis was to use the scientific method. After all, this is the way that all real science is performed.

Being an engineer (rather than a scientist), I had a problem with this statement. After all, I had done or reviewed hundreds (maybe thousands?) of root cause analyses and I had never used the scientific method. Was I wrong? Is the scientific method really the only or best answer?

First, to answer this question, you have to define the scientific method. And that’s the first problem. Some say the scientific method was invented in the 17th century and was the reason that we progressed beyond the dark ages. Others claim that the terminology “scientific method” is a 20th-century invention. But, no matter when you think the scientific method was invented, there are a great variety of methods that call themselves “the scientific method.” (Google “scientific method” and see how many different models you can find. The one presented above is an example.)

So let’s just say the scientific method that the person was insisting was the ONLY way to perform a root cause analysis required the investigator to develop a hypothesis and then gather evidence to either prove or disprove the hypothesis. That’s commonly part of most methods that call themselves the scientific method.

What’s the problem with this hypothesis testing model? People don’t do it very well. There’s even a scientific term the problem that people have disproving their hypothesis. It’s called CONFIRMATION BIAS. You can Google the term and read for hours. But the short description of the problem is that when people develop a hypothesis that they believe in, they tend to gather evidence to prove what they believe and disregard evidence that is contrary to their hypothesis. This is a natural human tendency – think of it like breathing. You can tell someone not to breath, but they will breath anyway.

What did my friend say about this problem with the scientific method? That it could be overcome by teaching people that they had to disprove all other theories and also look for evidence to disproves their theory.

The second part of this answer is like telling people not to breath. But what about the first part of the solution? Could people develop competing theories and then disprove them to prove that there was only one way the accident could have occurred? Probably not.

The problem with developing all possible theories is that your knowledge is limited. And, of course, how long would it take if you did have unlimited knowledge to develop all possible theories and prove or disprove them?

The biggest problem that accident investigators face is limited knowledge.

We used to take a poll at the start of each root cause analysis class that we taught. We asked:

“How many of you have had any type of formal training
in human factors or why people make human errors?”

The answer was always less than 5%.

Then we asked:

“How many of you have been asked to investigate
incidents that included human errors?”

The answer was always close to 100%.

So how many of these investigators could hypothesize all the potential causes for a human error and how would they prove or disprove them?

That’s one simple reason why the scientific method is not the only way, or even a good way, to investigate incidents and accidents.

Need more persuading? Read these articles on the problems with the scientific method:

The End of Theory: The Data Deluge Makes The Scientific Method Obsolete

The Scientific Method is a Myth

What Flaws Exist Within the Scientific Method?

Is the Scientific Method Seriously Flawed?

What’s Wrong with the Scientific Method?

Problems with “The Scientific Method”

That’s just a small handful of the articles out there.

Let me assume that you didn’t read any of the articles. Therefore, I will provide one convincing example of what’s wrong with the scientific method.

Isaac Newton, one of the world’s greatest mathematicians, developed the universal law of gravity. Supposedly he did this using the scientific method. And it worked on apples and planets. The problem is, when atomic and subatomic matter was discovered, the “law” of gravity didn’t work. There were other forces that governed subatomic interactions.

Enter Albert Einstein and quantum physics. A whole new set of laws (or maybe you called them “theories”) that ruled the universe. These theories were proven by the scientific method. But what are we discovering now? Those theories aren’t “right” either. There are things in the universe that don’t behave the way that quantum physics would predict. Einstein was wrong!

So, if two of the smartest people around – Newton and Einstein – used the scientific method to develop answers that were wrong but that most everyone believed … what chance do you and I have to develop the right answer during our next incident investigation?

Now for the good news.

Being an engineer, I didn’t start with the scientific method when developing the TapRooT® Root Cause Analysis System. Instead, I took an engineering approach. But you don’t have to be an engineer (or a human factors expert) to use it to understand what caused an accident and what you can do to stop a future similar accident from happening.

Being an engineer, I had my fair share of classes in science. Physics, math, and chemistry are all part of an engineer’s basic training. But engineers learn to go beyond science to solve problems (and design things) using models that have limitations. A useful model can be properly applied by an engineer to design a building, an electrical transmission network, a smartphone, or a 747 without understanding the limitations of quantum mechanics.

Also, being an engineer I found that the best college course I ever had that helped me understand accidents wasn’t an engineering course. It was a course on basic human factors. A course that very few engineers take.

By combining the knowledge of high reliability systems that I gained in the Nuclear Navy with my knowledge of engineering and human factors, I developed a model that could be used by people without engineering and human factors training to understand what happened during an incident, how it happened, why it happened, and how it could be prevented from happening again. We have been refining this model (the TapRooT® System) for about thirty years – making it better and more usable – using the feedback from tens of thousands of users around the world. We have seen it applied in a wide variety of industries to effectively solve equipment and human performance issues to improve safety, quality, production, and equipment reliability. These are real world tests with real world success (see the Success Stories at this link).

So, the next time someone tells you that the ONLY way to investigate an incident is the scientific method, just smile and know that they may have been right in the 17th century, but there is a better way to do it today.

If you don’t know how to use the TapRooT® System to solve problems, perhaps you should attend one of our courses. There is a basic 2-Day Course and an advanced 5-Day Course. See the schedule for public courses HERE. Or CONTACT US about having a course at your site.

Active Listening Inventory

March 28th, 2018 by

Are you a good listener? No one is born that way. Listening is a learned skill and practice makes perfect. Read through the following inventory statements and check for areas where you can improve your skills.

1. I listen without interrupting or finishing another’s sentences.
2. I am comfortable with long pauses in conversation.
3. I don’t “tune-out.”
4. I avoid distractions when listening.
5. I respond appropriately when someone is talking to let them know I am listening.
6. I am patient.
7. When someone is speaking, I am listening and not thinking of my next question or comment.
8. I am aware of my non-verbal messages as well as those displayed by others.

Root Cause Analysis Audit Idea

March 22nd, 2018 by

Screen Shot 2018 03 22 at 3 02 19 PM

In the past couple of years has your company had a major accident?

If they did, did you check to see if there were previous smaller incidents that should have been learned from and if the corrective actions should have prevented the major accident?

I don’t think I have ever seen a major accident that didn’t have precursors that could have been learned from to improve performance. The failure to learn and improve is a problem that needs a solution.

In the TapRooT® root cause analysis of a major accident, the failure to fix pervious precursor incidents should get you to the root cause of “corrective action NI” if you failed to implement effective corrective actions from the previous investigations.

If this idea seems like a new idea at your facility, here is something that you might try. Go back to your last major accident. Review your database to look for similar precursor incidents. If there aren’t any, you have identified a problem. You aren’t getting good reporting of minor incidents with potential serious consequences.

If you find previous incidents, it’s time for an audit. Review the investigations to determine why the previous corrective actions weren’t effective. This should produce improvements to your root cause analysis processes, training, reviews, …

Don’t wait for the next big accident to improve your processes. You have all the data that you need to start improvements today!

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.

What does bad root cause analysis cost?

March 7th, 2018 by

NewImage

Have you ever thought about this question?

An obvious answer is $$$BILLIONS.

Let’s look at one example.

The BP Texas City refinery explosion was extensively investigated and the root cause analysis of BP was found to be wanting. But BP didn’t learn. They didn’t implement advanced root cause analysis and apply it across all their business units. They didn’t learn from smaller incidents in the offshore exploration organization. They didn’t prevent the BP Deepwater Horizon accident. What did the Deepwater Horizon accident cost BP? The last estimate I saw was $22 billion. The costs have probably grown since then.

I would argue that ALL major accidents are at least partially caused by bad root cause analysis and not learning from past experience.

EVERY industrial fatality could be prevented if we learned from smaller precursor incidents.

EVERY hospital sentinel event could be prevented (and that’s estimated at 200,000 fatalities per year in the US alone) if hospitals applied advanced root cause analysis and learned from patient safety incidents.

Why don’t companies and managers do better root cause analysis and develop effective fixes? A false sense of saving time and effort. They don’t want to invest in improvement until something really bad happens. They kid themselves that really bad things won’t happen because they haven’t happened yet. They can’t see that investing in the best root cause analysis training is something that leads to excellent performance and saving money.

Yet that is what we’ve proven time and again when clients have adopted advanced root cause analysis and paid attention to their performance improvement efforts.

The cost of the best root cause analysis training and performance improvement efforts are a drop in the bucket compared to any major accident. They are even cheap compared to repeat minor and medium risk incidents.

I’m not promising something for nothing. Excellent performance isn’t free. It takes work to learn from incidents, implement effective fixes, and stop major accidents. Then, when you stop having major accidents, you can be lulled into a false sense of security that causes you to cut back your efforts to achieve excellence.

If you want to learn advanced root cause analysis with a guaranteed training, attend of our upcoming public TapRooT® Root Cause Analysis Training courses.

Here is the course guarantee:

Attend the course. Go back to work and use what you have learned to analyze accidents,
incidents, near-misses, equipment failures, operating issues, or quality problems.
If you don’t find root causes that you previously would have overlooked
and if you and your management don’t agree that the corrective actions that you
recommend are much more effective, just return your course materials/software
and we will refund the entire course fee.

Don’t be “penny wise and pound foolish.” Learn about advanced root cause analysis and apply it to save lives, prevent environmental damage, improve equipment reliability, and achieve operating excellence.

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

In March of 1994, two of our investigators were sent to the TapRooT 5-day Incident Investigator Team…

Fluor Fernald, Inc.

We started using TapRooT® in the mid 1990s after one of our supervisors wanted to instill a more formal process to our investigations…

CONOCO PHILLIPS
Contact Us