Category: Root Cause Analysis Tips

Safeguard Analysis for Finding Causal Factors

November 25th, 2015 by

A Causal Factor is nothing more than a mistake or an equipment failure that, if corrected, could have prevented the incident from happening.

Once you’ve gathered all the information you need for a TapRooT® investigation, you’re ready to start with the actual root cause analysis. However, it would be cumbersome to analyze the whole incident at once (like most systems expect you to do). Therefore, we break our investigation information into logical groups of information, called Causal Factor groups. So the first step here is to find Causal Factors.

Remember, a Causal Factor is nothing more than a mistake or an equipment failure that, if corrected, could have prevented the incident from happening (or at least made it less severe).  So we’re looking for these mistakes or failures on our SnapCharT®.  They often pop right off the page at you, but sometimes you need to look a little harder.  One way to make Causal Factor identification easier is to think of these mistakes as failed or inappropriately applied Safeguards.  Therefore, we can use a Safeguard Analysis to identify our Causal Factors.

There are just a few steps required to do this:

First, identify your Hazards, your Targets, and any Safeguards that were there, or should have been there.

Now, look for:

- an error that allowed a Hazard that shouldn’t have been there, or was larger than it should have been;

- an error that allowed a Safeguard to be missing;

- an error that allowed a Safeguard to fail;

- an error that allowed the Target to get too close to a Hazard; or

- an error that allowed the Incident to become worse after it occurred.

These errors are most likely your Causal Factors.

Let’s look at an example.  It’s actually not a full Incident, but a VERY near miss.  This video is a little scary!


Let’s say we’ve collected all of our evidence, and the following SnapCharT is what we’ve found.  NOTE:  THIS IS NOT A REAL INVESTIGATION!  I’m sure there is a LOT more info that I would normally gather, but let’s use this as an example on how to find Causal Factors.  We’ll assume this is all the information we need here.

Picture1 Picture2

Now, we can identify the Hazards, Targets, and Safeguards:

Hazard Safeguard Target
Moving Train Fence Pedestrians
Pedestrians (they could have stayed off the tracks)

Using the error questions above, we can see that:

- An error allowed the Hazard to be too large (the train was speeding)

- An error allowed the Targets to get too close to the Hazard (the Pedestrians decided to go through the fence, putting them almost in contact with the Hazard)

These 2 errors are our Causal Factors, and would be identified like this:

Picture3 Picture4

We can now move on to our root cause analysis to understand the human performance factors that lead to this nearly tragic Incident.

Causal Factors are an important tool that allow TapRooT® to quickly and accurately identify root causes to Incidents.  Using Safeguard Analysis can make finding Causal Factors much simpler.

Sign up to receive tips like these in your inbox every Tuesday. Email Barb at and ask her to subscribe you to the TapRooT® Friends & Experts eNewsletter – a great resource for refreshing your TapRooT® skills and career development.

Are you doing “spare time” root cause analysis?

November 19th, 2015 by


Don’t get caught in these scenarios – make root cause analysis an integral part of your improvement program.

 Do these scenarios look familiar to you?

Here’s scenario #1:

An incident occurs.

The supervisor performs a 5-Whys analysis, or maybe just does a few interviews with a few employees out on the plant floor. The supervisor collects just enough information to fill out the company report, or to satisfy his manager because this is a task done in his spare time. Once someone or something is found to pin the cause on, the supervisor thinks of a solution, (typically an employee gets disciplined or a piece of equipment gets fixed), and the root cause analysis is complete.

The downside to doing root cause analysis in your spare time like this is you’ll probably see repeat incidents. You’ll miss root causes or not get to the root. So, instead of saving time doing the investigation in your spare time, you have created more work.  Plus, you are working within your own knowledge.  You may be very experienced, but a bias (and we all have them) can cause you to overlook important information.  Also, morale will be affected because employees do not want to live under the fear of punishment if they make a mistake. And let’s not forget when near misses and small problems aren’t solved, chances are a major incident is building on the horizon.  Don’t let your facility be the next headline!

Here’s scenario #2:

An incident occurs.

The supervisor performs a TapRooT® investigation in his or her spare time. Her company does not have a blame culture– hooray! She only had time to attend one day of a 2-day TapRooT® course, but the former supervisor showed her the basics. The supervisor uses the Root Cause Tree® as a “pick list,” (without using a Root Cause Tree® Dictionary to dig deeper – she is not even aware there is a dictionary), until one root cause and a couple of causal factors are found.  Sigh of relief. Corrective actions to the root cause are implemented.  Check! This root cause analysis is complete!

The downside to this TapRooT® “spare time” root cause analysis is similar to scenario #1 in that you will probably experience repeat incidents because you’ll miss root causes that won’t be fixed, and there was not sufficient training on the TapRooT® tools.  You may progress beyond your own knowledge in identifying root causes using the Root Cause Tree® and that’s a plus, but you may not be casting a wide enough net by using all of the tools in the TapRooT® system.  Take shortcuts and don’t use all the tools available to you, and you will lose the power of TapRooT® to effectively guide you in your root cause analysis to find and fix incidents.

Don’t be that supervisor!

To get the full benefit of TapRooT®, join us at a course to receive all of these tools and understand how to use them:

SnapChart® – a visual technique for collecting and organizing information to understand what happened.
Root Cause Tree® – a way to see beyond your current knowledge (with additional help from the Root Cause Tree® Dictionary)
Corrective Action Helper® – a tool to help you think “outside the box” to develop effective corrective actions.
Safeguard Analysis – identify and confirm causal factors

This is how you find all the root causes and fix them once and for all.  Smaller problems are also found before they turn into major disasters.  It’s a win for everyone!

Are you doing spare time root cause analysis?  There is still time to join us for a course in 2015 and make 2016 a different story.

Learn more here:
2-Day TapRooT® Incident Investigation and Root Cause Analysis Course
5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training

Peer Feedback to Improve Root Cause Analysis

November 11th, 2015 by


What value does the peer get from giving feedback about a root cause analysis?

All Root Cause Analyses started have an initial goal…

Reduce, Mitigate or Eliminate a Problem!

As TapRooT® trained root cause analysis investigators soon learn, there is usually more than one Causal Factor that caused the Incident being investigated, and each Causal Factor has more than one Root Cause. If this sounds foreign to you as an investigator, check out our TapRooT® Root Cause method here. So if problems do not occur in isolation, why should the investigator work in isolation? Thus, the topic of today, “Peer Feedback to Improve Root Cause Analysis.”

Previously we discussed real–time peer review during the investigation TapRooT® Process and reviewing a completed TapRooT® looking for the “Good, Bad and the Ugly” with a spreadsheet audit included.

Root Cause Analysis Video Tip: Conduct Real-Time Peer Reviews

The Good, The Bad & The Ugly

So what’s next? Are peers created equal? What value can a peer add? What value does the peer get from giving feedback about a root cause analysis? Let’s see….

Peers are not created equal! This is a good thing. Below is a short list of peers to get feedback on your root cause analysis progression and the value that they add.

1. Coach/Mentor: This is a person who is competent and formally trained in the root cause process that you are using. They are not teaching you the process but guiding you through your use of it after you were formally trained. They have been in the trenches and dealt with the big investigations, These process champions can easily get you back on the right track and show unique techniques.

Too many companies get large numbers of employees trained in a process and then let them run free without future guidance or root cause analysis feedback. This is why our TapRooT® Instructors are available for process questions after training is complete. This is also why we encourage key company employees to attend our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training to help mentor those that have taken our 2-Day TapRooT® Incident Investigation and Root Cause Analysis Course.

2. Equal: This is the person who has attended the same root cause analysis training that you have and has the same level of competence. They may also have the same industry technical experiences that you have.

The value of the feedback from this person is to keep each other grounded in the process you are using and to help validate that the evidence received is substantiated. It is very easy sometimes to start pushing any root cause process into one’s biased direction once the energy gets flowing. The trained TapRooT® investigator and peer will remind you to slow down and let the TapRooT® process guide you to the root causes.

3. Novice: There are two types of novices to get feedback from, one that is not trained in the TapRooT® process and one that is not familiar with the investigation or process being investigated.

