Category: Root Causes

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

March 14th, 2018 by

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

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

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

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

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

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

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

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

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

February 20th, 2018 by

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

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

We hope to see you there!

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

January 31st, 2018 by

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

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

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

Knowing this…..

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

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

Where Do You Get Ideas To Improve Root Cause Analysis?

4 Signs You Need to Improve Your Investigations

Monday Accident & Lesson Learned

December 25th, 2017 by

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

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

December 14th, 2017 by

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

CLICK HERE to view the recent press release.

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

Air Date
December 17, 2017
Network and Time
Fox Business Network – 5:30pm EST
Channel Finder

My 20+ Year Relationship with 5-Why’s

December 11th, 2017 by

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

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

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

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

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

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

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

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

For more information, here are some previous blog articles:

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

Comparing TapRooT® to Other Root Cause Tools

What’s Fundamentally Wrong with 5-Whys?

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

November 3rd, 2017 by

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

Here is a quote from the report:

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


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


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


Also, from the report:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

October 23rd, 2017 by

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

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

August 30th, 2017 by


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

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

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

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

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


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

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

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


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

August 24th, 2017 by

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

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


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

Is There Just One Root Cause for a Major Accident?

July 26th, 2017 by


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

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

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

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

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

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

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

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

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

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

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

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

Why was the typo allowed to exist?

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

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

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

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

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

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

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

July 24th, 2017 by

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

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

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

Chipotle? What??!!!

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

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

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

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

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

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

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

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

What is the Root Cause of the USS Fitzgerald Collision?

July 17th, 2017 by


As a root cause analysis expert and former US Navy Officer who was qualified as a Surface Warfare Officer (SWO) and was qualified to stand underway steaming Officer of the Deck watches, I’ve had many friends ask me what was the root cause of the collision of the USS Fitzgerald.

Of course, the answer is that all the facts aren’t yet in. But that never keeps us from speculation…

But before I speculate, let’s honor the seven crew members who died as a result of this accident: Dakota Kyle Rigsby. Shingo Alexander Douglass. Ngoc T Truong Huynh. Noe Hernandez. Carlos Victor Ganzon Sibayan. Xavier Alec Martin. Gary Leo Rehm Jr.

Also, let’s note that the reason for good root cause analysis is to prevent fatalities and injuries by solving the problems discovered in an accident to keep a similar repeat accident from happening in the future.

Mia Culpa: It’s been a long time since I stood a bridge watch. I’m not familiar with the current state of naval readiness and training. However, my general opinion is that you should never turn in front of a containership. They are big. Even at night you can see them (commercial ships are often lit up). They are obvious on even a simple radar. So what could have gone wrong?

1. It was the middle of the night. I would bet that one thing that has not changed since I was in the Navy is FATIGUE. It would be interesting to see the Oficer of the Deck’s and the Conning Officer’s (if there was one) sleep schedule for the previous seven days. Fatigue was rampant when I was at sea in the navy. “Stupid” mistakes are often made by fatigued sailors. And who is to blame for the fatigue? It is built into the system. It is almost invisible. It is so rampant that no one even asks about it. You are suppose to be able to do your job with no sleep. Of course, this doesn’t work.

2. Where was the CO? I heard that the ship was in a shipping lane. Even though it was the middle of the night, I thought … where was the Commanding Officer? Our standing orders (rules for the Officer of the Deck) had us wake the CO if a contact (other ship) was getting close. If we had any doubt, we were to get him to the bridge (usually his sea cabin was only a couple of steps from the bridge). And the CO’s on the ships I was on were ALWAYS on the bridge when we were in a shipping lane. Why? Because in shipping lanes you are constantly having nearby contacts. Sometimes the CO even slept in their bridge chair, if nothing was going on, just so they would be handy if something happened. Commander Benson (the CO) had only been in his job for a month. He had previously been the Executive Officer. Did this have any impact on his relationship with bridge watchstanders?

3. Where was the CIC watch team?  On a Navy ship you have support. Besides the bridge watch team, you are supported by the Combat Information Center. They constantly monitor the radars for contacts (other ships or aircraft) and they should contact the Officer of the Deck if they see any problems. If the OOD doesn’t respond … they can contact the Commanding Officer (this would be rare – I never saw it done). Why didn’t they intervene?

4. Chicken of the Sea. Navy ships are notorious for staying away from other ships. Many Captains of commercial shipping referred to US Navy ships as “chickens of the sea” because they steered clear of any other traffic. Why was the Fitzgerald so close to commercial shipping?

