Author Archives: Mark Paradies

Strange Aviation Incident

Posted: August 16th, 2018 in Accidents, Current Events, Video

Imagine your corporate safety investigation of this…

Can Your Management Learn?

Posted: August 15th, 2018 in Human Performance, Performance Improvement, Pictures


Long ago, my boss was tasked with reviewing the Challenger space shuttle accident for lessons learned for a major chemical company. I assisted him and his conclusion was that all the same management system causes were present at our company.

He had a dilemma. How should he present this to senior management? He would be presenting to the company President and all the Senior Vice Presidents. He knew they were NOT expecting to here that they had problems. This might severely hurt his career.

He decided to just present the “facts” and that they would reach the same conclusions that he did.

He made the presentation. I was there. At the end, the President of the company thanked him for his hard work and said to everyone else that it was good that there was no similarities between NASA’s management and our company’s management. In other words, no lessons for us.

So much for just presenting the facts.

Why didn’t senior management reach the same conclusions that my boss did when presented with the same facts? The problem was that our management couldn’t critically review their own management systems. They thought that they were doing great and any other feedback was outside their paradigm. They were not being self-critical. They could not face the facts. And no one else was willing to tell them that they needed to improve (lot’s of “yes men” around them).

Of course, NASA’s management didn’t learn their lesson. They went on to have the Colombia shuttle accident because they didn’t learn from their experience and could not face the facts.

Another example of management not being able to learn was the BP’s management after the BP Texas City Refinery explosion.

First, they had a hard time getting past blaming the operators and supervisors (five were fired). There was an internal BP group (the Bonse report – see Bonse Main Report.pdf) that recommended management discipline (blaming the lower levels of senior management). However, no immediate disciplinary action was taken. Within two years, all the senior line management from the Refinery General Manager to the CEO were gone (none were fired immediately as part of the incident response). So the ability of that management to learn didn’t make any difference – they were gone!

However, managers on the upstream (exploration and production) side of the organization, didn’t seem to learn from the the accident on the downstream side of the organization. The result? The BP Deepwater Horizon accident happened because of failure to apply process safety lessons learned to the management of exploration operations.

These examples of failures to learn are the reasons why I ask the question in the title of this article:

Can your management learn?

That brings up the question:

What should managers do to learn?

Here are some ideas…

First, management has to be self-critical. Instead of blaming people at the pointy end of the stick (operators, maintenance people, and supervisors), they should say…

What did we do to cause this incident?
What should we do differently to prevent future incidents?

Being self-critical also means understanding Rickover’s “Facing the Facts” concept. See more about that concept at:

Second, senior management needs to understand root cause analysis. This may be more common today than it was thirty plus years ago because more senior managers have had some experience with advanced root cause systems (TapRooT®). They need to understand their (management’s) impact on management systems and their impact on investigations and implementation of corrective actions.

Management may also need to understand advanced trending concepts (we are publishing a book later this year about this) to be able to learn from their company’s statistics (or at least be critical of presentations about statistics).

What ideas do you have? Leave them as comments to share with others.

What’s Wrong with Pharmaceutical Root Cause Analysis?

Posted: August 8th, 2018 in Current Events, Investigations, Root Cause Analysis Tips, Root Causes


I was forwarded a copy of an interesting letter about American and Canadian Standards Boards with certifying bodies rejecting pharmaceutical quality incident reports because of poor root cause analysis. It stated that 90% of the rejections of reports were due to three types of root causes that were unacceptable (and I quote):

  1. Employee Error / Human Error / Operator Error OR anyone else who made an error is not an acceptable root cause – Was the training ineffective?  Was the procedure too vague?
  2. Misunderstood the requirement / Did not know it was a requirement / Our consultant told us this was ok OR any other misunderstandings is not an acceptable root cause.  Was the training effective?
  3. We had a layoff / Mona was on maternity leave / we moved locations / we scaled back production / we are still closing out Wayne’s 40 deviations from the last audit OR most other employee or business conditions are not acceptable root causes  They are DIRECT CAUSES.

The letter proposed four rules to follow with all future submissions:

  1. RULE #1:  The root cause can not be a re-statement of the deviation.  Example:  Deviation – Company XYZ did not document Preventive Actions as required by procedure.  Root Cause – We did not document Preventive Actions as required by the procedure.
  2. RULE #2:  There can not be an obvious “Why” that can be easily answered to the provided root cause – in this case they have not gone deep enough.  Example: Root Cause – The purchasing coordinator made a mistake and did not check to see if the supplier was approved.  Obvious “WHY” Was the training effective?  Did the procedure provide enough detail in this area?
  3. RULE #3:  The root cause can not be a direct cause.  Example:  Deviation – There were a number of internal audits scheduled for 2008 that were not completed.  Root Cause – We had a layoff and we did not have enough Internal Auditors to conduct the audits.
  4. RULE #4:  The root cause is a brief description of the cause of the problem.  We do not want any long stories regarding direct causes or what they are doing well even though this happened or who said what.  This is un-necessary detail and only adds confusion.

