Category: Root Cause Analysis Tips

Prepare your Investigation Results for Management

October 24th, 2016 by

presentation-36911_1280After you’ve concluded a TapRooT® investigation, preparing your investigation results for management doesn’t have to be a chore.  If you have TapRooT® software, you can avoid creating a Powerpoint completely!  Learn how here.

If you prefer to add content to a PowerPoint, the TapRooT® tools that helped you complete your investigation will also help you create a presentation that gets their attention.  Here is a simple guideline of what content to add from your TapRooT® investigation:

  • After your introduction slide, clearly and simply state the incident and the determined results in two to three sentences.
  • On the next slide, present a small section of your SnapCharT® that explains the incident.  For most incidents, it will include four to six Events (Squares) leading up to the incident, as well as the the incident (Circle), and one or two Events that occurred after the Incident.  Only present the first line of the SnapCharT® (the Events) on this slide.
  • Then add slides with visuals.  You have already documented evidence through photographs and videos and maybe even sketched arrangement/placement in Steps 1 and 2 of the TapRooT® 7-Step Major Investigation Process.  You can use these items as Powerpoint visuals.  But how many should you use?  Use the visuals that most clearly support your results – just a few will suffice depending on the complexity of the incident.
  • Then present slides that contain each section of your SnapCharT® that includes a Causal Factor – one Causal Factor section per slide.  Include Events and Conditions this time.  Write the Root Cause next to each Causal Factor determined.  Do not present the Root Cause Tree.  Why?  Because then you are providing a pick-list for management to analyze and they have not put in the hours analyzing the SnapCharT® and finding supporting evidence.
  • Finally, create a slide that presents your Corrective Actions in an easy-to-read column or table format.  For example, list the Root Cause in Column 1, the Corrective Action in Column 2 and who will implement the Corrective Action (and the deadline for implementation) in Column 3.

To practice preparing and presenting results to management, sign up for our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training.  You can even bring a real incident from your facility!

Users Share Best Practices: Understanding and Applying TapRooT®

October 24th, 2016 by

Our 2016 Global TapRooT® Summit was a great success this year! Our attendees helped one another by sharing some of their best practices. Brent Cothran describes how his company trains all new employees on the TapRooT® process.

(Click post title if video is not displaying.)

Users Share Best Practices: Adding a Day Two Refresher

October 21st, 2016 by

Our 2016 Global TapRooT® Summit was a great success this year! Our attendees helped one another by sharing some of their best practices. Watch Randy Karasti describe how adding a refresher at the beginning of the second day of training has helped their organization.

(Click post title if video is not displaying.)

Users Share Best Practices: Running a Four Day Course

October 20th, 2016 by

Our 2016 Global TapRooT® Summit was a great success this year! Our attendees helped one another by sharing some of their best practices. Larry Perkinson shares how his company teaches a four day TapRooT® course that includes a day dedicated to exams. What a great idea!

(Click post title if video is not displaying.)

Users Share Best Practices: Defining Your Focus

October 18th, 2016 by

Our 2016 Global TapRooT® Summit was a great success this year! Our attendees helped one another by sharing some of their best practices. Here Steven Sandlin discusses his best practice of defining the focus. What is the minimum threshold that drives an investigation?

(Click post title if video is not displaying.)

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

October 12th, 2016 by

Happy Wednesday and welcome to this week’s Root Cause Analysis Tip.

The topic this week is the concept of “Defense in Depth.” You may have also heard terms such as Barrier Analysis or LOPA (layer of protection analysis). In TapRooT®, we use the term Safeguards.

Take a look at this diagram (courtesy of Mark Paradies, the creator of TapRooT®):

Screen Shot 2016-10-07 at 10.43.31 AM

What the diagram depicts is an incident where several layers of protection have been breached. You may have also heard of Reason’s “Swiss Cheese Model.” In these models we can see that we only have incidents when all layers are breached. So the amount of layers and strength of those layers determine if (and how often) we have incidents. It is also why sometimes things go wrong but we do not have an incident; because one or more layers worked.

So our goal in developing processes is to make sure we have enough layers and that the layers are functioning the way we want. Remember that every Safeguard has a hole in it, it is not infallible. So we want to make the holes as small as possible.

The same applies to corrective actions. Do we need new layers? How can we strengthen existing layers?

The concept is easy. What is difficult is determining just how much is enough.

Risk really is the main driver of that in my view, but business realities come into play as well. The easy ones are the ones on either side of the spectrum. For example, something is fairly difficult but low risk – probably all you need is a procedure and some training (we refer to these as Quasi-Safeguards).