5. Experience. One thing I always wonder about is the experience of the crew and especially the officers on a US Navy ship. Typically, junior officers stand Officer of the Deck watches at sea. They have from a two to three year tour of duty and standing bridge watches is one of many things they do. Often, they don’t have extensive experience as an Officer of the Deck. How much experience did this watch team have? Once again, the experience of the team is NOT the team’s fault. It is a product of the system to train naval officers. Did it play a factor?

6. Two crews. The US Navy is trying out a new way of manning ships with two crews. One crew is off while the other goes to sea. This keeps the ship on station longer than a crew could stand to be deployed. But the crew is less familiar with the ship as they are only on it about 1/2 the time. I read some articles about this and couldn’t tell if the USS Fitzgerald was in this program or not (the program is for forward deployed ships like the Fitzgerald). Was this another factor?

These six factors are some of the many factors that investigators should be looking into. Of course, with a TapRooT® investigation, we would start with a detailed SnapCharT® of what happened BEFORE we would collect facts about why the Causal Factors happened. Unfortunately, the US Navy doesn’t do TapRooT® investigations. Let’s hope this investigation gets beyond blame to find the real root causes of this fatal collision at sea.

“Human Error” by Maintenance Crew is “Cause” of NYC Subway Derailment. Two Supervisors Suspended Without Pay.

June 29th, 2017 by


The New York Daily News says that a piece of track was left between the rails during repair of track on the NYC subway system. That loose track may have caused the derailment of an eight car train.

The rule is that any track less than 19.5 feet either be bolted down or removed. It seems that others say that the “practice” is somewhat different. This piece of track was only 13.5 feet long and was not bolted down.

But don’t worry. Two supervisors have been suspended without pay. And workers are riding the railed looking for other loose equipment between the rails. Problem solved. Human error root cause fixed…

Time for Advanced Root Cause Analysis of Special Operations Sky Diving Deaths?

May 31st, 2017 by

Screen Shot 2017 05 31 at 1 20 19 PM

Click on the image above for a Navy Times article about the accident at a recent deadly demonstration jump over the Hudson River.

Perhaps it’s time for a better root cause analysis of the problems causing these accidents?

Simple 5-Whys becomes complex 5-Whys – Why not use TapRooT® Root Cause Analysis?

May 31st, 2017 by

This video doesn’t really address the problems with 5-Whys but it sure does make it more complex.

They suggest that you can brainstorm root causes. You can’t brainstorm what you don’t understand.

For a more complete discussion of why people have problems with 5-Whys, see:

An Example of 5 Whys – Is this Root Cause Analysis? Let Me Know Your Thoughts…

And for a better way to find root causes see:

About TapRooT®

To get a book that will help you understand how to really find the root causes of low-to-medium risk problems, see: 

Interviewing & Evidence Collection Tip: You can’t know the “why” before the “what”

May 31st, 2017 by

Hello and welcome to this week’s column focused on interviewing and evidence collection for root cause analysis of workplace incidents and accidents.  Last week we talked about the value of a planning SnapCharT®.  I’d like to take a moment to expand on that thought.

Grasping at the “why” before the “what” is a common mistake that even experienced investigators make.  But you have to understand “what” happened before you can understand why it happened.  The goal of interviewing and evidence collection is to provide facts for the “what” so you can continue with the “why” (identifying causal factors and root causes).

When I worked in the legal field, I felt that most investigations were hypothesis-based.  It seemed that more often than not, we started with several hypotheses and then began a process of elimination until we were left with one we liked.  Instead of collecting evidence before we determined “why” an incident happened, we came up with our guesses and then looked for evidence that supported the guesses.

When an investigator reaches for the “why” before the “what,” this is what occurs:

  1. Tunnel vision.  The investigator only focuses on the hypotheses presented, and none of them may be correct.
  2. Abuse of evidence. The investigator may force the evidence to “fit” the hypothesis he/she feels most strongly about.  Further, any evidence collected that does not fit the hypothesis is ignored or discarded.
  3. Confirmation bias. The investigator only seeks evidence that supports his/her hypothesis.

It is a tenet of psychology that the human brain immediately desires a simple pattern that makes sense of a complex situation. So, there is really nothing that the investigator is intentionally doing wrong when he or she falls into that trap. Not to mention, humans simply do not like changing their minds when they become emotionally attached to an idea. And then there is social pressure… when a strong personality on the investigation team thinks he/she knows the “why” – and the rest of the team goes along with it.

TapRooT® helps investigative teams avoid reaching for the “why” before the “what.”  The 7-Step Major Investigation Process taught during our 5-Day training offers a systematic way to move through the investigation and takes the investigator beyond his/her knowledge to determine the “what” first so that the causal factors and root causes identified are accurate. Learn how to collect the evidence you need to understand the “what” in our 1-day Interviewing and Evidence Collection Techniques course on November 8 in Houston, Texas.