Wow! I would have thought this guidance would not be necessary. Are responses to quality incidents really this poor? Or is this letter a fake?

No wonder TapRooT® Users have no problem getting approvals for their root cause analysis. None of these problems would happen with any investigation using TapRooT®.

Why would TapRooT® Users never stop at the three causes listed above? Because they would understand that some are Causal Factors (the start of the root cause analysis) and they would have guidance provided by the Root Cause Tree® Diagram to help them find the real, fixable root causes of human performance and equipment failure related problems. This includes analyzing things like “internal audits not completed”; “human error”; and “misunderstood requirements.”

In addition, the TapRooT® Software helps investigators develop concise custom reports that only includes the details needed to understand what happened, how it happened, the root causes, and the effective corrective actions needed to prevent recurrence.

If you are in the pharmaceutical industry and you want to stop having problems with root cause analysis and want to start having effective investigations, root cause analysis, and fixes for problems, attend our TapRooT® Training and learn how simple advanced root cause analysis is.

The Reality of High-Reliability Organizations

Posted: August 1st, 2018 in Performance Improvement, Pictures

For the past decade, I’ve seen people write about their ground breaking high-reliability organization research. It often makes me chuckle because I’ve worked in a high-reliability organization and what the researchers “learn” isn’t always what is really going on.

First, let me say that my high-reliability organization experience was in Admiral Rickover’s Nuclear Navy. Seven years and two ships – the USS Arkansas and the USS Long Beach – both nuclear powered cruisers. I had close friends on submarines and nuclear-powered carriers. To learn more about the Nuke Navy record and Rickover’s philosophy, read the series of article at:

So what is the difference between the research and reality? Here are some of the ideas to consider…

1. Real high-reliability organizations vs fake high-reliability organizations.

Rickover’s Nuclear Navy was the original high-performance organization. In my experience, there isn’t anything that comes close. I’ve seen research that described carrier flight deck operations as a high-reliability organization. But from the accidents and injuries I’ve seen or heard about, I just don’t think they meet the standard.

That brings up a question. What is the standard?

I think the answer is ZERO. Rickover’s Nuclear Navy was (and still is even after he is gone for almost forty years) an organization that achieves the amazing record of ZERO reactor safety related accidents. There were no fatalities, no major releases of radioactive material, and no core-melt accidents. And this record was set during Rickover’s leadership when the Navy was running hundreds of reactor at sea every year. Today that’s a record of sixty years of continuous operation of many nuclear reactors without a major reactor related accident.

If you are in the process industry, think of this as all the US refineries having no fires or explosions or significant environmental releases for 60 years.

For carrier aviation to qualify as a high reliability organization, they would have to have zero flight deck related fatalities, explosions, or aviation related crashes on all the US carriers for years. As far as I know, they don’t achieve this record for a single year (usually not a single deployment).

Therefore, if you are going to learn from a high-reliability organization, make sure it is a real high-reliability organization.

2. High-Reliability Organizations aren’t good at everything.

Rickover’s Nuclear Navy record for reactor safety was amazing. However, submarine or nuclear surface ship industrial safety was pretty average. Thus, the same excellence emphasis was not applied to everything.

Let’s use a sports example. If you are a great athlete, you have the chance to excel at a sport. But you probably can’t be good at every sport. The world’s greatest basketball player may not be able to switch over and become the worlds greatest baseball player … or golfer. They might be better than average but they probably won’t be great.

Why? Because being great requires focus. If your focus becomes too broad, you lose your focus and performance slips. Thus, you can talk about high-reliability organizations like they are great at everything, but they probably aren’t. They probably focus their attention to become great.

3. The high COST for exceptional excellence.

You can ask the Nuke Navy sailors about the cost of excellence:

  • 12 to 18 hour days
  • failed marriages
  • burnout

Recruiting the exceptional sailors required to meet the highest standards wasn’t easy (and still isn’t easy). There is a financial bonus to keep Nuke Navy sailors in the Nuke Navy. This is a significant chunk of change to keep the best from being recruited away because the average sailor just didn’t cut it in the Nuclear Navy.