If something is difficult AND high risk, we need a lot of layers, and hopefully many of them are engineering controls.

The hard ones are the ones in the middle; a process is very easy and there is very little chance of a problem… BUT, the risk is very high – in this case determining what you need can be very difficult.

In my November column, I will talk about the strength of Safeguards.

In closing, I urge you to think about Defense in Depth when developing processes. Audit them to make sure the layers are functioning. And if you do have an incident think about Safeguards and Defense in Depth when developing your corrective actions.

Have you been to our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training?  Learn more about advanced techniques like Safeguards Analysis, Change Analysis, Critical Human Action Profile (CHAP) and Cognitive Interviewing.

Thanks for visiting the blog, and enjoy your week.

Users Share Best Practices: Including Positives in Your Report

October 10th, 2016 by

Our 2016 Global TapRooT® Summit was a great success this year! Our attendees helped one another by sharing some of their best practices. Watch Matt Deluhery discuss his best practice of including positives found during an investigation. These include noting safeguards that worked as well as individuals that stepped up during the recovery process.

(Click post title if video is not displaying.)

Root Cause Analysis Tip: Investigating a Procedure Problem

September 28th, 2016 by

TapRooT® Users … What do you do when you think there may be a problem with a procedure that contributed to a Causal Factor that led to an Incident?

Here’s a tip from the soon to be published book: TapRooT® Root Cause Analysis for Major Investigations.

To investigate problems in the Procedures Basic Cause Category:

  1. Get an unused copy of the procedure.
  2. Get the completed, signed-off or checked-off procedure (if sign-off/check-off is required).
  3. Get any reference material/documentation.
  4. Was procedure used?
  5. Was it signed-off properly?
  6. Verify technical accuracy of the procedure (table-top review).
  7. Verify usability of the procedure by performing a field walk-through. (Consider performing a Critical Human Action Profile, Appendix F, and reviewing potential human factors problems at the same time.)
  8. If problems are found, consider looking for generic causes in the procedure writing and review system.

That’s the start of the guidance provided in the book that will be published in November. Watch for our notice about the release and get your copy for guidance investigating all of the Basic Cause Categories on the back side of the TapRooT® Root Cause Tree®.

My favorite procedure related story was and investigation where the team doing the investigation said that the person who was injured was using a procedure. I asked to see it. They said:

You want to see the procedure?

I said “Yes.”

They sent someone off to get it.

They came back with a brown paper grocery bag.

They handed it to me.

I said, “What’s this?”

They said, “the procedure.”

I looked in the bag. There was nothing inside.

They said, “No look on the outside of the bag.”

There were hand written notes on the outside of the bag. Mainly equipment part numbers. That was …

The Procedure.

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

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

September 28th, 2016 by

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

(Click post title if video is not displaying.)

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

September 15th, 2016 by

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

Here is the question …

Can we do more?

The answer is … YES!

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

What is a Generic root cause?

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

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

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

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

Get the idea?

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

To do this we use this three step process:

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

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

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

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

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

That’s going beyond simple root cause analysis.


Using TapRooT® for Simple Investigations

August 9th, 2016 by

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

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

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

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

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

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

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

Flowchart with no paragraphs

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

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

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

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

Choose a course and register here!

Is Discipline All That Is Needed?

July 6th, 2016 by

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

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

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

Let me sum up what we know …

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

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

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


Healthcare: Can’t See the Forest for the Trees

July 5th, 2016 by


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

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

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

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

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

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

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

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

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

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

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

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

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

July 5th, 2016 by


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

X + Y (A) = The Incident

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

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

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

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

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

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

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

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

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

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

Can Healthcare Benefit from Procedure Usage?

June 27th, 2016 by


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

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

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

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

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

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

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

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

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

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

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

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

Those procedures always make work more difficult.

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

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

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

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

Have a Plan! Using the TapRooT® Tools to Plan Your Investigation

June 22nd, 2016 by


Sometimes, it seems like the toughest part of an investigation is figuring out how to get started. What’s the first step? Where am I headed? Who do I need to talk to? What questions should I ask?

Unfortunately, most systems kind of leave you hanging.  They assume that you’re some kind of forensic and investigation expert, with years of psychological and interviewing training already under your belt.  Like you’re only job at your company is to sit around and wait for a problem to occur so that you can perform an investigation!

Luckily, TapRooT® has some great tools that are designed to walk you through an investigation process.  We have recently tweaked this guidance to make it even easier to quickly progress through the investigation.  Some of the tools are used for every investigation; some are used only in specialized circumstances when you need additional help gathering information.