There is a natural tendency that the more you know about the process you are investigating, the less that you put down on paper. After all, everyone knows how that thing works or what happened. Why do I need to write it down? Simple… “What does not get written down does not get investigated!” As the novice asks you more questions to understand the root cause analysis that you are performing, the more you explain and the more you write down.

4. Formal Auditor: The formal auditor usually audits the root cause analyses after they are completed and the corrective actions have been implemented. There is less communication and engagement between you and the auditor, which is very different than the first peers listed above.

The value of this feedback is that it is designed to look for consistency and standardization across multiple root cause analyses. The auditor may find investigations that need to be recalibrated but may also find new and better ways of doing an investigation based on other’s unique techniques. We also encourage auditors to have taken our 2-Day Advanced Trending Techniques Course, to help look for trends.

The final plus for this feedback activity…..

“Everyone learns something and recalibrates their Root Cause Analysis Techniques and we all help meet the goal of Reduce, Mitigate or Eliminate a Problem!”

New EPA Refinery Regulation Requires Root Cause Analysis of Upset Emission Events

November 5th, 2015 by

The new EPA emission regulation (not yet published in the Federal Register, but available here), requires a root cause analysis and corrective actions for upset emission releases including flare events.

Not only is a root cause analysis with corrective actions required, but a second event from the same equipment for the same root cause would trigger a diviation of the standard (read “fine”). In addition, the same device with more than 3 events per 3 years or the combination of 3 releases becomes a deviation.

This means it is time for effective, advanced root cause analysis of emission events. Time to send your folks to TapRooT® Root Cause Analysis Training!

Elements of a Credible Effective Root Cause Analysis

November 4th, 2015 by

Many people ask “What makes a good RCA?”. This question as stated is difficult to answer due to the fact that “good” is a very subjective term. What is good for one may not be good enough for another and vice versa. But, if we replace one simple word in that question we can make it a much more objective question. By changing that term to “credible” and/or “effective,” now we have a good starting point as both these terms have investigative standards and principles behind them. Let’s start with some definition:

Credible: This term is defined as “able to be believed; convincing.” Let’s focus on an investigation for our example and ask what would make our investigation able to be believed? One simple answer comes to mind, the ability to see the relationship between our Root Causes, our Causal Factors, and our Incident. That “Specific” relationship as we call it is dependent on the data collected in an investigation and ability for your audience to be able to connect those “dots” if you will.

Effective: This term is defined as “successful in producing a desired or intended result”. This focuses on the outcome of an action and what the desired results or end point is. For investigations the outcome or desired result is to implement fixes and Corrective Actions that will in the future reduce the risk of or remove the risk of a reoccurrence. The audience’ ability to see the effectiveness of the Corrective Actions is key.

So if we add both these words together and use them in combination to define an investigation we can now see how to answer the initial question.

Credible Root Cause Analyses

Let’s begin with the word credible and provide some guidance for our TapRooT® Users. When I look at and review any investigation the credibility is established for me in two techniques, the SnapCharT® and the Root Cause Tree®.


Let me put this as simply and as plainly as I can, when building your chart the team should put ALL information into that SnapCharT®. No matter how insignificant something may seem, or how common place something may be it should be on the chart for transparency and for use during the analysis on the Root Cause Tree®. Anytime you make a conscious effort to leave information off the chart you open yourself up for questions and you reduce the ability of your audience to “connect the dots” as mentioned above. This lowers your credibility significantly.

This can also lead to issues when your audience tries to understand the relationship between the Root Causes you have chosen on the Root Cause Tree® and the information on the SnapCharT®. This relationship should be as “transparent” as possible and the audience should not have to work to figure out the relationship. There should be a direct link between data on the chart and the Root Causes from the Root Cause Tree®.

Nurse 1Nurse 2
Above you see two examples of the same Causal Factor. The one on the left shows very little detail about the issue or problem, the one on the right shows all the data known about the same issue. Which one do you believe will help your audience and investigative team understand the problem?

Root Cause Tree®

Once the thorough “transparent” SnapCharT® is completed and the investigation move into the Root Cause Tree® to analyze your Causal Factors, documentation is the key to credibility. Three statements that can kill credibility are: “I believe,” “I think,” and “I am pretty sure,” Each one of these statements provides your audience with doubt as to what you truly know. This is why I always recommend the use of the Root Cause Tree® Dictionary and Analysis Comments in the Root Cause Tree® for documentation. This provides the connection and the defendable path for you and your audience.

As the Tree is analyzed the investigation should have data from the SnapCharT® to confirm each selection on the Root Cause Tree® as well as one or many questions answered as a yes from the Dictionary. Take that data (cut and paste) and put that into the Analysis Comments in the TapRooT® Software to document “why” you answer yes, and to show the audience your reasoning.

1 copy
Simply right click on the item and open the Root Cause Tree® Dictionary, highlight and copy the question or questions you get a yes to. Then use the same Rt-click menu to select the Analysis Comments Field.

AnalysisCommentField copy 2
Paste the copied text into this field and then describe the information from the SnapCharT® that gives you the yes. Click OK and that information is stored with your Root Cause Tree®. To access this information you can use the same Rt-click menu and select Analysis Comment again, or in the reports section for that investigation select the Root Cause Tree® Comment Report. This will contain all comments associated with each Causal Factor and Root Cause Tree®.

RCTCommentReport copy
This provides you with not only documentation for every step in the process but also with the “I know because” answer to any question that may arise. If data can be provided at any point in the Root Cause Analysis to show the “whys”, there is very little debate as to the credibility of the analysis. People may not like your answers, but they cannot deny them.

Effective Investigations

We have explored the “Credibility” of analyses so now we need to look at the Effective portion. We concluded that this measure is tied to the effectiveness of the Corrective Actions we present and implement. An analysis by itself cannot be effective without corrective and preventative actions that solve the Root Causes and prevent or reduce the likelihood of recurrence in the future.

When developing our Corrective Actions for the Root Causes we find during our analyses we have to consider the following items for each action:

Implementation: The act of putting the specific action in place in our systems and organization

Verification: This is a short-term measure of implementation. How are we going to ensure that what we proposed as the Corrective Action was implemented properly.

Validation: This is a long-term measure of effectiveness. This plan is based around the question, “What will success look like?” built with a plan to measure the progress (or regression) towards that outcome.

Most companies do a pretty effective job of the Implementation phase, implementing actions for every root cause. But in follow-up to these actions they do nothing; seemingly they wash their hands of the issue and say they are done. Implementation by itself does not ensure success. The two measurements above are very important because the provide some level of oversight for the actions and are a quality control check to make sure the actions hit the mark. If for any reason the Validation shows that the action is not having the desired effect the action needs to be revisited and revised if necessary starting the cycle again.

If Corrective Actions are implemented and not measured you increase the risk of the implementation falling short, or the action itself not actually having a positive impact on your systems and employees.


In the end, the credibility of your analysis is dependent on the data you collect, the quality (not quantity) of the data, and how it is used to confirm any answers found on the Root Cause Tree®. The effectiveness is dependent on the success of the corrective actions implemented and the longer term sustained success of the changes in the system to stop future recurrence. By following the 7-Step Process flow, and the Core techniques highlighter here within the TapRooT® process the system will guide you through these steps and aid you in successfully providing your management with a very Credible and Effective Investigation.

Want to learn more?

Our 5-Day TaprooT® Advanced Root Cause Analysis Team Leader Training provides all of the essentials to perform a root cause analysis plus advanced techniques.  You also receive a single user copy of TapRooT® software in the 5-day course.  The software combines incident identification, analysis, and dynamic report writing into one seamless process.

TapRooT® Summit – Get Amped Up in the Investigator Track!

October 28th, 2015 by


walk-292995_1280 copy

Join us in San Antonio, Texas August 1 – 5, 2016 for the Global TapRooT® Summit!


2507Ken Reed Head 2 copy

Ken Reed

Our 2016 Global TapRooT® Summit is just around the corner, and I’m REALLY excited about the session line-up we’ve set up for you. I’m the track leader in the TapRooT® Investigator Track, and we’ve got some excellent sessions planned to help you become a better investigator:

We’re going to start off with a session that lets our TapRooT® Users Share Best Practices with you. What better way to learn about best practice ideas than to get them directly from other users who are successfully implementing at their company? This session is always one of the most useful, hands-on sessions at our Summit.