4. Weak Signals

Research about high-reliability organizations describes detecting “weak signals” that indicated problems. Let me put this straight. If you are in a high-reliability organization, those signal aren’t weak. They scream out at you.

The problem is that non-high-reliability organizations have on a double set of hearing protection. Many don’t hear or see the signals until dead bodies pile up at their feet.

There is no secret to hearing the signals. If you know what makes your systems highly reliable, then you make sure that these important factors are looked after, maintained, and nurtured. The Rickover article linked to above lays out these factors for the Nuclear Navy (and they are the same factors that apply in process safety).

Here’s an example…

If the budget is cut so that you start getting a maintenance backlog, that isn’t a weak signal. Management high and low should be hearing the signal (there is a maintenance backlog).

If the budget is cut so much that safety significant maintenance isn’t getting done, the system is screaming at you. (This should be monitored and discussed in weekly management meetings.)

If you are having precursor incidents because of deferred maintenance, the top management (the COO) should know about it and should be demanding changes.

Thus weak signals aren’t weak if you are a high-reliability organization.

And if you think they are weak signals – you aren’t in a high-reliability organization.

That’s a start. I’ll stop here and not belabor the point.

Living high-reliability and
researching high-reliability
are two quite different experiences.

If I was going to get advice about becoming a high-reliability organization (quite a challenge if you aren’t one), I would talk to someone who lived in a high-reliability organization and who also has worked at a non-high-reliability organization. Or, better yet, I would hire that person to help lead the effort. I would not become part of someone’s university research detached from the experience of living in the organization.

But be ready for difficulties and major change. Talking about high-reliability is much easier than living high-reliability.

Just my advice … take it or leave it.

Why Does Blame “Make Sense”?

Posted: July 25th, 2018 in Accidents, Human Performance, Investigations, Performance Improvement, Pictures, Root Cause Analysis Tips, TapRooT

Think about a recent accident …

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

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

someone screwed up!

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

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

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

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

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

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

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

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

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

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

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

What is a mystery incident?

A refinery plant manager told me this story:

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

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

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

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

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

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

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

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

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

How Does the FDA Decide What Facilities to Inspect?

Posted: July 24th, 2018 in Quality

The FDA uses a site selection model (SSM) based on FDASIA section 705. Here is the model …


So what can you do to reduce your FDA inspection frequency? Have better performance!

First, with better quality performance you will have less compliance issues – the first criteria.

Second, with better quality performance you will have less recalls – the second criteria.

Third, with better quality performance you will have a better inspection history – the fourth criteria.

Thus, by improving quality performance, you will reduce the resources required to deal with FDA inspections.

How do you have better quality performance?

One major factor is the quality of your root cause analysis and CAPA program.

TapRooT® Root Cause Analysis can help your facility achieve excellence in root cause analysis and have a world-class CAPA program.

For more about TapRooT® Root Cause Analysis Training, see:

The Best Incident Investigation Performance Indicator

Posted: July 18th, 2018 in Investigations, Performance Improvement, Root Cause Analysis Tips


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

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

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

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

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

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

Here are two examples:

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

You be the judge.

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

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

Management System

Posted: July 11th, 2018 in RCA Tip Videos, Root Causes, TapRooT

Screen Shot 2018 05 24 at 10 02 52 PM

Back in 1985, my boss suggested I (Mark Paradies) look at better ways to analyze and trend root causes. I already understood human factors (from training for my master’s degree from the University of Illinois) and equipment reliability (from my experience in the Nuclear Navy). Therefore, I had a good start on the knowledge I needed to develop a system for root cause analysis.

The very first system I developed had a category (today we would call it a Basic Cause Category) of Leadership.

When I showed the system to my boss and he saw the Leadership category, he said:

“You have to take that out.”

He explained that senior management would go nuts if we said there was a leadership issue. We argued for quite a while. I said that management would just have to accept that they, too, could improve. He explained that I had done such a good job NOT having blame categories in the system that I shouldn’t have a blame category for leadership and that’s how the company’s management would view a Leadership category.

Eventually, he convinced me that we could come up with a better name. He wanted to call it “Organizational Factors.” I said that it should be “Management.” He said that was just as bad as Leadership. He wanted to call it “Systems.” I thought that clouded the responsibility for where the changes needed to be made. Finally I suggested “Management System.” It took a while, but he finally agreed.

After several management presentations and several discussions with senior management, we finally got approval for the “Management System” category.

Little did I know that we had invented a term that would be used around the world.