Some of these tools are required for every investigation; some are optional data-gathering tools.  Let’s first take a look at the required tools.

Mandatory Tools


One of the first things you need to do is get a good understanding of exactly what happened.  Instead of just grabbing a big yellow legal pad and start scribbling down random thoughts, you will use the SnapCharT® to build a visual representation and timeline of what actually occurred.  By putting your thoughts down on the timeline, you can more easily see not only what you already know, but also what you still need to find out.  It helps you figure out what questions to ask and who to ask.  Building your SnapCharT® is ALWAYS the first step in your investigation for just this reason.  There is no reason to go into the interview process if you don’t already have a basic understanding of what happened and what questions you need to ask.  It’s really amazing to see a group of people start building a SnapCharT®, thinking they already have a good understanding of the issues, and watch them suddenly realize that they still need to ask a few pointed questions to truly understand the problem.

Root Cause Tree®:

Most TapRooT® users know that the Root Cause Tree® is used during the root cause analysis steps in the process.  However, this tool is a treasure trove of terrific questions and guidance that can be used while building your SnapCharT®.  In conjunction with the Dictionary®, it contains a comprehensive list of interview questions; the same questions that a human performance expert would ask if they were performing this same investigation.  You’ll need the answers to these questions once you get to the root cause analysis phase.  Why not “cheat” a little bit and ask these questions right up front while building your SnapCharT®?

The tools I listed above are used during EVERY investigation.  However, in certain circumstances, you may need some additional guidance and data-gathering tools to help build your SnapCharT®.  Let’s look at the non-required tools.

Optional Tools

Change Analysis:  This is a great tool to use to help you ask thought-provoking questions.  It is used when either something is different than it used to be, or when there is a difference between two seemingly identical circumstances.  The Change Analysis tool helps you determine what would have normally made the situation operate correctly, and (this time) what allowed the problem to show up under the exact circumstances of the incident.  It is actually an extremely easy tool to use, and yet it is very powerful.  I find this to be my most-used optional tool.  The results of this analysis are now added to your SnapCharT® for later root cause analysis.

Critical Human Action Profile (CHAP):  Sometimes, you need help understanding those “dumb” mistakes.  How can someone be walking down the stairs and just plain fall down?  The person must just be clumsy!  This is a great time to use CHAP.  It allows you to do an in-depth job task analysis, understanding exactly what the person was doing at each step in the task.  What tools were they using (and supposed to be using)?  How did we expect them to perform the individual steps in the task?  This tool forces you to drill down to a very detailed analysis of exactly what the person was doing, and also should have been doing.  The differences you find will be added to your SnapCharT® to help you understand EXACTLY what was going on.

Equifactor®:  If your investigation includes equipment failures, you may need some help understanding the exact cause of the failure.  You can’t really progress through the root cause analysis unless you understand the physical cause of the equipment problem.  For example, if a compressor has excessive vibration, and this was directly related to your incident, you really need to know exactly why the vibration was occurring.  Just putting “Compressor begins vibrating” on your SnapCharT® is not very useful; you have to know what lead to the vibration.  The Equifactor® equipment troubleshooting tables can give your maintenance and reliability folks some expert advice on where to start looking for the cause of the failure.  These tables were developed by Heinz Bloch, so you now have the benefit of some of his expertise as you troubleshoot the failure.  Once you find the problem (maybe the flexible coupling has seized), you can add this to your SnapCharT® and look at the human performance issues that were likely present in this failure.

The TapRooT® System is more than just the Root Cause Tree® that everyone is familiar with.  The additional tools provided by the system can give you the guidance you need to get started and progress through your investigations.  If you need some help getting started, the TapRooT® tools will get you going!  Learn more in our 2-day TapRooT® Incident Investigation and Root Cause Analysis Course.

Handwriting and RCA

June 20th, 2016 by

Today’s article is meant to create a discussion. We all know that Electronic Medical Records (EMR) are taking the place of written orders in healthcare (providing their own set of issues), so where does the written word fall on the Root Cause Tree®?

The cartoon below illustrates the issue we are discussing:

Back in the day doctors and nurses always used written records, or prescriptions. Today the reliance on this form of communication is less than in the past but can still cause issues. One question to ask yourself is, “Is the burden of understanding written communication on the writer or the reader?”  What is your opinion on this? Mine is that it is most certainly on the writer. We should not provide communications of any kind that have to be interpreted to be understood. Going back that is why many acronyms have been removed from healthcare…they simply created confusion.

So thinking about written communication, if we have a Causal Factor dealing with a nurse or physician did something wrong due to a misunderstanding of a written communication…where would we go under the “Human Performance Difficulty” section?