Have you fallen into the trap of trying to decide the “why” before the “what”? Do you have something additional to share about this common problem? How has TapRooT® helped you avoid it? Comment below and be entered into our August drawing to win a copy of our new “Evidence Collection and Interviewing Techniques to Sharpen Investigation Skills” book!

Root Cause Tip: “Enforcement Needs Improvement” – You Can’t Train Obedience/Compliance/Positive Behavior

May 26th, 2017 by

This is a quick clarification to stop a definite no-no in poorly developed corrective actions.

You find evidence during your root cause analysis to support the root cause “Enforcement NI” based on the following statements from your Root Cause Tree® Dictionary for a particular causal factor:

  • Was enforcement of the SPAC (Standards, Policies, Administrative Controls) seen as inconsistent by the employees?
  • Has failure to follow SPAC in the past gone uncorrected or unpunished?
  • Did management fail to provide positive incentives for people to follow the SPAC?
  • Was there a reward for NOT following the SPAC (for example: saving time, avoiding discomfort).
  • When supervisors or management noticed problems with worker behavior, did they fail to coach workers and thereby leave problems similar to this causal factor uncorrected?

But then if you create a corrective action to retrain, remind, and reemphasize the rules, directed at the employee or in rare occasions the immediate supervisor, your investigation started on track and jumped tracks at the end.

Now, I am okay with an alert going out to the field for critical to safety or operation issues as a key care about reminder, but that does not fix the issues identified with the evidence above. If you use Train/Re-Train as a corrective action, then you imply that the person must not have known how to perform the job in the first place. If that were the case, root causes under the Basic Cause Category of “Training” should have been selected.

Training covers the person’s knowledge, skills and abilities to perform a specific task safely and successfully. Training does not ensure sustainment of proper actions to perform the task; supervision acknowledgement, reward and discipline from supervision, senior leadership and peers ensure acceptance and sustainment for correct task behaviors.

Don’t forget, it is just as easy for supervision to ignore unsafe behavior as it is for an employee to deviate from a task (assuming the task was doable in the first place). Reward and discipline applies to changing supervision’s behavior as well.

Something else to evaluate. If the root cause of Enforcement NI shows up frequently, make sure that you are not closing the door prematurely on the Root Cause Tree® Dictionary Near Root Causes of:

  • Oversight/Employee Relations (Audits should be catching this and the company culture should be evaluated).
  • Corrective Actions (If you tried to fix this issue before, why did it fail?).

Remember, you can’t train obedience/compliance/positive behavior. Finally, if you get stuck on developing a corrective active for Enforcement NI or any of our root causes, stop and read your Corrective Action Helper®.  

Learn more by attending one of our upcoming TapRooT® Courses or just call 865.539.2139 and ask a question if you get stuck after being trained.

Root Cause Analysis Resource for Low-to-Medium Risk Incidents

May 11th, 2017 by

Our recent release, Using the Essential TapRooT® Techniques to Investigate Low-to-Medium Risk Incidents, is in it’s second printing! This popular book helps investigators develop a clear sequence of events, identify causal factors, find the real root causes and develop corrective actions that work.

Course attendees also receive this book in our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training and our 2-Day TapRooT® Root Cause Analysis training.  The book may also be purchased from the web store as part of a set (with our Major Investigation book):

It is the most practical tool any investigator can have on his/her desk to refresh his/her knowledge and is written in an easy-to reference format.  Do you have a copy of the new book?  Comment below with your thoughts.


What Would You Do If You Saw a Bad 5-Why Example?

April 19th, 2017 by

It seems that I’m continually confronted by folks that think 5-Whys is an acceptable root cause analysis tool. 

The reason they bring up the subject to me is that I have frequently published articles pointing out the drawbacks of 5-Whys. Here are some examples…

Article in Quality Progress: Under Scrutiny (page 32)

An Example of 5 Whys – Is this Root Cause Analysis? Let Me Know Your Thoughts…

What’s Fundamentally Wrong with 5-Whys?

Teruyuki Minoura (Toyota Exec) Talks About Problems with 5-Whys

That got me thinking … Have I EVER seen a good example of a 5-Why root cause analysis that I thought was a good example of a root cause analysis? And the answer was “NO.”

So here is my question … 

What do you do when you see someone presenting a bad root cause analysis where they are missing the point?

Leave a comment below and let me know the tack that you take … What do you think?

Are you attending the ASQ World Conference on Quality in Charlotte?

April 19th, 2017 by