Are your investigations any good? Mark Paradies is going to run a session on how to properly Grade Your Investigations. He’ll give you industry best-practice ideas on what really matters in an investigation. This isn’t just a high-level thought experiment; you’ll walk away with a grading sheet that you can customize for your company that will allow you to put an actual number grade on each investigation. This is a great way to improve each and every investigation.

Are you ready to implement TapRooT® at your company, but not sure how to get started? Ed Skompski will be leading a session on How to do a New Implementation of TapRooT®. We’ve helped many companies figure out what they need to do for a successful, long-term TapRooT® implementation, and he’s ready to share those ideas with you. Wouldn’t you love to have an implementation checklist?!

Barb Phillips is going to have a couple of sessions on individual investigator techniques. Interviewing Behaviors and Body Language will help you learn advanced skills to perform more effective interviews. The Investigation Team Leader session will give you pointers on how to lead more complex investigations from the perspective of the lead facilitator. These are both going to be terrific sessions for all TapRooT® investigators.

Wouldn’t it be nice to ask all the right questions at your very first interview? In addition to Barb’s topic on body language, we’re going to look even more deeply at how to use The 15 Questions To Identify Interview Topics. This will help you better plan your interviews to ensure you minimize the number of follow-up interviews required during your investigations.

We’ve had many requests to speak in more detail about the intricacies of a few of the Root Cause Tree® Basic Cause Categories. This year, we are going to Deep Dive into Procedures and Management Systems. We’ll show you where some of these root causes come from, and how to recognize them during your investigations.

I’m really excited about my track this year. If you are a TapRooT® investigator, you will not want to miss these sessions. Plan on being in San Antonio next year; don’t miss out on this opportunity!!

Learn more:

Three Indicators that Root Cause Analysis is not Important to your Business

October 21st, 2015 by


How important is root cause analysis to your business? Before you answer that, think about your completed investigations to find out if your efforts are working. Here are three indicators that root cause analysis (RCA) is not important to your business.

  1. The RCA stops short. There are many reasons a RCA will stop short of finding the real root causes. Political expediency, lack of valuable training, and failure to base the RCA on facts and evidence are high on the list among them. When the investigation stops after the first root cause is found, the problem will occur again because other paths to the problem were not identified and corrected.  Does your RCA system offer a way to examine a complete set of events and conditions so you never stop short?  Does it offer a way to document all of this efficiently?
  2. Weak corrective actions. Are you finding solutions that fix the problem or are you simply treating a symptom of the problem? It’s easy to tell. If the incident happens again after corrective actions were implemented, your corrective actions are only treating symptoms. Your system may not be offering you well-developed definitions or giving you the questions to ask so that you are not forced to rely on your own opinions and knowledge for fixes. Your system of root cause analysis is wasting your time.  A good RCA system clearly guides you to define the problem, measure and analyze it, and develop effective corrective actions.
  3. Lessons not learned. Is your organization learning from past incidents? Remembering what has occurred and how it was fixed will help your organization stay proactive. A focused set of root causes and effective corrective actions are important, but don’t forget the lesson.  A solid RCA system will help you identify generic causes. When you correct a generic cause, you’ll prevent problems from occurring across your organization.  Less work for you, more success for your business!

If you’ve noticed that your facility is running into one or more of the problems above, it’s time to consider training to make RCA more important to your business. RCA is mission critical knowledge worth the investment in training. Is the cheap answer working for you? Remember, you get what you pay for.

There is still time to grab a seat in our 2-Day TapRooT® Incident Investigation & Root Cause Analysis courses where you will learn ALL of the essentials to conduct a root cause analysis in just two days.  (CLICK HERE to learn more or register.)

And we have a few seats left in our 5-Day TapRooT® Advanced Root Cause Analysis & Team Leader Training courses where you will learn all of the essentials and advanced techniques PLUS receive a copy of our root cause software that will help you every step of the way.  (CLICK HERE to learn more or register.)


Are Your Corrective Actions Designed to Prevent Future Incidents?

October 14th, 2015 by

I had a great conversation with one of our clients today. He mentioned that, with the price of oil below $50/barrel, his company is being proactive and looking at ways to improve their processes.  One thing that they’re doing is reviewing old incidents and seeing where the commonalities lie.  One item of interest that they found:  They have discovered several instances of repeat problems.  They found root causes, but they seem to pop up again.

What they are doing is what we call a Generic Cause analysis.  They are looking deeper at their data and finding opportunities for improvement.

A review of the corrective actions found quite a few that seemed to be more akin to immediate actions than corrective actions.  For example, if there was a production shutdown that was caused by a failed valve, the corrective action was, “Remove and repair the faulty valve.”  Now, I’m not saying that this is necessarily a bad idea.  However, is this corrective action aimed at preventing future recurrence of the incident?  This corrective action, by itself, is designed more to restore plant operation, not prevent future issues.

Remarkably, this turned out to be more a terminology issue than a failure of their system.  When asked about this, the Corrective Action team said, “Oh, you want actions that will prevent the incident in the future?  Then you aren’t asking for ‘corrective actions’; you are asking for ‘preventative actions.’  You have to be clear what you want.”

TapRooT® does not really distinguish between these types of fixes.  We expect all of these actions to be developed.  We find that the “corrective actions” noted above are designed to fix the Causal Factor (“Valve failed to open.  Therefore, repair the valve.”).  This is as far as most other “root cause analysis” systems go, since they normally only get to the causal factor level.


While you DO need to fix these issues, we also want you to continue to assign corrective actions to actual root causes.  If the valve failed because the repair procedure specified the incorrect part (in TapRooT®, this root cause would be “facts wrong”), and you would therefore put a corrective action in place to fix this human-performance problem (“Update repair standard to indicate the correct gasket part number 885-33425″).  This will fix not just this particular valve, but any valves in the future that are repaired using this same repair procedure.  Without this corrective action, you will see this same issue pop up again as we continue to improperly repair valve failures.

Make sure you and your investigation teams are all on the same page.  We use the term “Corrective Action” to indicate any and all actions that are designed to fix problems.  Corrective Actions include those actions that fix the general issue (failed valve), and those that are designed to prevent the issue from occurring again in the future (procedure wrong).  Take a look at your systems and make sure you are fixing both types of problems.

Sign up to receive tips like these in your inbox every Tuesday. Email Barb at and ask her to subscribe you to the TapRooT® Friends & Experts eNewsletter – a great resource for refreshing your TapRooT® skills and career development.

How To Trend Your Accident Data

October 7th, 2015 by

What methods do you use to trend your accident data?

Is a decrease in lost time injuries seen as a success?

Is in an increase in injuries a failure and time for drastic action?

Are you using bar graphs or a simple line graph to look for trends?

How much change in the stats is enough for you to tell management that significant change has occurred?

That’s what I learned about 20 years ago and have been perfecting ever since.

How can you learn them too?

First, you can read Chapter 5 of the TapRooT® Book.

Second, you can study advanced trending and learn to use XmR Charts to trend accident data (both frequently occurring data and infrequently occurring data).

Third, you can attend SI’s TapRooT® Advanced Trending Techniques Course. You can hold one on your site for your people or the public course we hold each year just before the TapRooT® Summit.

When is the next public course?

On August 1-2, 2016 in San Antonio, TX. That’s a long time but it is the first public course. Mark your calendar to save the dates.

What will you learn at the TapRooT® Advanced Trending Techniques Course?

See the course outline here:

Also, read this article about picking targets for improvement to learn a little more before you attend a course:

And if you are interested in learning more about advanced trending, ask us about having a course at your site. Contact us by CLICKING HERE.

What is the Difference Between a Safety Related Incident and a Quality Problem when using TapRooT®?

September 30th, 2015 by

Quality ControlWelcome to this week’s root cause analysis tips column.

This week I would like to ask the question…what is the difference between a safety incident and a quality problem?

Before you answer that, let me tell you that this is a trick question.

The answer is……drum roll please: there is NO DIFFERENCE. The difference in a safety problem vs. a quality problem is the consequence; there is no difference in the approach you take in investigating.

In TapRooT®, the first thing we always do is to create a SnapCharT®. And the first thing we do when creating a SnapCharT® is to define the incident with a circle. This defines the scope of your investigation. Your circle could contain anything that creates pain for your company and that you would like to prevent from happening again. Examples of things that might go in your circle:

• Fatality
• Lost time injury
• Recordable injury
• Vehicle accident
• Facility damage
• etc. etc.

• Defective product (not sent to customer)
• Defective product (sent to customer)
• Customer complaint
• Delayed shipment
• Returns
• etc. etc.

Once you have defined the incident, you map out what happened, define the causal factors, perform root cause analysis, and develop corrective actions.

So start thinking about different ways your company can use TapRooT®. I’ve mentioned Safety and Quality, but there are many more. equipment reliability, environment, security, project delays; the list is really endless.

The more ways you can use TapRooT®, the better ROI you will get from your training. I know from experience when different disciplines in an organization start speaking the same language, there are some great intangible benefits as well. So if you are a safety manager, drag your quality manager with you to training next time. You will be glad you did.

Thanks for visiting the blog and best wishes for your improvement efforts.

Would you like to receive tips like these in your inbox? Our eNewsletter is delivered every Tuesday and includes root cause tips, career development tips, current events and even a joke. Contact Barb at to sign up for the TapRooT® Friends & Experts eNewsletter.  

4 Root Cause Analysis Timesavers

September 23rd, 2015 by


I know how this works.  You get the notification that “something bad” happened, and you are assigned to perform a root cause analysis.  Your initial reaction is, “There goes the rest of my week!”

However, there is no reason that a relatively simple analysis needs to take an inordinate amount of time.  There are several things you can do to make sure that you can efficiently conduct the investigation, find solid root causes, and implement effective corrective actions.  Here are a few ideas to help you make the process as smooth as possible.

1.  The first thing that needs to be in place is a Detailed Investigation Policy for your company.  When does a RCA need to be performed?  What types of problems trigger an RCA?  What is the decision-making chain of command?  Who makes the notifications?  Who is notified?  Who will be on the team?  All of these questions need to be easily answered in order to quickly get the process started.  I have seen investigators receive notification of a problem over a week after the actual incident.  By this time, evidence has been lost, key players are no longer available, and peoples’ memories have faded.  All of this makes the investigation just that much harder.  If you can streamline this initial decision-making and notification process so that the investigation can start within hours, you’ll find the actual investigation goes MUCH more smoothly.

2.  Probably the biggest timesaver is to Be Proficient in the TapRooT® Process.  We recommend you use TapRooT® at least once per month to maintain proficiency in the system.  You can’t be good at anything if you only use it sparingly.  I often hear people tell me, “Luckily, we don’t have enough incidents to use TapRooT® more than once per year.”  Imagine if I asked you to put together an Excel spreadsheet using pivot tables, and you haven’t opened Excel since 2014!  You’d have to relearn some key concepts, slowing you down.  The same is true of an investigation process.  If you only do an investigation once each year, you aren’t looking very hard for incidents.  I’ll guarantee there are plenty of things that need to be analyzed.  Each analysis makes you that much better at the process.  Maybe go back to point #1 above and update your investigation trigger points.

3.  When you actually get started on an investigation, the first thing you should do is Start A Spring SnapCharT®.  This initial chart gets your investigator juices flowing.  It helps you think about the timeline of the incident, identifying holes in your knowledge and questions you need to ask in order to fill those holes.  It is the first step in the process.  As soon as you get that initial phone call, start building your SnapCharT®!

4.  Finally, although it is optional, The TapRooT® Software can really speed up your analysis.  The SnapCharT® tool is extremely user friendly, and the Root Cause Dictionary is only a right-click away.  It guides you through the investigation process so you don’t have to try to remember where you’re going.

You won’t perform an investigation in 5 minutes.  However, by following these tips, you relatively quickly and efficiently move through the process, with terrific results.

To learn more about learning all of the essential techniques to perform a root cause investigation, read about our 2-Day TapRooT® Incident Investigation and Root Cause Analysis Course.

Accident/Incident Investigation Statistics … Typical Corrective Actions + More

September 22nd, 2015 by

Found an interesting old (2000) report from the UK HSE about incident/accident investigations. They had a contractor perform surveys about accident/incident investigation tools and results.


It seems that homegrown investigation systems or no system were the most frequently used to investigate accidents/incidents.


With that type of investigation system, it should be no surprise that the three top corrective actions were:

  1. Tell them to be more careful/aware.
  2. Training/refresher training
  3. Reinforce safe behavior (Is that discipline?)

That’s what we found back in the early 1990’s.

Think it has changed any today?


Another interesting fact. How long did people typically spend doing investigations?

  • 42% took 5 hours or less
  • 35% took 5 to 20 hours
  • 18% took over 20 hours

Of course this is an old UK survey. Does it match up with your current experience?checklist-41335_640


One third of those polled had NO accident/incident investigation training. Most of the rest just had general health and safety training as part of IOSH or NEBOSH courses. Also, most people performing investigations were not dedicated health and safety professionals.

What do you think? Is this similar to your experience at your company?


The report then provided a review of example investigations that the researchers had reviewed. As an expert in root cause analysis, these were awful but typical. many just filled out a form. Others grilled people and decided what they thought were the causes and the corrective actions.


Are you 15 years behind with no system, no training, and bad results?

Then you need to attend a TapRooT® Course. See:

Have you started to improve but still have a long way to go? You might want to attend one of our public 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training Courses. See:

Are you good to great but you want to be even better? The plan to attend the 2016 Global TapRooT® Summit in San Antonio, TX, on August 1-5. We’ll be posting more details about the Summit soon.

Improve Your Investigations with this Free Tool

September 16th, 2015 by

Jack Frost discusses an idea to improve investigations he learned during Mark Paradies’ best practice session at the 2015 Global TapRooT® Summit.
DOWNLOAD the free tool he refers to HERE.

And make plans to join us at the next Global TapRooT® Summit, August 1 – 5, 2015 in San Antonio, Texas!

When Deciding Who to Interview, Work Your Way Around the Target!

September 9th, 2015 by

One of the first dilemmas facing any investigator is deciding what data you need and what you have to have. There are many theories on this topic, but one rule of thumb I like to use is to, work your way around the target.

In the 7-Step Process Flow, Step 1 + 2 comprise the “What” portion of the investigation where we begin the process of trying to understand what our Incident is, and what let up to and followed it. During this time we work with our SnapCharT® to aid us in organizing and understanding the data we collect.

Data comes in many forms including our 3P’s + R; People, Paper, Plant, and Recordings. All of these forms of data are important to helping us understand the initiation of and the genesis of an incident. These different data types fit together to weave a picture of the incident and provides us with the basis for our analyses moving forward. For most, the first place we start is with anyone involved with the incident to get their first hand accounts of “What” happened and “Why”. By taking this very simplistic approach we can begin the process of vetting out truth and fiction, fact and opinion. But this is only one subset of people we must interview to fully understand an incident.

Working your way around the target means thinking about anyone who might have influence on an incident and making sure we interview and gather all perspectives.

Think of the incident/accident as a target, with concentric rings moving outward from the center. Each ring further from the center has less direct knowledge but can provide very valuable perspective. We need to understand everything surrounding the incident to fully evaluate for and understand the root causes. So there are various levels of knowledge and influence that we should consider.

Inner Circle – Those Involved: These people will give you your best starting point and the most information directly related to the incident/accident. Most direct knowledge will be found here.

Second Circle – Those Around or Near the Incident: This group can provide interesting information that might help you piece together what you know. They may or may not have any direct knowledge but can provide things such as what was heard, felt, smelled, tasted and sensed. Much of this can be used by the investigator understand information provided by those involved and can many times provide very simple yet important pieces to the investigative puzzle.

Third Circle – Subject Matter Experts (SMEs): When trying to understand a process or failure, SMEs provide an invaluable resource. Their knowledge can allow the investigator to understand successful performance and what should have happened. This can be used to understand both Equipment and Human Performance related failures. By understanding proper performance the investigator can more easily identify where potential failures exist. By understanding how processes or systems fail we can more easily identify Causal Factors.

Fourth “Dotted” Circle – Those with Influence on the Incident: Working with many investigative teams I have found that many facilitators only consider those members of management with direct involvement in the incident. That could include a direct line supervisor or a local area manager. By approaching this group in this manner the investigator can lose sight of a very important piece of work culture. That missing piece is the “Expectation”. What is communicated and expected can many times be in opposition and create confusion or problems in the work place. I believe to fully understand an incident and its causes the investigator should reach out to differing layers of management and talk about what is the “Expectation” for performance of whatever jobs are involved. This “Expectation” can not be used as fact but can aid in the understanding of decisions made and actions taken by those involved in the incident.