One question that would most likely be a yes is the second question under the Team Performance Section: Did failure to agree about the who/what/when/where of performing the job play a role in this problem?. This leads us to Training, Communications, and Work Direction but does that really match?

For this week please provide your insight into where you believe this issue would fit. Thank you for reading and for providing your insight! I will write about our results in next week’s article! Have a great week……

(P.S. Don’t forget to sign up for my Medical track at the 2016 Global TapRooT® Summit, San Antonio, August 3-5, 2016.)

Root Cause Analysis is not about Root Causes

June 15th, 2016 by


I must be crazy, I teach TapRooT® Root Cause Analysis and say it’s not about the root causes? Yes, it is true. Root Cause Analysis is really about fixing, prevention and improved ability to recover from a problem.

Yes, an objective root cause process is a must, for hints read the 7 Secrets of Root Cause Analysis. However the reason behind the need for and the end intent of the root cause analysis is just as important. Lets start with a new idea for many doing root cause analyses today, “improved ability to recover from a problem.”


Sometimes the first action to correct a problem on the spot was like pouring water on an oil fire. Didn’t cause the fire but sure did not help the situation, and in some cases it really made the problem. Many problem solvers just look for the root causes that caused a problem and not what also made it worse.

Here are just a few examples of actions or lack of actions that made the initial problem grow larger in extent if not worse at the end of the day:

  1. Flint River Lead Exposure Delayed Response
  2. Firestone Tire Delayed Recall
  3. 1947 Explosion Caused by Incorrect Response to Initial Fire
  4. A case closer to this article writer’s life when the wrong medicine was given for heart failure of loved one: Root Cause Analysis Tip: Patient’s heart stopped twice in the Emergency Room… what was missed?

So why do I say “improved ability to recover from a problem” is a new concept for many doing root cause analyses today? Simple, many start and stay with “why did the problem occur.” Read more on how to improve the use of the more simple “why” tools if you have to use them:  A Look at 3 Popular Quick Idea Based Root Cause Analysis Techniques: 5-Whys, Fishbone Diagrams and Brainstorming.


The easiest way to improve the ability to respond to a problem is to map out a timeline for actions that occurred before the problem occurred, and the immediate responses to control or correct the problem. If the response made things worse, then perform a root cause analysis on that problem as well.


The last topic is prevention. The intent of a root cause analysis is not just to find the one “rootiest cause” or even a multitude of root causes. The intent is to find the problems and root causes that caused the problem and the problems that failed to catch/stop the problem AND THEN Eliminate or Mitigate those root causes so that future problems can be prevented or at the minimum, have the probability of the problems occurrence reduced.

When is a Root Cause NOT a Root Cause to a Sentinel Event

June 13th, 2016 by

So many times when I review Sentinel Event (SE) analyses for companies, I struggle to find the link between a Root Cause and the data on the SnapCharT®. But at the same time, the Corrective Action provided for that cause makes sense to reduce the likelihood of recurrence. This is perplexing as I did not want to say that the analysis was done poorly or was not correct simply because the outcome would probably be a positive one. Then it hit me, many people when going through the Root Cause Tree® were focusing more on the outcome desired than what the data told them.

Our ultimate goal is to fix a problem, reduce risk, and keep our patients, patients’ families and staff safe. To do so we have to present a very coherent, logical argument back to our administration regarding our analysis and findings. I represent this with the following diagram:

Specific Relationships
There is a “Specific” relationship between an Incident, the related Causal Factors, the Root Causes of those Causal Factors, and the Corrective Actions we recommend. This relationship has to be easily seen by your audience. If there is a break in that connection from the top (Incident) to the bottom (Corrective Actions) there is generally a problem with the analysis.

The issue that prompted this article relates to how people go through the Root Cause Tree®. As the user gets down to the Root Cause level I begin hearing people making declarations, “We could fix this issue by labeling the medication better” and with that statement the team puts a positive checkmark by Labels NI. What is wrong with this statement and action? Nothing upon first glance if it is true that a better label could prevent recurrence.

Digging deeper, these types of thought processes are actually working in reverse of what we teach. We teach to look at the data on the SnapCharT®, read the definitions to determine if the data supports selecting Labels NI. Based on our teachings we should hear statements such as, “Do I have an evidence (on my SnapCharT®) that tells me that the labeling present at the time of the event contributed to this Causal Factor (and thereby to the Incident)?” Notice that one quote is a question and one is a statement and therein lies a key difference. As we work through the analysis we should be questioning our data versus the definitions and items in the Root Cause Tree® not stating how we could fix the issue. Once we have the Root Cause, we can then work on a Corrective Action to fix the Root Cause.