The first place it spread to was INPO (Institute of Nuclear Power Operation). I had interviewed for a job there and they had tried to hire me but I had already taken another job. However, I stayed in contact with Joe Bishop who was in charge of developing the HPES (Human Performance Evaluation System) system for INPO. When they had a version of the system ready, he sent me a copy for review. I commented that they had missed the Management System causes. Sure enough, my work on Management System made it into INPO’s HPES system.

From there, the terminology spread throughout the U.S. nuclear industry and to nuclear plants around the world.

Once I started System Improvements in 1988, the terminology started spreading to other industries. Refining, chemicals, oil exploration and production, and other industries. By the early 1990s, TapRooT® was adopted by industry leaders around the world. And the terminology “Management System” went with it.

Then, I began hearing the term at professional society meetings. People started insisting that to find root causes you needed to find “management system” causes. I thought this was interesting. Where had the term “management system” come from?

I researched the term on the internet and couldn’t find any references prior to the meeting I had with my boss back in 1986. In fact, it looked like the terminology had started to be used in the mid-1990s.

I can’t prove it but I think the terminology came from that meeting with my boss, Rod Satterfield. And that is how the Management System terminology got started.

If you would like to learn more about the Management System, all you need to do is read about it in the TapRooT® Root Cause Tree® Dictionary. You will receive a copy of the dictionary and will learn how to use it in any of our TapRooT® 2-Day or 5-Day Courses.

Monday Accident & Lessons Learned: Fatal Accident While Unloading a Truck

Posted: July 9th, 2018 in Accidents, Current Events, Pictures, Video

WKBW TV reported that two employees were killed when a stack of Corian counter tops that weighed 800 pounds per slab (11 slabs total) fell on them. The accident occurred at 1:30 a.m. and the employees were pronounced dead at the scene.

The company issued a statement that said:

“We’re saddened to report that a tragic accident occurred this morning at our facility in Lockport, NY that resulted in the death of two of our colleagues. We’re working with our safety team and local law enforcement to understand the circumstances under which this tragedy occurred. Our deepest sympathies are with their families and our Lockport team members.”

OSHA will be conducting an investigation of the deaths. OSHA has investigated two other serious injuries at XPO facilities elsewhere in New York state.

What was the Hazard in this accident?

The heavy, high-piled load.

Who were the targets?

The two employees.

What were the Safeguards?

From the newspaper articles, we don’t know.

We also don’t know any of the reasons for the Safeguard’s failure.

The root cause analysis will have to determine the Safeguards, why they failed, and if they were sufficient. (Do we need additional Safeguards?)

In the TapRooT® System, a SnapCharT® would be used to collect and organize the information about what happened.

Then the failed Safeguards would be identified.

Next, the failed Safeguards (Causal Factors) would be analyzed to find their root causes using the Root Cause Tree® Diagram.

Once the root causes for all the Safeguards were found, the team would start developing corrective actions.

The Safeguards would be reviewed to see if after they were strengthened, if they would be adequate. If they would not be adequate, either additional Safeguards would be developed or the process could be modified to reduce or remove the hazard. For example, stack the counter tops no more that 16 inches high.

To improve the Safeguards that failed, you would address each of the root causes by developing SMARTER corrective actions using the Corrective Action Helper® Module of TapRooT® Software.

What is a SMARTER corrective action?








To learn more about the TapRooT® System, SnapCharT®, Safeguard Analysis, Causal Factors, the Root Cause Tree® Diagram, the Corrective Action Helper® Module, the TapRooT® Software, and SMARTER, attend one of our 2-Day or 5-Day TapRooT® Courses. Here is a list of the dates and locations of the courses being held around the world:

Happy 4th of July

Posted: July 4th, 2018 in Current Events, Pictures


In the US we celebrate declaring our independence from The British crown on the 4th of July. It was a great risk for a minor colony to stand up to the world’s mightiest power. Perhaps were were foolish or you might say reckless … but the outcome was a system without a king and with a constitution that affirmed and guaranteed our God given rights.

So today when you are celebrating somewhere in the US, remember those who risked all for the freedoms we enjoy today and those who stand ready to do that today.

Happy Independence Day!

One Safeguard Eliminated = Death

Posted: July 3rd, 2018 in Accidents, Current Events, How Far Away Is Death?, Video

Watch the video and see what could have been done to avoid a fatality…

I think there was an obvious Safeguard missing. What was it?

Practice, Feedback, & Improve (Develop Skills)

Posted: June 27th, 2018 in Courses, Performance Improvement, Pictures, Root Cause Analysis Tips, TapRooT, Training

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

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

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

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

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

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

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

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

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