If the investigator works their way around the target, and ensure that these different perspectives are understood, they will have a better more thorough understanding of the incident and can perform a more thorough and complete root cause analysis.

To learn more about interviewing techniques, register for our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training.



Politician Calls for Root Cause Analysis

September 4th, 2015 by

This is not the Friday Joke.

Root cause analysis has become so popular that politicians are now calling for companies to complete a root cause analysis and implement corrective actions.


Massachusetts Governor Charlie Baker wrote a letter to Entergy Nuclear Operations calling on them to “… perform an appropriate root cause analysis …” of safety issues the NRC had announced “… and to complete all necessary repairs and corrective actions.”

The letter was in response to an unplanned shutdown at the Pilgrim nuclear power plant in Plymouth, Massachusetts caused by a malfunctioning main steam stop valve (one of eight valves that is designed to shut off steam from the reactor to the turbine that generates electricity). The valve had failed shut.

For all those not in the nuclear industry, note that in the nuclear industry, a failure of one of eight valves that failed in the safe direction (shut) and that has backup safety systems (both manual and automatic) can get a public letter from the Governor and attention from a federal regulator. Imagine if you had this level of safety oversight of your systems. Would your equipment reliability programs pass muster?

The response from Entergy to the Governor noted that, “We have made changes and equipment upgrades that have already resulted in positive enhancements to operational reliability.” (Note that these fixes occurred in less than a week after the original mechanical failure.)

For more about the story, see:

Note the local NPR story at the link above is inaccurate in its description of the problem and the mechanical systems.

For those interested in improving equipment reliability and root cause analysis, consider attending one of our 3-Day TapRooT®/Equifactor® Equipment Troubleshooting and Root Cause Analysis Courses. See the upcoming course list at:

Now for the biggest question … 

When will government authorities start applying root cause analysis
to the myriad of problems we face as a nation and start implementing appropriate corrective actions?

Root Cause Tip: What is the minimum investigation for a simple incident?

September 2nd, 2015 by


What is the minimum investigation for a simple incident?

Before you can answer this question, you need to decide the outcome you are looking for. For example:

  • Do you just want to document the facts? 
  • Would you be happy with a simple corrective action that may (or may not) be effective?
  • Do you need effective corrective actions to prevent repeats of this specific incident?
  • Do you want to prevent similar types of incidents?

The answers to these questions depend on two factors that determine risk:

  1. What were the consequences of this incident and could things have happened slightly differently and had much worse consequences?
  2. What is the likelihood that this type of incident will happen again?

Of course, before you start an investigation, answering these two questions may be difficult. Before you start an investigation, you don’t really know what happened! But in spite of this lack of knowledge, someone must decide if an incident is worth investigating and the resources to dedicate to the investigation.

I’ve seen simple incidents that, when investigated, revealed complex problems that could have caused a serious accident. Therefore, if a thorough investigation is not performed, the investigator may never know what they could have discovered. That’s why I caution management that something that seems simple may not be simple.

However, some incidents ARE simple. I’ve seen many incidents that people were investigating that were similar to this one:

An employee stumbles, falls, and sprains
his wrist while walking down a flat sidewalk.
He had on simple shoes with adequate tread.
He was not particularly preoccupied
nor was he entirely paying attention to each step
(just normal walking).

How much can be learned by investigating this incident? Probably not much. I would suggest that even though the person sprained his wrist, this incident should not be investigated beyond a simple recording of the facts so that the incident could be recorded for safety records (OSHA logs in the USA) and included in future incident trending. 

You might ask:

“But what if the employee had stumbled and fell in front of an oncoming car and the employee killed?”

In that case, because of the consequences, a detailed major investigation would be required.

In either case, the TapRooT® Root Cause Analysis System could be used to complete the investigation. 

The TapRooT® Root Cause Analysis System is a robust, flexible system for analyzing and fixing problems. The complete system can be used to analyze and fix complex accidents, quality problems, hospital sentinel events, and other issues that require a complete understanding of what happened and effective corrective actions. 

I’m in the process of writing a new set of TapRooT® Books. The first one I’m writing is about investigating simple incidents using the basic tools of TapRooT®.

To give you a sneak preview, if you decide to investigate an incident, the minimum technique to use is a SnapCharT®.

From the initial SnapCharT®, the investigator must decide if the incident is worthy of further effort (can something worthwhile be learned).

What’s next? What do you do if you decide to go beyond the initial SnapCharT®?

You will have to wait for the new book to be released early next year to find out what we are recommending. But I can give you a hint ,,, It won’t be asking why five times!

A Look at 3 Popular Quick Idea Based Root Cause Analysis Techniques: 5-Whys, Fishbone Diagrams and Brainstorming

August 26th, 2015 by

Today’s root cause tip will walk through a few popular quick-idea based root cause analysis techniques used by many.

Do a quick search using Google or Yahoo search engines for “Root Cause Analysis Training” and these techniques often pop up in your internet browser: 5-Whys, Fishbone (Ishikawa) Diagrams, Brainstorming and of course, TapRooT® Root Cause Analysis. Now type in “free” or “quick root cause analysis templates” and you will not find TapRooT®. Is that good or bad? Of course my dad always taught me that what is earned and worked for was always more satisfying and led to a stronger sense of accomplishment. The end product also lasted longer.


Why would a person search for root cause analysis training on the Internet? If I were to brainstorm the whys as defined in


- a sudden impulse, idea, etc.

- a fit of mental confusion or excitement. 


-1890-95; brain + storm; originally a severe mental disturbance

Then I might suggest the following “whys”:

  1. The person was bored.
  2. A student was doing research.
  3. A training department was assigned to find and schedule quick low cost training techniques that can be taught online.
  4. You were assigned to find good root cause training to solve problems.

Now those weren’t too many suggestions on my part. But there is hope, because brainstorming is best served in groups. As defined in

Brainstorming is a group creativity technique by which efforts are made to find a conclusion for a specific problem by gathering a list of ideas spontaneously contributed by its members.

But we have to establish a few rules per

  1. Focus on quantity…. The more the merrier.
  2. Withhold criticism…. No why is a bad why and you might shut down the quantity given by others that were made fun of.
  3. Welcome unusual ideas
  4. Combine and improve ideas… we can build off other peoples’ whys for a really good why to solve a problem.

Okay with our new rules and group in place, we came up with more whys to why someone was searching for root cause analysis on the internet:

  1. The person was bored.
  2. A student was doing research.
  3. A training department was assigned to find schedule quick low cost training techniques that can be taught online.
  4. You were assigned to find good root cause training to solve problems.
  5. The current root cause techniques are not working very well.
  6. You are planning a party and this would be a great team game. (This one was my favorite suggestion)

Fishbone (Ishikawa) Diagrams

Brainstorming not quite good enough in our quest to solve why people are searching for root cause analysis on the internet you think? Let’s do a guided search for whys with our group using a Fishbone (Ishikawa) Diagram.

Now this tool also comes with some rules:

  1. Agree on a problem statement as a group. Ours is “why are people searching for root cause analysis on the internet?”
  2. The problem statement is placed at the head of the fish as seen in the diagram above.
  3. Now Brainstorm the major categories of the cause of the problem and list them underneath each category. For our fishbone from, we are going use Methods, Machines, Material and Measurements.

a. Methods: How the process is performed and the specific requirements for doing it, such as policies, procedures, rules, regulations and laws

b. Machines: Any equipment, computers, tools, etc. required to accomplish the job

c. Materials: Raw materials, parts, pens, paper, etc. used to produce the final product

d. Measurements: Data generated from the process that are used to evaluate its quality

 Caution, there are many categories to chose from which may lead the group into different directions each time they use one. We could have also used the categories as listed in

The 7 P’s

Physical Evidence
The 5 S’s

Here is our refined fishbone. I have to admit, it does look a little better than the brainstorming list above. Did not take that much time at all.


  1. As each idea is given, the facilitator writes it as a branch from the appropriate category.
  • Again ask “why does this happen?” about each cause.
  • Write sub-causes branching off the causes. Continue to ask “Why?” and generate deeper levels of causes. Layers of branches indicate causal relationships.