In conclusion if we choose the Corrective Action first followed by a cause that justifies that action, the investigative team has created a break in that “Specific Relationship” from top to bottom. That break is between the Causal Factor/Root Causes and the data collected on our SnapCharT®. Without data on the SnapCharT® to support the Root Causes you present to your management team, you put your analysis in question. Without belief in the analysis management will be less likely to provide you the resources you need to fix issues and improve performance.

If you would like more information on this or any topic relating to the use of TapRooT® in Healthcare feel free to contact me directly at or at (865) 539-2139.

Root Cause Tip: Was it an Accident, an Incident, and an Event?

June 9th, 2016 by

Many years ago when I was in the Navy, I was writing an application to become an Assistant Professor at the University of Illinois. My boss was reviewing what I wrote and we got into a long discussion over whether a problem we had had was an event or an incident. A couple of years later, while I was doing my Master’s Degree research, I got into a very similar discussion over whether a significant problem at a nuclear plant was an accident or an incident.

OK, let’s look at the dictionary definitions… (from the Merriam-Webster on-line Dictionary)


  1. an unforeseen and unplanned event or circumstance
  2. lack of intention or necessity :  chance <met by accident rather than by design>
  3. an unfortunate event resulting especially from carelessness or ignorance
  4. an unexpected and medically important bodily event especially when injurious <a cerebrovascular accident>
  5. an unexpected happening causing loss or injury which is not due to any fault or misconduct on the part of the person injured but for which legal relief may be sought
  6. used euphemistically to refer to an involuntary act or instance of urination or defecation
  7. a nonessential property or quality of an entity or circumstance <the accident of nationality>


  1. something dependent on or subordinate to something else of greater or principal importance
  2. an occurrence of an action or situation that is a separate unit of experience :  happening
  3. an accompanying minor occurrence or condition :  concomitant
  4. an action likely to lead to grave consequences especially in diplomatic matters <a serious border incident>


  1. outcomeb :  the final outcome or determination of a legal actionc :
  2. a postulated outcome, condition, or eventuality <in the event that I am not there, call the house>
  3. something that happens :  occurrence
  4. a noteworthy happeningc :  a social occasion or activity
  5. an adverse or damaging medical occurrence <a heart attack or other cardiac event>
  6. any of the contests in a program of sports
  7. the fundamental entity of observed physical reality represented by a point designated by three coordinates of place and one of time in the space-time continuum postulated by the theory of relativity
  8. a subset of the possible outcomes of an experiment

So let’s make this simple …

In safety terminology, an EVENT is something that happens.

An INCIDENT is a minor accident.

An ACCIDENT is something that has serious human consequences (injury or fatality).

Thus we probably talk about:

  • lost time accidents
  • near-miss incidents
  • events that led to a near-miss

In the TapRooT® System, an Event is an action step in the sequence of events on the SnapCharT®. The Incident is the worst thing that happened in the SnapCharT® sequence of events. Thus, and Incident is a special kind of Event. Plus, if the SnapCharT® is describing a serious injury, the Incident describes the Accident. Thus an Event could be an Incident that describes an Accident!


Do you define these terms at your facility?

If so, please add your definitions as a comment here.

Root Cause Analysis on Trends

June 2nd, 2016 by

Welcome to this week’s root cause analysis tips. This week I would like to talk about root cause analysis on trends.

One of the most common discussions I have with people involves what to do with the things you do not have time to investigate. Many companies use some sort of ranking or risk matrix to determine at what point something is important enough to warrant an investigation. I have some thoughts on this…


Sometimes people try to investigate everything and end up doing poor investigations.

First of all, sometimes people try to investigate everything and end up doing poor investigations on everything; that does not help anybody. One consideration on where to draw the line is related to your current numbers. For example, if you work in a plant that has a few incidents per year, if you have the resources to investigate, I say do it. But if you are looking at large numbers at a corporate level, you may not have the resources – and you have to decide where to draw the line.

So what about the minor incidents you have that don’t get investigated – what to do with them? Well, it goes beyond minor incidents, you have other things that can be trended, rootcaused (is that a word?), and corrected. It is actually quite easy to investigate a trend, the hard part is actually collecting the data. I call this getting things in the “right bucket.” Here are some examples of information you might collect (or should):

• Minor incidents
• Near Misses
• Audit Findings
• BBS Observations