Monday Accident & Lessons Learned: What Does a Human Error Cost? A £566,670 Fine in the UK!

Posted: June 25th, 2018 in Accidents, Current Events, Human Performance, Performance Improvement, TapRooT

Dump truck(Not actual truck, For illustration only.)

The UK HSE fined a construction company £566,670 after a dump truck touched (or came near) a power line causing a short.

No one was hurt and the truck suffered only minor damage.

The drive tried to pull forward to finish dumping his load and caused a short.

Why did the company get fined?

“A suitable and sufficient assessment would have identified the need to contact the Distribution Network Operator, Western Power, to request the OPL’s were diverted underground prior to the commencement of construction. If this was not reasonably practicable, Mick George Ltd should have erected goalposts either side of the OPL’s to warn drivers about the OPL’s. “

That was the statement from the UK HSE Inspector as quoted in a hazarded article.

What Safeguards do you need to keep a simple human error from becoming an accident (or a large fine)?

Performing a Safeguard Analysis before starting work is always a good idea. Learn more about using Safeguard Analysis proactively at our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Course. See the upcoming public course dats around the world at:

The History of the Definition of a Root Cause

Posted: June 20th, 2018 in Performance Improvement, Root Cause Analysis Tips, TapRooT


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

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


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

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


A root cause is
the most basic cause (or causes)
that can reasonably be identified
that management has control to fix
and, when fixed, will prevent
(or significantly reduce the likelihood of)
the problem’s recurrence.

That definition was starting to be a mouthful.

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

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


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

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

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

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

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

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

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

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

Monday Accident & Lessons Learned: Why is Right of Way Maintenance Important?

Posted: June 18th, 2018 in Accidents, Current Events, Equipment/Equifactor®, Investigations, Pictures

Here is another example of why right of way maintenance is important for utility transmission and distribution departments …


An article on hazardex reported that the California Department of Forestry and Fire Protection (Cal Fire) said in a press release that 12 of the wildfires that raged across California’s wine country were due to tree branches touching PG&E power lines.

Eight of the 12 fires have been referred to county District Attorney’s offices for potential criminal prosecution for alleged violations of California laws.

The fires last October killed 44 people, burned more than 245,000 acres, and cost at least $9.4 billion dollars of insured losses. PG&E has informed it’s shareholders that it could be liable costs in excess of the $800 million in insurance coverage that it has for wildfires.

PG&E is lobbying state legislators for relief because they are attributing the fires to climate change and say they should not be held liable for the damage.

What lessons can you learn from this?

Sometimes the cost of delayed maintenance is much higher than the cost of performing the maintenance.

Can you tell which maintenance is safety critical?

Do you know the risks associated with your deferred maintenance?

Things to think about.

TapRooT® Users – Use It ALL

Posted: June 13th, 2018 in Performance Improvement, Pictures, Root Cause Analysis Tips, Summit, TapRooT


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

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

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

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

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

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

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

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

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

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

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

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

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

New Study Suggests Poor Officer Seamanship Training Across the Navy – Is This a Generic Cause of 2017 Fatal Navy Ship Collisions?

Posted: June 7th, 2018 in Accidents, Current Events, Human Performance, Investigations, Pictures


It is hard to do a root cause analysis from afar with only newspaper stories as your source of facts … but a recent The Washington Times article shed some light on a potential generic cause for the fatal collisions last year.

The Navy conducted an assessment of seamanship skills of 164 first-tour junior officers. The results were as follows

  • 16% (27 of 164) – no concerns
  • 66% (108 of 164) – some concerns
  • 18% (29 of 164) – significant concerns

With almost 1 out of 5 having significant concerns, and two thirds having some concerns, it made me wonder about the blame being placed on the ship’s Commanding Officers and crew. Were they set up for failure by a training program that sent officers to sea who didn’t have the skills needed to perform their jobs as Officer of the Deck and Junior Offiicer of the Deck?

The blame heavy initial investigations certainly didn’t highlight this generic training problem that now seems to be being addressed by the Navy.

Navy officers who cooperated with the Navy’s investigations faced court martials after cooperating.


According to and article in The Maritime Executive Lt j.g. Sarah Coppock, Officer of the Deck during the USS Fitzgerald collision, pled guilt to charges to avoid facing a court martial. Was she properly trained or would have the Navy’s evaluators had “concerns” with her abilities if she was evaluated BEFORE the collision? Was this accident due to the abbreviated training that the Navy instituted to save money?