Item number 4 gets into looking for causal relationships within our suggested causes which leads into our 5 whys discussion next.

5 Whys

Let’s take one of the “causes” listed above and get to a good root cause with our group to understand why people are searching for root cause analysis on the internet?

Here are the simple instructions for performing a 5 Whys as listed in

5 Whys is an iterative question-asking technique used to explore the cause-and-effect relationships underlying a particular problem. The primary goal of the technique is to determine the root cause of a defect or problem by repeating the question “Why?” Each question forms the basis of the next question.

  1. Why are people searching for root cause analysis on the internet?

Answer: Because there is no database to search in on their computer and the boss wants training answers now.

  1. Why is there no database on the computer to search from?

 Answer: Because these are computers produced in 1995 and a knowledge database cannot be installed.

  1. Why do we not have new computers that can have databases installed?

 Answer the company is short money.

  1. Why is there no money left to purchase computers?

Answer: Because we have lost money on repeat incidents.

  1. Why do we have repeat incidents?

Answer: Because we do not have a good, effective, cost reducing Root Cause Analysis Process. I have a great solution for this problem….. look here for future courses in TapRooT® Root Cause Analysis.

Okay, I agree this was a very high level and superficial exploration of the 3 Popular Quick Idea Based Root Cause Analysis Techniques: 5-Whys, Fishbone Diagrams and Brainstorming.

However, the steps that we explored are valid steps and flow of the actual processes. The ending results from superficial creation of whys are very true and have been the cause for repeat problem occurrences.

If you are going to use these process, as they are often still required for everyday issue resolution for some and for others are actually considered their only root cause tools, then head off some of the issues with a couple of these best practice suggestions.

  1. Never start with Brainstorming. This is a great tool for suggesting corrective actions tied to actual root causes, but should not be used for evidence collection and figuring out why something happened.

What to do instead? Go Out And Look (GOAL). Never armchair troubleshoot from a conference table surrounded by people.

  1. Only use a Fishbone (Ishikawa) Diagram if:

a. You have collected evidence
b. You standardized and defined your fishbone cause categories
c. You have the right experts in the room
d. Cause or Corrective action ideas do not drive the actual what and why questions.

  1. Only use 5 Whys for trying to identify the actions or inactions that allowed an issue to occur and not the actual root causes. Why?

a. There is a tendency to look for only one cause when using the process; even if you ask 5 Whys for each action or inaction found on the Fishbone (Ishikawa) Diagram, there is still a tendency to look for only one cause in each section. I have never just had one cause for any problem that I have investigated.
b. It is not how many questions one asks but what one asks.
c. When used to collect evidence or understand evidence, there is a tendency for “group think” to occur that drives which direction the evidence and causation linkage goes. Look up the Space Shuttle issue tied to the o-ring failure for a group think example that was detrimental to life.
d. There is nothing to push the investigations outside what they know as a whole and what may be missing from the investigation. In that case, always bring in different knowledgeable and people new to the problem for constant checks and rechecks. Also look for outside industry best practices and knowledge to help get better investigations completed.

So in closing…..

  1. If it looks too easy and requires less work, you get what you put in it.
  2. If there is a large amount of guessing, you are also guessing at the corrective action.
  3. If the right expert is not in the room when using the tools explored, nobody will know what to ask or to verify.
  4. If the people using the process are the only thing driving the evidence collection, bias has a stronger natural tendency to take over.

I look forward to your examples of using these processes and also comments on some of the traps you did or did not avoid while using these 3 tools.

Senior Management & Root Cause Analysis

August 19th, 2015 by

What is the easiest way to tell a good root cause analysis program from a bad one?

The involvement of senior management.

How do you know if a root cause analysis program is about to fail?

Senior management changes and the new management shows no interest in the root cause analysis program.

What level of senior management is involved in the best root cause analysis programs?

All the way to the corporate board.


The answers to the three questions above show that senior management involvement is extremely important to the success of any root cause analysis program. The better the root cause analysis program, the more senior management involvement counts. That’s why I thought I’d take this time to explain how senior management should be involved in a root cause analysis program.



I’ve seen a few leading companies where the Corporate Board was knowledgeable of the safety/process safety/quality improvement programs. The best had a senior manager who was responsible for reporting key reactive and proactive statistics to a special board committee with primary responsibility for safety and other improvement efforts. The committee, that included the CEO, also was provided with overviews of the most serious incident investigations and summaries of improvement efforts.

This board’s interest ensured that people paid attention to the programs and that budgets weren’t slashed for key improvement initiatives (because they were supported by the board).


Of course, VPs or Division Managers were interested in their division’s reactive and proactive improvement performance. What VP or Division Manager wouldn’t be if the Corporate Board was going to see their statistics. They wanted to be able to manage performance so they became involved in improvement efforts. The held divisional meetings to review progress and presentation of root cause analyses of their biggest problems. They held Plant Managers and Unit Leaders responsible for their performance making improvement programs succeed.


Involved Plant Managers demand good root cause analysis and schedule reviews of detailed root cause analyses of significant problem investigations. They make sure that their key improvement programs are staffed with well trained, insightful leaders and that they have plentiful staff and budget to perform investigations, review reactive and proactive statistics, sponsor training throughout the plant, and look outside the company for improvement ideas. They are the site sponsors of the improvement programs. They are trained in the root cause analysis tools being applied at the plant. Because they are trained, they offer insightful critiques of the investigation presentations. They reward employees for their participation in root cause analyses and the improvement programs.


Is your senior management involved in performance improvement?

Do you have best practices for management involvement that I’ve missed and should be included here?

What do you need to do to improve your management involvement?

If you have support, are you ready for management turnover?

Rome wasn’t built in a day. Don’t worry if your program doesn’t have all the management support that it needs. But don’t ignore your program’s shortcomings. Work on getting more management support all the way up to the corporate board.

When safety/improvement performance is seen as equally important, you know you have achieved a level of support that most improvement managers can only dream about.

What, Why and then Fix… There is No Other Sequence for Root Cause Analysis

August 12th, 2015 by

Heard the quote above in a movie years ago when a group of scientists created a super computer to solve the “Ultimate Question of Life.” The super computer’s “ultimate answer” was “42”. This answer meant nothing to the community because they did not know the ultimate question for the ultimate answer.

When it comes to effective root cause analysis and problem solving, are you jumping to the “ultimate why” or the “ultimate fix” without truly knowing the “ultimate what” behind the problem?

It is not how many questions you ask or even how many solutions that you throw at a problem; instead, it is how you define the scope of your problem that needs to be solved, what you learn when you find out what happened during the problem’s occurrence, what you ask based on what you learn and how you fix what you find out.

The sequence of what happened, why “the what” happened and then fixing what you find for good problem solving sounds simple, right? Then why do so many people not follow this critical sequence of problem solving? A personal experience comes to mind from a recent investigation failure that I observed. Note that you should always start with defining what the problem is that needs to be analyzed before you start a root cause analysis.

The problem scope of the investigation failure mentioned above was to understand why there was a repeat of an incident after a team had completed their incident investigation and implemented their created corrective actions.

What are the probable costs of not analyzing an incident?

1. Hazards to people, equipment, processes or a customer not identified and therefore will not be removed, isolated or mitigated.

2. The next associated incident has a worst outcome:

a. A loss of life, injury or other harm to people
b. Damage to the environment
c. Equipment run to unplanned failure
d. Loss of a process or production system
e. A loss of client from repeat defects and failures
f. Government or other independent Agency involvement

3. A backlog of incidents and rework of incidents that includes a backlog of corrective actions.

Below are some of the facts that I collected for the repeat incident failure that I observed:

1. The investigation team had a natural tendency to take shortcuts by using experienced-based guessing to reduce investigation time.

If you already “know” the whys of a problem or you know the solution that you want to implement, then you do not need to verify what happened.

This team’s shortcuts then became “longcuts” due to guessing and expert driven tunnel vision that led them into erroneously based evidence collection and why selections. This error ended in wasted time and poor corrective actions that did not lesson or mitigate the problems that caused the original incident.

2. Poor problem solving skills for many of the team were taught previously in “well meaning” problem solving training… 5-Why’s, Ishikawa Diagrams and Brainstorming Solutions.