If you do a good job of collecting data, you can then trend the information. Your trends should reveal what processes are causing you pain. You then investigate the PROCESS, rather than an incident. For example, let’s say you had some near misses, some audit findings, and some BBS observations related to your lockout/tagout process that revealed issues. You may have not had a major incident yet, but you have warning signs. You can’t (or don’t have time to) go back and do full blown investigations on each data point, so you map out the process with a SnapCharT®, adding everything you know about the process as conditions, and based on that information, you identify your known failures and potential failures as Significant Issues (the equivalent to Causal Factors) in TapRooT®. Then off to the Root Cause Tree® and corrective actions. You’ve done ONE investigation on potentially dozens (or hundreds) of issues. This is more effective and much easier than doing multiple bad investigations.

Investigation of trends is a very important consideration in Audit Programs. Again, do you have time to investigate every finding? Maybe not. Here is an example:

A corporate auditor for a big box store has 100 compliance questions on a checklist and 100 locations that were audited using this checklist in the past year. That is a fair amount of data. The auditor can use this data to develop a list of top findings and then analyze the biggest issues.

The data for the yearly compliance is presented on a Pareto Chart below.

Screen Shot 2016-05-10 at 4.02.03 PM

The top two categories are related to a similar topic: required signage. The audits have revealed both missing signs and outdated signs. Let’s look at these issues together on a SnapCharT®. Significant Issues are marked with a triangle:

Screen Shot 2016-05-10 at 4.02.24 PM

Next, you take the Significant Issues through the Root Cause Tree®, and apply corrective actions. One investigation on dozens of findings.

I hate to use clichés, but WORK SMARTER NOT HARDER!

Want to learn more? I have a couple of opportunities that might interest you:

If you already collect good information and have good trending in place, consider attending the new TapRooT® for Audits Course on August 1-2.

If you are not there yet and want to learn how to collect data and trend, consider the Advanced Trending Techniques Course, also on August 1-2.

Thanks for taking the time to read the blog, and happy investigating/auditing.

Equifactor® Equipment Troubleshooting Basics

May 25th, 2016 by


Equifactor® is designed to be used to help your equipment maintenance and reliability people figure out the root causes of mechanical or electrical equipment failures.

I thought I’d take the opportunity to take us back to the basics for a moment. I’d like to describe how the Equifactor® Equipment Troubleshooting module of TapRooT® is designed to be used.

What is Equifactor®?

When performing a root cause analysis using TapRooT®, it is critical that you gather the right information for the problem at hand.  This can be safety information, environmental procedures, policies and work instructions for a particular task, etc.  It is usually pretty obvious what types of data you need for the type of investigation you’re performing.

Sometimes, additional TapRooT® data-gathering tools are required for specific types of problems.  Equifactor® is one of those tools.  It is designed to be used to help your equipment maintenance and reliability people figure out the root causes of mechanical or electrical equipment failures.

Why use Equifactor®?

During your investigation, you may find that one of your problems relates to an equipment malfunction.  For example, you might find that a compressor is vibrating above expectation.  You can put this fact into your SnapCharT®, but now what?  What do you do with this piece of information?  To get past this point in the SnapCharT®, you really need the answer from your troubleshooting team:  “Why is the compressor vibrating?”  Unfortunately, if you knew that, you wouldn’t need to put the question on your SnapCharT® in the first place!  You need to know the physical cause of the vibration in order to progress to a more detailed SnapCharT® with Causal Factors.

Equifactor® in detail

This is where Equifactor® comes in.  To help your equipment experts figure out the physical cause of the vibration, they will probably rely on their experience and local manuals for troubleshooting advice.  They’ll look at the possible causes they are familiar with, and hopefully find the problem.  However, we can’t rely on hope.  What happens when they check the items they are familiar with, and the problem is not found?  This is when they can turn to the Equifactor® troubleshooting tables for help.  The tables give a comprehensive list of possible causes of compressor vibration.  Your experts can review these tables to identify all the possible causes that apply to your compressor, and then use that list of possible causes to devise a detailed troubleshooting plan to identify the issue.  Theses tables give your maintenance team some great guidance on things to look at during their troubleshooting.  These items are quite often things that they have never seen before, and therefore did not think to look for.

Equifactor® – a TapRooT® Tool