If you are attending the conference, please stop by the TapRooT® Booth (#213) and say hello. Chris Vallee, Per Ohstrom, and I will be there.

The first 500 visitors will receive a special gift, the world’s fastest root cause analysis tool!

Bring a business card and enter the drawing for cool TapRooT® stuff during the Tuesday exhibit hall extravaganza.

Want to see the new TapRooT® VI 6.2.0 software? Come by on Tuesday from 09:00-1:30 and we’ll be happy to walk through a quality example for you.

See you then!

Why Does TapRooT® Exist?

March 28th, 2017 by


If you are a TapRooT® User, you may think that the TapRooT® Root Cause Analysis System exists to help people find root causes. But there is more to it than that. TapRooT® exists to:

  • Save lives
  • Prevent injuries
  • Improve product/service quality
  • Improve equipment reliability
  • Make work easier and more productive
  • Stop sentinel events
  • Stop the cycle of blaming people for system caused errors

And we are accomplishing our mission around the world.

Of course, there is still a lot to do. If you would like to learn more about using TapRooT® Root Cause Analysis to help your company accomplish these things, get more information about TapRooT® HERE or attend one of our courses (get info HERE).

If you would like to learn how others have used TapRooT® to meet the objectives laid out above, see the Success Stories at:

Why do Audits fail and why do I have so many repeat findings? Take a detour!!!

March 27th, 2017 by

Have you ever performed an audit and got frustrated when you found the same issues as the last audit? I feel your pain….we all have. Why does this happen so much? Because most companies audit programs look a little like this:

Screen Shot 2017-03-27 at 4.00.54 PM

Q: What is missing from this picture?

A: Root Cause Analysis, of course!!

Many companies actually have good programs for FINDING problems without having a good program for FIXING problems. If you want problems fixed, root cause analysis has to be part of it. So on the road to improvement, take a DETOUR to Root Cause Land!

Screen Shot 2017-03-27 at 4.13.20 PM

For your program to be effective, it should look more like this:

Screen Shot 2017-03-27 at 4.04.23 PM

The best way to do root cause analysis on audits? TapRooT®.

We have a new course, TapRooT® for Audits, that we will be holding in Charlotte, NC on May 4-5. Why not join us? For more information and to register, click HERE

How can TapRooT® help with your ISO programs (or other management system issues)?

January 25th, 2017 by

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

Many companies are ISO certified and some of those that are not have some type of management system. There are too many different systems and standards out there to discuss individually, but one of the common themes is continuous improvement.

Whether you use a commonly known management system or developed your own, one of your goals should be to improve your system/business. When I think of a management system, I think of it as a framework for how you manage your business. Whether required or not, incorporating continuous improvement is a smart thing to do.

While ISO has hundreds of standards, some of the most commonly known are 9000 (Quality) and 14000 (Environmental); coming down the pike soon is 45001 (Safety). There are also numerous industry specific standards. Many of the ISO standards use a common framework that includes the PDCA (plan, do, check, act) cycle. This is where TapRooT® can help.

PDCA is a simple process that has been in use widely since the 1950’s. I do not know many processes that have endured that long. So why? Because it is easy and it works.


As part of PDCA, you have to determine what to fix, how to fix it, and whether it works. Sounds a little like root cause analysis and corrective action, doesn’t it? So if you were going to use PDCA to help solve your problems, what would you use for root cause analysis? If I were you, I would use TapRooT®. Need help with corrective actions? Use the Corrective Action Helper®, SMARTER Matrix, and Safeguards hierarchy. You can incorporate TapRooT® tools into any improvement framework you use.

Also, don’t forget the importance of auditing. This should be part of your management system as well. We’ve taught auditing with TapRooT® for years, but we recently developed a new course specifically for Auditors, TapRooT® for Audits, and wrote a new book, TapRooT® Root Cause Analysis for Audits and Proactive Performance Improvement. The primary topic of the book is auditing, but we also have a short section on PDCA. We’ll be teaching this course in Charlotte, NC in May if you would like to join us. Or, if you are already TapRooT® trained, you can get the book on our store.

Audits Kit

Thanks for reading the blog, and best of luck with your improvement efforts.

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.

Connect with Us

Filter News

Search News


Angie ComerAngie Comer


Anne RobertsAnne Roberts


Barb CarrBarb Carr

Editorial Director

Chris ValleeChris Vallee

Human Factors

Dan VerlindeDan Verlinde

VP, Software

Dave JanneyDave Janney

Safety & Quality

Garrett BoydGarrett Boyd

Technical Support

Ken ReedKen Reed

VP, Equifactor®

Linda UngerLinda Unger


Mark ParadiesMark Paradies

Creator of TapRooT®

Per OhstromPer Ohstrom

VP, Sales

Shaun BakerShaun Baker

Technical Support

Steve RaycraftSteve Raycraft

Technical Support

Wayne BrownWayne Brown

Technical Support

Success Stories

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


Fortunately, I already had a plan. I had previously used TapRooT to improve investigations…

Bi-State Development Corporation
Contact Us