Items one and two above support each other and are easily adapted by expertise driven problem solvers. Just call these factors above co-enablers. These methods tend to feel good because they support your own experiences and they are quick and easy tools to learn and use. These tools assume that all right experts are sitting in the room, all the right people went out to look at the problem and no guesses or assumptions were made. Not the case on most situations during problem solving.

A good root cause analysis process does not replace the need for a company’s process experts, workers or managers. It instead should pull good information from these people in an unbiased and effective manner. It should also ensure good corrective actions are developed, implemented, verified and validated.

The problems identified above encouraged the company’s problem solvers to deviate from an effective problem solving sequence of what, why and then fix during root cause analysis, which caused this team’s incident to repeat.

So what happens when investigators follow the “Ask Why First” method instead of trying to learn what happened first?

1. The investigators tend to pull from their own experiences first and quickly try to fit their experiences to the problem being analyzed. This is the first stage of failure called guessing. Never assume what happened is the same as to what really occurred during a problem. Also, if you never experienced the problem before, you will have no experience to fit the problem to.

2. Investigators often throw multiple “possible” root cause options at a previously “known” problem. The more causes the merrier, right?

Actually no. For every cause you throw at a problem not based on facts of the incident, you now have to take time to collect information, causing you to waste time. Often you choose which cause is the most important to you before you know the facts and then ignore collecting any other “unimportant” information.

3. Depending on the previous problem solving training received, investigators often drive the evidence collection with linear brainstorming why questions (5 Whys style).

You increase the probability of delaying, if not actually ignoring, viable evidence. This process also tends to let you drive to find just one “real root cause”. This problem is a critical error. After all, even a fire, like any other problem that you may investigate, has more than one ingredient and cause. This can also produce “tunnel vision” designed to find the “most important” or “rootiest root cause”.

Let’s look at the “Fix the Problem First” method. Many well-meaning problem solving methods state that solving the problem is more important than finding all the whys or what’s of the problem that needs to be resolved. Management doesn’t care how you fix the problem as long as you solve it, right? What could go wrong if we just try to brainstorm a solution first and by-pass the whole finding a cause thing?

1. The focus of the investigation tends to be for the investigators to quickly put things back to normal, to stabilize the environment for damage control. This is not problem solving in reality, it is actually called triage. Triage is where you quickly assess the issue, make a best solution guess and then put that guess into action. Reduction of time to solution is vital in triage.

There is a need for triage with immediate actions, however this should not be practiced during good problem solving because it becomes a “Broke-Fix” mentality as opposed to understanding the problem to improve preventing the problem from occurring again.

2. If you have a fix in mind, you have an agenda. This agenda looks for supporting evidence to validate the selected fix and also tends to filter out other important issues.

The level of your organization chart that is driving the solution during this process can also set the stage for what is acceptable for the investigators at that site to discuss and address at the employee level. This often restricts getting all the facts and restricts what is allowed to be changed.

So how does starting with “What happened first” during problem solving prevent the issues listed above?

1. Identifying what happened before the problem that needs to be resolved occurred and what happened after it occurred, with proper detail and supporting evidence, reduces the case for assumption led decisions.

2. Writing down what happened, increases the ability to identify more clearly the conflicting statements from interviews and gaps in a process being investigated.

3. Writing down what happened, allows you to identify what worked right. This helps validate good processes and demonstrates that you’re using a root cause analysis process that looks for the good, the bad and the missing best practices. This is good for morale and increases the probability for effective and sustaining corrective actions.

4. You now have good documentation to help you find out why the problem that needs to be resolved occurred and why the fix is justified. This documentation can reduce the amount of corrective actions rejected by managers and regulators.

5. You are now using a good root cause process to not only figure out why the problem occurred but what also why actions or inactions failed to mitigate the problem or made it worse.

6. At the end of the day your initial gut feeling of what happened, why it happened and how to fix it is either substantiated or rejected based on facts and not emotions.

The sequence of What, Why and then Fix… There is No Other Sequence for good Root Cause Analysis.

For extra credit after reading this TapRooT blog article, let me know what movie the ultimate answer “42” came from and what the question really was for the answer.

You can also join me to learn more about effective TapRooT® Root Cause Analysis by attending one of my classes. We can talk about the movie over coffee or a soda and make a SnapCharT® for why the world was going get destroyed for a new galactic highway.

Why What You Think About Root Cause Training is Wrong

August 5th, 2015 by


People are often surprised when they learn the reasons they haven’t taken root cause analysis training are invalid.  Here are the top three excuses people give that are wrong:

1. Most employers aren’t seeking that skill when hiring.

Root cause analysis is a top skill valued by employers because mistakes don’t “just happen” but can be traced to well-defined causal factors that can be corrected.  A bonus to root cause analysis training is that root causes identified over time across multiple occurrences can be used for proactive improvement. For example, if a significant number of investigations point to confusing or incomplete SPAC (Standards, Policies, or Admin Controls), improvement of this management system can begin. Trending of root causes allows development of systematic improvements as well as evaluation of the impact of corrective actions.  What boss doesn’t appreciate an employee who can prevent HUGE problems and losses from occurring?  Promoting your root cause analysis skills is an impressive topic of conversation on any job interview.

2. It takes too long to learn enough to really use it on my job.

In just 2 days you can learn all of the essentials to conduct a root cause analysis and add this impressive skill to your resume.  You will be equipped to find and fix the root causes of incidents, accidents, quality problems, near-misses, operational errors, hospital sentinel events and other types of problems.  The essential TapRooT® Techniques include:

  • SnapCharT® – a simple, visual technique for collecting and organizing information to understand what happened.
  • Root Cause Tree® – a systematic, repeatable way to find the root causes of human performance and equipment problems — the Root Cause Tree® helps investigators see beyond their current knowledge.
  • Corrective Action Helper® – help lead investigators “outside the box” to develop effective corrective actions.

There are all kinds of training programs you can enroll in for your career development that take months, even years, to complete.  A 2-day investment for this valuable training program will equip you with a powerful skill that will set you apart from the rest.

3. I don’t have enough technical knowledge to take training like that.

It doesn’t matter if you have a high school diploma or an MBA.  It doesn’t matter if you do not know much about root cause analysis beyond the description provided below.  Our attendees, at every level of education and technical skill, find that they can engage in the training and take away root cause analysis skills to implement immediately.  It is not a “sit and listen” training – attendees do hands on exercises to develop their new knowledge in the course.

Root cause analysis is a systematic process used in investigating and fixing the causes of major accidents, everyday incidents, minor near-misses, quality issues, human errors, maintenance problems, medical mistakes, productivity issues, manufacturing mistakes and environmental releases.

Root cause analysis training provides:

  • the knowledge to identify what, how and why something happened, and this knowledge is vital to preventing it from happening again.
  • the understanding that root causes are identifiable and can be managed with corrective actions.
  • an ease of data collection, root cause identification, and corrective action recommendations and implementation.

Still not convinced root cause analysis training is for you?

GUARANTEE for the 2-Day TapRooT® Incident Investigation and Root Cause Analysis Course: Attend this 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.

CLICK HERE to register for the 2-Day TapRooT® Incident Investigation and Root Cause Analysis Course.

What’s the most important information in a root cause analysis?

July 29th, 2015 by

Welcome to this week’s root cause tips column. So what is the most important information or criteria in a good root cause analysis? (By the way, this is a trick question)

I started a list:

• A timeline of what happened
• Complete evidence
• Identification of causal factors
• Safeguards analysis (what failed)
• Safeguards Analysis (what worked)
• Root Causes substantiated by evidence
• Generic (system) Causes identified
• Corrective Actions that eliminate the root causes
• Corrective Actions that are implemented
• Corrective Actions that have been verified effective

So what do you think? Have I missed anything? Please comment below if you have any other ideas.

And which are the most important?

Yes, it is a trick question. They are ALL important.

For example, what if you did a really good job of collecting evidence and got good root causes but wrote weak corrective actions? Have you ever seen training as a corrective action for root causes that had nothing to do with training? Of course you have, that’s my point.

TapRooT® is a systematic process, software, and training for finding the real root causes of problems.

TapRooT® is a systematic process, software, and training for finding the real root causes of problems.

What if you had great corrective actions but they were never implemented (or checked to see if they were effective)?