Once your team finds the physical cause of the compressor vibration (for example, maybe the wrong coupling bolts were used, throwing off the balance of the machine), we’re not done.  Equifactor® is NOT a separate, independent tool.  It is designed to be used as a data-gathering tool for your TapRooT® investigation.  Therefore, the problem that was found (wrong coupling bolts) is now added to the original SnapCharT®, and we can now move forward with our normal TapRooT® investigation.  I’m pretty sure the bolts didn’t magically install themselves; a human was involved.  We can now discover the human performance issues that lead the mechanics to use the wrong bolts.  We continue adding information to our SnapCharT®, until we can run all of the Causal Factors (one of which will probably be, “Mechanics assembled the coupling using the wrong bolts”) through the Root Cause Tree®.  We can now apply effective corrective actions to the problem.  Instead of blaming the mechanic (“Counselled the mechanic on the importance of using the authorized repair parts during coupling assembly”), we can now target our corrective actions at the reason the mechanic used the wrong bolts (correct bolts not available, common use of “parts bins” to repair equipment, wrong part number on repair order, etc.).

Equifactor® is a terrific tool to assist your maintenance and reliability folks in finding the physical cause of a machinery problem.  It is a tool to assist you in performing your TapRooT® investigation when an equipment problem is part of that investigation.  Learn to use these tables to save you time and effort when troubleshooting your equipment issues.

LEARN MORE about Equifactor®.

CONTACT US about a course.

How Does Senior Leadership Affect RCA in Healthcare?

May 23rd, 2016 by

Across industries, senior leadership has some level of impact on every process and system.

I attended the Ohio Association of Healthcare Quality (OAHQ) Conference in Columbus last week and gave a talk on this subject. In any industry there is always some level of impact that senior leadership has on every process and system. From their expectations for the staff through their desire for the organization and business, these expectations become the guidelines within which we work.

When I talk to healthcare professionals I always hear the positive and the negative (usually in reverse order), and it is very rare that anyone is only on one side or the other. There is usually a mix. Some of the things I hear about are as follows:

Negative Impact:

  1. Unreasonable expectations for timelines in determining root causes
  2. Not providing a charter or guideline that provides the responsibilities of the team and communicates the abilities of the team/team leader
  3. Messages communicated from the Administration do not match with the “reality” of our working environment
  4. Corrective Actions that are recommended are not always implemented or followed and are substituted with managements own ideas that are not in alignment with the findings

Positive Impact:

  1. Our team feels like we are provided the necessary support to gather what we need to gather to understand the event
  2. Management supports our efforts to implement corrective and preventative measures following an adverse outcome
  3. The organization is very much a proactive group who truly want and desire to make our systems the best they can be

Now, looking at this list, we truly see how these issues are polar in ways. Different organizations have the opposite opinions from their counterparts. This is to be expected as each organization is different.

Looking at these comments and thinking towards TapRooT® and our Root Cause Tree®/Dictionary, where would these issues (if found to be causal factors) show up in the analysis? Well there is one primary area where I believe these truly match:

Management System – How Policies and the Actions of the Management System Impact the System

Of course this is not the only area that could show up as every investigation is different but these most certainly could have impact. And in addition to that, when investigating events you have to look at the outcomes (not root causes necessarily) from previous similar events. This portion of the analysis will gather data that could lead you to multiple root causes:

Management System->Corrective Actions->Corrective Action NI or Trending NI: If it is found that previous corrective actions were never implemented, or were not as effective as they could be you might be led to and those decisions were directly related to management decisions to change alter or not follow-up to see if the actions worked.

Management System->SPAC Not Used->Enforcement and/or Accountability: When examining events, if it is found that due to a lack of support from senior leadership to uphold investigative charters or uphold the level of responsibility given to the investigative team, then this could most certainly be a Management System issue.

These are just a few examples of how past performance can impact the events you investigate today. My recommendation is to always talk to people in your Management System to understand their expectation and compare that expectation to the actual messages received and heard throughout the organization. Then compare those messages to what happened during the event analysis to assess the actual impact. You might be surprised at what you uncover.

If you would like to know more about the TapRooT® process and our investigative philosophy please contact me directly at or attend one of our training courses held worldwide and learn how TapRooT can help you improve performance. Thank you for reading!

Root Cause Analysis Tip: Use the Dictionary!

May 19th, 2016 by

TapRooT® Users have more than a root cause analysis tool. They have an investigation and root cause analysis system.

The TapRooT® System does more than root cause analysis. It helps you investigate the problem, collect and organize the information about what happened. Identify all the Causal Factors and then find their root causes. Finally, it helps you develop effective fixes.

But even that isn’t all that the TapRooT® System does. It helps companies TREND their problem data to spot areas needing improvement and measure performance.

One key to all this “functionality” is the systematic processes built into the TapRooT® System. One of those systematic processes is the Root Cause Tree® and Dictionary.


The Root Cause Tree® Dictionary is a detailed set of questions that helps you consistently identify root causes using the evidence you collected and organized on your SnapCharT®.