Note that in the press release, information came out that hadn’t previously been released that the Fitzgerald’s main navigation radar was known to be malfunctioning and that Lt. j.g. Coppock thought she had done calculations that showed that the merchant ship would pass safely astern.


In other blame related news, the Chief Boatswains Mate on the USS McCain plead guilty to dereliction of duty for the training of personnel to use the Integrated Bridge Navigation System, newly installed on the McCain four months before he arrived. His total training on the system was 30 minutes of instruction by a “master helmsman.” He had never used the system on a previous ships and requested additional training and documentation on the system, but had not received any help prior to the collision.

He thought that the three sailors on duty from the USS Antietam, a similar cruiser, were familiar with the steering system. However, after the crash he discovered that the USS McCain was the only cruiser in the 7th fleet with this system and that the transferred sailors were not familiar with the system.

On his previous ship Chief Butler took action to avoid a collision at sea when a steering system failed during an underway replenishment and won the 2014 Sailor of the Year award. Yet the Navy would have us believe that he was a “bad sailor” (derelict in his duties) aboard the USS McCain.


Also blamed was the CO of the USS McCain, Commander Alfredo J. Sanchez. He pleaded guilty to dereliction of duty in a pretrial agreement. Commander Sanchez was originally charged with negligent homicide and hazarding a vessel  but both other charges were dropped as part of the pretrial agreement.

Maybe I’m seeing a pattern here. Pretrial agreements and guilty pleas to reduced charges to avoid putting the Navy on trial for systemic deficiencies (perhaps the real root causes of the collisions).

Would your root cause analysis system tend to place blame or would it find the true root and generic causes of your most significant safety, quality, and equipment reliability problems?

The TapRooT® Root Cause Analysis System is designed to look for the real root and generic causes of issues without placing unnecessary blame. Find out more at one of our courses:

Is Blame Built Into Your Root Cause System?

Posted: June 6th, 2018 in Human Performance, Performance Improvement, Pictures, Root Cause Analysis Tips, Root Causes, TapRooT


If you want to stop good root cause analysis, introduce blame into the process.

In recent years, good analysts have fought to eliminate blame from root cause analysis. But there are still some root cause systems that promote blame. They actually build blame into the system.

How can this be? Maybe they just don’t understand how to make a world-class root cause analysis system.

When TapRooT® Root Cause Analysis was new, I often had people ask:

“Where is the place you put ‘the operator was stupid?'”

Today, this question might make you laugh. Back in the day, I spent quite a bit of time explaining that stupidity is not a root cause. If you hire stupid people, send them through your training program, and qualify them, then that is YOUR problem with your training program.

The “stupid people” root cause is a blame-oriented cause. It is not a root cause.

Logo color no lines no text copy

What is a root cause? Here is the TapRooT® System definition:

Root Cause
The absence of best practices
or the failure to apply knowledge
that would have prevented the problem. 

Are there systems with “stupid people” root causes? YES! Try these blame categories:
    • Attitude
    • Attention less than adequate
    • Step was omitted due to mental lapse
    • Individual’s capabilities to perform work less than adequate
    • Improper body positioning
    • Incorrect performance due to a mental lapse
    • Less than adequate motor skills
    • Inadequate size or strength
    • Poor judgment/lack of judgment/misjudgment
    • Reasoning capabilities less than adequate
    • Poor coordination
    • Poor reaction time
    • Emotional overload
    • Lower learning aptitude
    • Memory failure/memory lapse
    • Behavior inadequate
    • Violation by individual
    • Inability to comprehend training
    • Insufficient mental capabilities
    • Poor language ability
    • In the line of fire
    • Inattention to detail
    • Unawareness
    • Mindset

You might laugh at these root causes but they are included in real systems that people are required to use. The “operator is stupid” root cause might fit in the “reasoning capabilities less than adequate,” the “incorrect performance due to mental lapse,” the “poor judgment/lack of judgment,” or the “insufficient mental capabilities” categories.

You may ask:

“Couldn’t a mental lapse be a cause?”

Of course, the answer is yes. Someone could have a mental lapse. But it isn’t a root cause. Why? It doesn’t fit the definition. It isn’t a best practice or a failure to apply knowledge. We are supposed to develop systems that account for human capabilities and limitations. At best, a memory lapse would be part of a a Causal Factor.

To deal with human frailties, we implement best practices to stop simple memory lapses from becoming incidents. In other words, that’s why we have checklists, good human engineering, second checks when needed, and supervision. The root causes listed on the back side of the TapRooT® Root Cause Tree® are linked to human performance best practices that make human performance more reliable so that a simple memory lapse doesn’t become an accident.