The fact of the matter is you have to have all these things for an effective investigation and root cause analysis. It is easy to miss things, we’re all human and we all have different experiences, knowledge, and biases. But the good news is that this is all built into how TapRooT® functions. Just follow the process and you will have a good root cause analysis.

You must know WHAT happened before you can determine why. This is why evidence collection is so important.

You must know WHY before you can write corrective actions. If you do not have good evidence you will miss causal factors and root causes. ALL root causes have to be substantiated with evidence.

You must FIX the root causes. Your corrective action has to specifically address the root causes, has to be implemented, and has to be verified.

Think of it as a chain link fence. If any part of the chain is broken, the fence is compromised, and in this case, so is your investigation.

If you are interested in learning the TapRooT® Root Cause Analysis, our 2-day course offers all the process essentials needed to conduct an investigation including:

  • SnapCharT® – a simple, visual technique for collecting and organizing information to understand what happened.
  • Root Cause Tree® – a systematic, repeatable way to find the root causes of human performance and equipment problems — the Root Cause Tree® helps investigators see beyond their current knowledge.
  • Corrective Action Helper® – help lead investigators “outside the box” to develop effective corrective actions.

Check out our schedule for a course near you:

I hope I’ve given you some food for thought. Thanks for visiting our blog and happy investigating.

Root Cause Analysis Tip: 6 Reasons to Look for Generic Root Causes

July 22nd, 2015 by


“Allowing generic causes to fester can sometimes cause similar problems to pop up in unexpected areas.”

You have established a good performance improvement program, supported by performing solid incident investigations.  Your teams are finding good root causes, and your corrective action program is tracking through to completion.  But you still seem to be seeing more repeat issues than you expect.  What could be the problem?

We find many companies are doing a great job using TapRooT® to find and correct the root causes discovered during their investigations.  But many companies are skipping over the Generic Cause Analysis portion of the investigation process.  While fixing the individual root causes are likely to prevent that particular issue from happening again, allowing generic causes to fester can sometimes cause similar problems to pop up in unexpected areas.

6 Reasons to Look for Generic Root Causes

Here are 6 reasons to conduct a generic cause analysis on your investigation results:

1. The same incident occurs again at another facility.

2. Your annual review shows the same root cause from several incident investigations.

3.  Your audits show recurrence of the same behavior issues.

4. You apply the same corrective action over and over.

5. Similar incidents occur in different departments.

6. The same Causal Factor keeps showing up.

These indicators point to the need to look deeper for generic causes.  These generic issues are allowing similar root causes and causal factors to show up in seemingly unrelated incidents.  When management is reviewing incident reports and audit findings, one of your checklist items should be to verify that generic causes were considered and either addressed or verified not to be present.  Take a look at how your incident review checklist and make sure you are conducting a generic cause analysis during the investigation.

Finding and correcting generic causes are basically a freebie; you’ve already performed the investigation and root cause analysis.  There is no reason not to take a few extra minutes and verify that you are fully addressing any generic issues.

Learn more about finding and fixing root causes in our 2-day or 5-day TapRooT® Root Cause Analysis courses!

Interviewing: Why Every Investigator Should Avoid These 3 Things

July 15th, 2015 by

When an employee is a witness to an incident that occurs in the workplace, what he or she witnessed becomes valuable information for evidence collection and finding and fixing the root causes.  Retrieval from memory is hard work, and when an interview is not set up properly, a witness will not remember important details.

The two short videos below are actors playing the role of interviewer and interviewee in a mock incident investigation interview for a General Motors incident investigation training module. They created one “good” interview, and one “bad” interview scenario.

Let’s take a quick look at the bad scenario, what not to do when interviewing.

Three mistakes to avoid:

  1. The interviewer did not communicate open, friendly body language during the greeting or try to “break the ice.” Notice that the interviewer appeared uninterested in the interviewee when she sat down, and he gestured with palms down which may convey to the interviewee that he already knows what happened. Soon thereafter, he actually says the words “I know what happened” and “I gotta ask you some questions so I can fill out this report.” At this point, the interviewee may feel like the interview is just a formality and he doesn’t need her information.  This mistake is a good way to completely shut the interviewee down right off the bat.
  2. The interviewer asked closed-ended, leading questions. “Was Larry wearing a seatbelt?”  “Was Larry speeding?” “Was Larry out partying again last night?” The interviewer put the interviewee on defense with this line of questioning.  Also, these questions are limited to a “yes” or “no” answer and will not elicit much information, and they are leading. The interviewer already told her “I know what happened” so she may have been afraid at this point to say “yes” or “no” because it may not be the same thing the interviewer “knows.”  Overall, interviewees want to provide good information so when interviewers lead them into thinking they already have “the right” information, the interviewees may doubt what they witnessed so they can also give “the right” answer.
  3. The interviewer does not set up the cognitive interview properly and interrupts constantly. Interrupting when an interviewee is delivering a narrative (i.e., telling the story as she remembers it) is the worst mistake an interviewer can make because it causes the interviewee to lose her train of thought and valuable information she may provide.  The interviewer has already made the mistake of assuming the principle role with his “I already know what happened” attitude so the interviewee will wait for him to ask specific questions without volunteering anything.  The interviewer also said “I only have a few questions here.” This makes the interviewee feel like he is in a hurry so she should keep her answers brief.

How the interview could be improved:

  1. Begin the interview with a friendly tone to develop rapport.  This includes open body language (smile, eye contact, open palms).  Tell the interviewee about the purpose of the interview (to find the root causes of the incident so they can be corrected and kept from occurring again).  If the interviewee was injured or witnessed a tragic accident, ask her how she is feeling or how she is doing since witnessing the accident.  Be human. Research proves that the amount of information an interviewee remembers changes based on the tone established during the first few minutes of the interview.
  2. Save closed-ended questions to follow-up something specific the interviewee said. When the interviewee is telling her story (the narrative) of the incident and a question pops into the interviewer’s mind about what she said, don’t interrupt.  After the witness gives her narrative, try open-ended questions before closing in on small details with closed-ended questions.  This will keep the interviewee in memory retrieval mode for a little longer.  The interviewer should write down questions and ask them after the interviewee has completely finished her narrative, and the questions should pertain to the narrative. For example, “You stated that you were on Workstation 3 when the incident occurred. Is that your normal workstation?”
  3. Set up the cognitive interview.  There are three steps to setting up a cognitive interview. The first step is to tell the interviewee explicitly to assume the principle role.  “I didn’t see the incident, so I’m relying on you to tell me what happened.”  The second step is to ask the interviewee for the narrative.  “Picture, in your mind’s eye, where you were right before the incident occurred.  Think about where you were standing, what you were thinking and feeling at the time. Get a clear picture of your surroundings.”  The third step is to ask the witness to report small details. “Tell me everything you remember about the incident no matter how trivial.”  Then don’t interrupt!

Let’s take a quick look at a “good” interview.

Keep in mind that these videos were recorded for training purposes.  A true cognitive interview would last longer than 3 minutes, but this is a good example of a few good techniques to use. Kudos to these two actors and their efforts to make our workplaces safer.

Comment below on the techniques the interviewer used that made this interview better than the first as well as any mistakes in the first video that were not discussed above.

For more information about how to conduct an investigative interview, attend our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training.

What were the Safeguards?

July 9th, 2015 by

I love to use Safeguard Analysis to examine incidents and determine Causal Factors. 

What were the Safeguards keeping this officer safe and how did they fail? (A failed Safeguard is usually a Causal Factor.)

Watch and leave a comment about your ideas …

Connect with Us

Filter News

Search News


Barb PhillipsBarb Phillips

Editorial Director

Chris ValleeChris Vallee

Six Sigma

Dan VerlindeDan Verlinde

Software Development

Dave JanneyDave Janney

Safety & Quality

Ed SkompskiEd Skompski


Gabby MillerGabby Miller

Communications Specialist

Ken ReedKen Reed


Linda UngerLinda Unger

Vice President

Mark ParadiesMark Paradies

Creator of TapRooT®

Steve RaycraftSteve Raycraft

Technical Support

Success Stories

In 1995, BellSouth Telecommunications noticed an increase in the number of service interruptions or outages…

Bell South

The healthcare industry has recognized that improved root cause analysis of quality incidents…

Good Samaritan Hospital
Contact Us