For each node on the TapRooT® Root Cause Tree® Diagram, there is a set of questions that define that node. If you get a yes for any of those questions, it indicates that you should continue down that path to see if there is an applicable root cause. Atr the root cause level, you answer the questions to see if you have the evidence you need to identify a problem that needs fixing (needs improvement).


For example, to determine if the root cause “hot/cold” under the Work Environment Near Root Cause under the Human Engineering Basic Cause Category is a root cause, you would answer the questions (shown in the Dictionary above):

  1. Was an issue cause by excessive exposure of personnel to hot or cold environments (for example, heat exhaustion or numbness from the cold)?
  2. Did hurrying to get out of an excessively hot or cold environment contribute to the issue?
  3. Did workers have trouble feeling items because gloves were worn to protect them from cold or hot temperatures?

If you get a “Yes” then you have a problem to solve.

How do you solve it? You use Safeguards Analysis and the Corrective Action Helper® Guide. Attend one of our TapRooT® Root Cause Analysis Courses to learn all the secrets of the advanced TapRooT® Root Cause Analysis System.

The TapRooT® Root Cause Tree® Dictionary provides a common root cause analysis language for your investigators. The Dictionary helps the investigators consistently find root causes using their investigation evidence, This makes for consistent root cause analysis identification and the ability to trend the results.

The expert systems built into the Root Cause Tree® Diagram and Dictionary expand the number of root causes that investigators look for and helps investigators identify root causes that they previously would have overlooked. This helps companies more quickly improve performance by solving human performance issues that previously would NOT have been identified and, therefore, would not have been fixed.

Are you using a tool or a system?

If you need the most advanced root cause analysis system, attend one of our public TapRooT® Courses. Here are a few that are coming up in the next six months:

2-Day TapRooT® Root Cause Analysis Training

 Dublin, Ireland      June 8-9, 2016

Pittsburgh, PA   June 20-21, 2016

Hartford, CT       July 13-14, 2016

San Antonio, TX   August, 1-2, 2016

Copenhagen, Denmark September 22-23, 2016


2-Day TapRooT®/Equifactor® Equipment Troubleshooting & Root Cause Analysis Training

San Antonio, TX   August 1-2, 2016


5-Day TapRooT® Advanced Root Cause Analysis Training

Houston, TX           June 13-17, 2016

Gatlinburg, TN          June 20-24, 2016

Niagara Falls, Canada July 11-15, 2016

Monterrey, Mexico   August 22-26, 2016

Mumbai, India   August 29 – September 2, 2016

Aberdeen, Scotland  September 19-23, 2016

For the complete list of current courses held around the world, see:

To hold a course at your site, contact us by CLICKING HERE.

(Note: Copyrighted material shown above is used by permission of System Improvements.)

Using TapRooT® for Audits

May 18th, 2016 by

pablo (96)

Happy Wednesday, and welcome to this week’s root cause analysis column.

This week I wanted to share an excerpt from our new book which will be coming out on August 1st, TapRooT® Root Cause Analysis for Audits and Proactive Performance Improvement. I hope this small part of the book will help you start to think about being more proactive.

“An Ounce of Prevention is Worth a Pound of Cure.”
Ben Franklin

Around the world, professionals and companies have sought to find a better way to perform investigations on problems and losses. Many of the smartest people and leading companies use TapRooT®.

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 simple or complex accidents, difficult quality problems, hospital sentinel events, and other issues that require a complete understanding of what happened and the development of effective corrective actions. However, wouldn’t it be better if you never had to do investigations in the first place?

Many companies do perform audits. Unfortunately, in some cases, this work does not yield improvements. Why? There are many reasons, but the primary reason is lack of good root cause analysis. A company can actually be very good at finding problems, but not be effective at FIXING problems.

Beyond auditing, proactive improvement can take many forms, and when effective, becomes an overall mindset and can put an organization on the path to excellence. If that is the case, why are more companies not proactive? Here are just a few reasons:

  • Time (perceived at least)
  • They don’t have a reason to (not enough pain)
  • They do not have the buy-in (management and employee support)
  • Procrastination (human nature!)
  • They don’t know how (this is where TapRooT® comes in!)

TapRooT®, when used with auditing and proactive improvement programs, can help lead to organizational excellence and reduce the number of investigations required.

Would you like to be one of the first people to get the new book? If so, attend our new course, TapRooT® for Audits, at the Global TapRooT® Summit, August 1-2, in San Antonio. To register for the course (and the summit on August 3-5, click HERE

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

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

Fortunately, I had just been introduced to a system for incident investigation and root cause analysis…

Enmax Corporation

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

Bell South
Contact Us