What happens when you make a pick list with blame categories like those in the bulleted list above? The categories get overused. It is much easier to blame the operator (they had less than adequate motor skills) than to find out why they moved the controls the wrong way. Its easy to say there was a “behavior issue.” It is difficult to understand why someone behaved the way they did. TapRooT® looks beyond behavior and simple motor skill error to find real root causes.

We have actually tested the use of “blame categories” in a system and shown that including blame categories in an otherwise good system causes investigators to jump to conclusions and select these “easy to pick” blame categories rather than applying the investigative effort required to find real root causes.

You may think that if you don’t have categories, you have sidestepped the problem of blame. WRONG! Blame is built into our psyche. Most cause-and-effect examples I see have some blame built into the analysis.

If you want to successfully find the real, fixable root causes of accidents, precursor incidents, quality issues, equipment failures, cost overruns, or operational failures, don’t start by placing blame or use a root cause system with built-in blame categories. Instead, use advanced root cause analysis – TapRooT®.

The best way to learn about advanced root cause analysis is in a 2-Day TapRooT® Root Cause Analysis Course or a 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Course. See the list of upcoming public courses here:

Why do we still have major process safety accidents?

Posted: May 30th, 2018 in Accidents, Performance Improvement, Pictures, Root Cause Analysis Tips, TapRooT

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

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

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

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

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

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

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

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

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

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

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

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

And that got me thinking …

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

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

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

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

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

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

Why is TapRooT® Root Cause Analysis Software the Best Choice?

Posted: May 23rd, 2018 in Software, TapRooT

Screen Shot 2018 05 04 at 12 23 16 PM

If you are looking for the best root cause analysis software, here are some things to consider:

  1. How the software works is important, but the root cause analysis system that the software uses is probably THE MOST IMPORTANT part of picking your software. No matter how well a bad root cause tool is implemented in software … it is still a bad root cause analysis tool. Therefore, you should look for a world-class root cause analysis tool.
  2. It’s all in the cloud, baby! The days of software just working on one operating system are over. Now your software should be cloud-based and available on a multitude of devices. Mac or PC, laptop or tablet, even phones should be supported.
  3. Able to connect with other software. Does the software play well with others? The root cause analysis software should be able to connect with other ESHQ (Environment, Safety, Health, Quality), human resource, or performance monitoring systems.
  4. Custom reports. Reports the way that you and your management want them. Easy to develop and save. No special software required.
  5. Trends. Advanced trending techniques that help you measure and predict performance.

Sounds great. But where can you find these features? The TapRooT® Version VI Software (of course).

Screen Shot 2018 05 04 at 12 33 50 PM

First, the TapRooT® VI Software is based on the world-class TapRooT® Root Cause Analysis System. If you don’t know why TapRooT® stands head and shoulders above other root cause systems, you should attend our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training and find out. Learn to use SnapCharT® to investigate what happened and organize your evidence. Use Equifactor® to troubleshoot equipment failures. Use Safeguard Analysis to find all the Causal Factors. Use the Root Cause Tree® to find the real, fixable causes of human performance and equipment issues. and use the Corrective Action Helper® Module to develop effective fixes.

Screen Shot 2018 05 04 at 12 34 46 PM

Second, TapRooT® VI Software is cloud-based. You can subscribe as an individual; you can host the TapRooT® VI Software on your network; or we can host the software for your whole company. TapRooT® VI is device independent. Mac, tablet, smartphone. No problem. CONTACT US for more information.

Third, TapRooT® VI Software has an API. This allows easy connections to other software. Talk to our IT guys to find out more. Call 865-357-0080 or CLICK HERE.

Fourth, need a custom report? No problem when you are using TapRooT® VI Software. Have a look at this link to get some ideas …

Fifth, we have been teaching advanced trending techniques for 20 years and they are built into the TapRooT® VI Software. Here’s a short video on exporting trending data to Excel.

But there is more to consider when picking your root cause analysis software. Consider this:

How good is the training?

How good is the software support?

TapRooT® Training is highly rated by students around the world. See samples of what they have to say HERE.

What abut our software support? Outstanding! Our knowledgeable support staff is happy to help you figure things out.

Want more information about TapRooT® VI Software? Let’s do an online demo. CONTACT US to learn more.

Two Incidents in the Same Year Cost UK Auto Parts Manufacturer £1.6m in Fines

Posted: May 22nd, 2018 in Accidents, Investigations, Performance Improvement, Pictures

Screen Shot 2018 05 22 at 4 37 39 PM

Faltec Europe manufactures car parts in the UK. They had two incidents in 2015 related to health and safety.

The first was an outbreak of Legionnaires’ Disease due to a cooling water system that wasn’t being properly treated.

The second was an explosion and fire in the manufacturing facility,

For more details see:

The company was prosecuted by the UK HSE and was fined £800,000 for each incident plus £75,159.73 in costs and a victim surcharge of £120.

The machine that exploded had had precursor incidents, but the company had not taken adequate corrective actions.

Are you investigating your precursor incidents and learning from them to prevent major injuries/health issues, fires, and explosions?

Perhaps you should be applying advanced root cause analysis to find and fix the real root causes of equipment and human error related incidents? Learn more at one of our courses:

2-Day TapRooT® RooT® Cause Analysis Course

5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training

Want to see our courses in Europe? CLICK HERE.

You can attend our training at our public courses anywhere around the world. See the list by CLICKING HERE.

Would you like to sponsor a course at your site? Contact us for a quote by CLICKING HERE.

Avoid Big Problems By Paying Attention to the Small Stuff

Posted: May 16th, 2018 in Accidents, Courses, Performance Improvement, Pictures, Root Cause Analysis Tips, TapRooT

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

Avoid Big Problems By Paying Attention to the Small Stuff

may sound counter-intuitive.

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

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

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

A Senior VP at a utility told me:

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

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

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

What is a precursor incident?

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

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

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

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

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

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

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

SwissCheese copy

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

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

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

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

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

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

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

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

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

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

How do you get started?

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

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

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

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

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

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

Posted: May 9th, 2018 in Pictures, Root Cause Analysis Tips, TapRooT

Find the Root Cause

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

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

1.    Why did the robot stop?

–    The circuit has overloaded, causing a blown fuse.

2.    Why did the circuit overload?

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

3.    Why was there insufficient lubrication on the bearings?

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

4.    Why is the pump not circulating sufficient oil?

–    The pump intake is clogged with metal shavings.

5.    Why is the intake clogged with metal shavings?

–    Because there is no filter on the pump.

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

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

TapRooT® Root Cause Analysis

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

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

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

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

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

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

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

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

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

Causal Factors

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

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

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

TapRooT® Root Causes

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

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

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

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

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

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

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

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

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

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

Admiral Rickover’s 7 Rules

Posted: May 9th, 2018 in Performance Improvement, TapRooT

Hyman Rickover 1955

Rule 1. You must have a rising standard of quality over time, and well beyond what is required by any minimum standard.
Rule 2. People running complex systems should be highly capable.
Rule 3. Supervisors have to face bad news when it comes, and take problems to a level high enough to fix those problems.
Rule 4. You must have a healthy respect for the dangers and risks of your particular job.
Rule 5. Training must be constant and rigorous.
Rule 6. All the functions of repair, quality control, and technical support must fit together.
Rule 7. The organization and members thereof must have the ability and willingness to learn from mistakes of the past.

Are you using advanced root cause analysis to learn from past mistakes? Learn more about advanced root cause analysis by CLICKING HERE.

Newest Aircraft Carrier Breaks Down During Sea Trials

Posted: May 8th, 2018 in Current Events, Equipment/Equifactor®, Video

USS Ford underway for sea trials …

An article in Popular Mechanics said the the USS Ford had to return early from sea trials because of an overheating thrust bearing on one of the four main engines. Bloomberg reported that:

“inspection of the parts involved in the January 2018 incident revealed improperly machined gears at GE’s facility in Lynn, Massachusetts as the ‘root cause.'”

Is “improperly machined gears” a root cause? That would be a Causal Factor and the start of a root cause analysis in the TapRooT® System. And why wasn’t the “improper” machining detected prior to installation and sea trials?

Here is some footage of sea trials (including a brief glimpse of one main shaft turning).

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®

Michelle WishounMichelle Wishoun

Licensing Paralegal

Per OhstromPer Ohstrom

VP, Sales

Shaun BakerShaun Baker

Technical Support

Steve RaycraftSteve Raycraft

Technical Support

Wayne BrownWayne Brown

Technical Support

Success Stories

Stopping Future Accidents by Correcting Problems That Did Not Cause The Accidents Being Investigated Submitted by: James Watson, Regional Specialist, System Safety Branch FAA, Alaska Challenge TapRooT® investigation often identify actions and conditions that didn’t cause the actual accident being evaluated but that could be significant and, if not corrected, could combine with other factors …

I know that accidents happen, but I always try and learn from them and absolutely aim…

Contact Us