Search Results for: hypothesis

 

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

Posted: May 31st, 2017 in Investigations, Root Cause Analysis Tips, Root Causes

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!

To Hypothesize or NOT to Hypothesize … that is the Question!

Posted: May 16th, 2017 in Quality, Root Cause Analysis Tips, TapRooT, Training

NewImage

Yet again, another article in Quality Progress magazine (May 2017 – Solid Footings) suggests that the basis for a root cause analysis is a hypothesis.

We have discussed the problems of starting a root cause analysis with a hypothesis before but it is probably worth discussing it one more time…

NewImage

Don’t start with the answer.

Starting with the answer (a hypothesis) is a bad practice. Why? Because of a human tendency called “confirmation bias.” You can read about confirmation bias in the scientific literature (do a Google search) but the simple answer is that people focus on evidence that proves their hypothesis and disregard evidence that conflicts with their hypothesis. This is a natural human tendency that is difficult to avoid if you start with a hypothesis.

NewImage

I’ve seen many root cause experts pontificate about investigators “keeping an open mind” and disprove their own hypothesis. That’s great. That’s like saying, “Don’t breath.” Once you propose an answer … you start to believe it and PROVE it.

What should you do?

Use a system that doesn’t start with a hypothesis.Try TapRooT® Root Cause Analysis.

NewImage

You will learn to use a SnapCharT® to collect information about what happened without jumping to conclusions.

Once you understand what happened and identify the Causal Factors, you will then be ready to analyze why the Safeguards failed (find the root causes) without jumping to conclusions by using advanced tools: the Root Cause Tree® Diagram and the Root Cause Tree® Dictionary.

This system gets you to think beyond your current knowledge!

The system has been proven to work at major companies and different industries around the world.

Want to learn more to improve quality and safety at your company? Attend one of our public root cause analysis courses. See the list of upcoming courses at:

http://www.taproot.com/store/Courses/

Top 3 Reasons for Bad Root Cause Analysis and How You Can Overcome Them…

Posted: February 7th, 2017 in Human Performance, Investigations, Performance Improvement, Pictures, Quality, Root Cause Analysis Tips, TapRooT, Training, Video

NewImage

I’ve heard many high level managers complain that they see the same problems happen over and over again. They just can’t get people to find and fix the problems’ root causes. Why does this happen and what can management do to overcome these issues? Read on to find out.

 

1. BLAME

Blame is the number one reason for bad root cause analysis.

Why?

Because people who are worried about blame don’t fully cooperate with an investigation. They don’t admit their involvement. They hold back critical information. Often this leads to mystery accidents. No one knows who was involved, what happened, or why it happened.

As Bart Simpson says:

“I didn’t do it.”
“Nobody saw me do it.”
“You can’t prove anything.”

Blame is so common that people take it for granted.

Somebody makes a mistake and what do we do? Discipline them.

If they are a contractor, we fire them. No questions asked.

And if the mistake was made by senior management? Sorry … that’s not how blame works. Blame always flows downhill. At a certain senior level management becomes blessed. Only truly horrific accidents like the Deepwater Horizon or Bhopal get senior managers fired or jailed. Then again, maybe those accidents aren’t bad enough for discipline for senior management.

Think about the biggest economic collapse in recent history – the housing collapse of 2008. What senior banker went to jail?

But be an operator and make a simple mistake like pushing the wrong button or a mechanic who doesn’t lock out a breaker while working on equipment? You may be fired or have the feds come after you to put you in jail.

Talk to Kurt Mix. He was a BP engineer who deleted a few text messages from his personal cell phone AFTER he had turned it over to the feds. He was the only person off the Deepwater Horizon who faced criminal charges. Or ask the two BP company men who represented BP on the Deepwater Horizon and faced years of criminal prosecution. 

How do you stop blame and get people to cooperate with investigations? Here are two best practices.

A. Start Small …

If you are investigating near-misses that could have become major accidents and you don’t discipline people who spill the beans, people will learn to cooperate. This is especially true if you reward people for participating and develop effective fixes that make the work easier and their jobs less hazardous. 

Small accidents just don’t have the same cloud of blame hanging over them so if you start small, you have a better chance of getting people to cooperate even if a blame culture has already been established.

B. Use a SnapCharT® to facilitate your investigation and report to management.

We’ve learned that using a SnapCharT® to facilitate an investigation and to show the results to management reduces the tendency to look for blame. The SnapCharT® focuses on what happened and “who did it” becomes less important.

Often, the SnapCharT® shows that there were several things that could have prevented the accident and that no one person was strictly to blame. 

What is a SnapCharT®? Attend any TapRooT® Training and you will learn how to use them. See:

TapRooT® Training

NewImage

2. FIRST ASK WHAT NOT WHY

Ever see someone use 5-Whys to find root causes? They start with what they think is the problem and then ask “Why?” five times. Unfortunately this easy methods often leads investigators astray.

Why?

Because they should have started by asking what before they asked why.

Many investigators start asking why before they understand what happened. This causes them to jump to conclusions. They don’t gather critical evidence that may lead them to the real root causes of the problem. And they tend to focus on a single Causal Factor and miss several others that also contributed to the problem. 

How do you get people to ask what instead of why?

Once again, the SnapCharT® is the best tool to get investigators focused on what happened, find the incidents details, identify all the Causal Factors and the information about each Causal Factor that the investigator needs to identify each problem’s root causes.

NewImage

3. YOU MUST GO BEYOND YOUR CURRENT KNOWLEDGE

Many investigators start their investigation with a pretty good idea of the root causes they are looking for. They already know the answers. All they have to do is find the evidence that supports their hypothesis.

What happens when an investigator starts an investigation by jumping to conclusions?

They ignore evidence that is counter to their hypothesis. This problem is called a:

Confirmation Bias

It has been proven in many scientific studies.

But there is an even bigger problem for investigators who think they know the answer. They often don’t have the training in human factors and equipment reliability to recognize the real root causes of each of the Causal Factors. Therefore, they only look for the root causes they know about and don’t get beyond their current knowledge.

What can you do to help investigators look beyond their current knowledge and avoid confirmation bias?

Have them use the SnapCharT® and the TapRooT® Root Cause Tree® Diagram when finding root causes. You will be amazed at the root causes your investigators discover that they previously would have overlooked.

How can your investigators learn to use the Root Cause Tree® Diagram? Once again, send them to TapRooT® Training.

THAT’S IT…

The TapRooT® Root Cause Analysis System can help your investigators overcome the top 3 reasons for bad root cause analysis. And that’s not all. There are many other advantages for management and investigators (and employees) when people use TapRooT® to solve problems.

If you haven’t tried TapRooT® to solve problems, you don’t know what you are missing.

If your organization faces:

  • Quality Issues
  • Safety Incidents
  • Repeat Equipment Failures
  • Sentinel Events
  • Environmental Incidents
  • Cost Overruns
  • Missed Schedules
  • Plant Downtime

You need to be apply the best root cause analysis system: TapRooT®.

Learn more at: 

http://www.taproot.com/products-services/about-taproot

And find the dates and locations for our public TapRooT® Training at:

 http://www.taproot.com/store/Courses/

NewImage

Root Cause Analysis Used as an Important Tool to Identify Patient Safety Best Practices

Posted: March 7th, 2013 in Medical/Healthcare, Performance Improvement, TapRooT

The Agency for Healthcare Research and Quality did a study looking for proven methods of improving patient safety and healthcare outcomes. In that study, results of root cause analyses were used to find targets for improvement, look for effective techniques (proof of improvement), and provide potential areas for developing corrective actions (improvement initiatives).

The report defined root cause analysis several different ways, including:

Page 290: “Root cause analysis (RCA) is a structured analysis technique originally developed for human factors and systems engineering to retrospectively determine the interrelationship of component elements in causing an observed malfunction or accident. It has been adapted for use in medical and health care systems.

Page 412: “…an in-depth examination of the data to identify factors in the care process that contribute to the errors…”

One comment in the report was:

Wu examined the use of RCAs in medicine generally, and noted a very wide range of skill in performing RCAs accurately, a lack of best practices in reporting and followup, and the absence of peer-reviewed evidence of the effectiveness of RCAs or their cost-benefits tradeoffs.”
(Wu AW, Lipshutz AK, Pronovost PJ. Effectiveness and efficiency of root cause analysis in medicine. JAMA. 2008;299(6):685-7. PMID: 18270357)

That made me worry.

Were conclusions drawn in the report that were based on faulty root cause analysis?

After all, we have all seen poor root cause analysis done before. 5-Whys that lead to a preconceived result. Fault Trees built to prove a hypothesis (and missing other possibilities). People jumping to conclusions and not considering causes that they don’t understand.

I wondered … “What if the healthcare industry really adopted an effective root cause tool (TapRooT®) and then actually implemented it effectively? … What would happen?”

There’s more to TapRooT® than just sending people to a 2-Day Course.

To get the full benefits from TapRooT®, management must integrate it into their improvement efforts and manage it’s implementation and use.

That’s why we wrote Chapter 6 of the TapRooT® Book. To guide people to what an effective TapRooT® implementation looks like.

Implementation that includes a vision for improvement with a written plan that includes a sponsor, an improvement leader, and trained facilitators and peer reviewers.  A plan that includes effective measurement and continuous improvement. A plan that includes management reviews and rewards for investigations and measured improvement success.

Work is required to make root cause analysis successful. If you are in the healthcare industry (or any other industry for that matter) read Chapter 6 and take the challenge to implement TapRooT® effectively at your facility. You’ll then be able to prove that TapRooT® was effective in helping you improve patient safety.

7 Secrets of Root Cause Analysis

Posted: January 7th, 2011 in Investigations, Performance Improvement, Root Cause Analysis Tips, Root Causes

Who’s Keeping the Secrets?

In over 25 years of human factors and root cause analysis study, I’ve learned a few things that everyone should know. I don’t keep these root cause “best practices” a secret, but you would think that I did. Why? Because I find so many “experts” and lay people alike who don’t understand what I see as obvious. So I thought, “Why not share the seven most important ‘secrets’ here?” Then I could explain how the secrets are incorporated into TapRooT®.

7 Secrets

Here’s the list of the 7 Secrets:

1. Your root cause analysis is only as good as the info you collect.

2. Your knowledge (or lack of it) can get in the way of a good root cause analysis.

3. You have to understand what happened before you can understand why it happened.

4. Interviews are NOT about asking questions.

5. You can’t solve all human performance problems with discipline, training, and procedures.

6. Often, people can’t see effective corrective actions even if they can find the root causes.

7. All investigations do NOT need to be created equal (but some investigation steps can’t be skipped).

Garbage In = Garbage Out

Most root cause systems operate as a “stand-alone” module. Information goes in and an answer comes out. They don’t help investigators collect accurate info.

To make matters worse, some root cause tools actually start by developing a “hypothesis” and then collecting information to verify (or perhaps disprove) the hypothesis. Extensive research has proven that once an investigator becomes invested in a particular hypothesis, his/her brain automatically starts looking for “facts” to confirm the hypothesis and disregards “facts” that are counter to the hypothesis. The result? You find what you want to find. This is not a robust root cause analysis process.

Investigation Tied To RCA

7 secrets

TapRooT® 7-Step Process

Copyright 2008 by System Improvements, Inc. Used by permission.

TapRooT® takes a completely different approach to how a root cause analysis process is used in an investigation. In the TapRooT® 7-Step Process, the root cause analysis tools are used throughout the investigation to make every investigation phase, including information collection, more robust.

Step 1: Planning

The first tool from the TapRooT® Toolbox that helps an investigator collect info is the SnapCharT®. The investigator starts using this tool to organize the investigation and decide what evidence needs to be gathered and assigns a priority to securing evidence that might be lost.

First Secret

That’s the first secret. Get accurate, complete, necessary information to understand the incident. If you try to analyze assumptions, you will be guessing at the root causes and fixing your guesses. That would be a “bad practice.”

Secret 2

Your knowledge (or lack of it) can get in the way of a good root cause analysis.

What? You think this is obvious? That’s OK. Many don’t recognize how this secret interferes with root cause analysis.

Let’s start with a popular root cause myth: Cause & Effect. Many think they can use the theory of cause & effect to find root causes. They assume that an experienced investigator who has seen a cause produce an effect can use that knowledge to diagnose future problems by using his/her experience to deduce the complex causal links (cause & effect chain) of an accident. This theory is the basis for many root cause analysis tools like 5-Whys, Cause-and-Effect Analysis, and FMEA.

An obvious problem with this theory is that inexperienced investigators don’t know many cause & effect relationships. They can’t find what they don’t know.

But many don’t understand that even experienced investigators may be led astray by the assumptions behind cause & effect analysis. How? Read on…

Investigator Trap

Experienced investigators are often trapped by the same cause & effect assumption that traps amateurs. How? First, even the most experienced investigators don’t know all the cause & effect relationships that cause accidents. This is especially true of the causes of human error. Many “experts” have little or no training or understanding of the psychology behind human error.

To combat the lack of knowledge, they recommend putting together teams of investigators with the hope that someone on the team will see the right answer. Of course, this depends on team selection to counter the inherent weakness of the assumption behind cause & effect. Also, it assumes that the rest of the team will recognize the right answer when another team member suggests it. Good luck! More likely, the “strongest” member of the team will lead the team to arrive at the answers that he/she is experienced with.

Favorite-Cause-Itis

Experienced investigators often fall into the “favorite-cause-itis” trap. They use their experience to guide the investigation. This leads them to find cause & effect relationships that they are familiar with. Why? Because that is what they look for. They search for familiar patterns and disregard counter evidence. (The technical name for this phenomenon is “confirmation bias.”) The more experienced the investigator is … the more likely he/she is to fall into the trap.

Exposing this secret doesn’t make me popular with experienced guru investigators. They don’t want to admit that they have the same weakness as inexperienced investigators when it comes to cause & effect analysis. They try to explain that they don’t have preconceived ideas about the cause of any accident. But of course, this statement flies in the face of the basis of cause & effect analysis – that experienced investigators know the cause & effect relationships of accidents and can recognize them during an investigation.

TapRooT® Overcomes Favorite-Cause-Itis

How does TapRooT® overcome problems with “investigator knowledge”? Two ways. First, it keeps the investigation focused on “What happened?” while information is being collected. Because investigators don’t prematurely jump to finding causes, they are more likely to follow the evidence where it leads rather than following it where they want to go.

The main tool they use for collecting evidence is the SnapCharT®. They also use Change Analysis, Equifactor®, and CHAP. This combination of advanced tools produces superior information to analyze.

But the real magic behind TapRooT®’s root cause analysis is the Root Cause Tree®. The Root Cause Tree® takes the knowledge of hundreds of experts and makes it available to every investigator. (For the impressive list of sources used to build the tree, see Chapter 1 of the TapRooT® Book.) This knowledge doesn’t have to be in the investigator’s head because it is built into the Root Cause Tree® and the Root Cause Tree® Dictionary. Applying these systematic methods helps TapRooT® Users keep from jumping to conclusions.

The organization of causation in the Root Cause Tree® not only came from many reliable, advanced, sources but also was reviewed, critiqued, and tested. Beyond that, there are over 20 years of feedback from the international base of TapRooT® Users and members of the TapRooT® Advisory Board. This makes the TapRooT® System a unique, advanced process for finding the real root causes of problems.

Secret 3

You have to understand what happened before you can understand why it happened.

This secret seems obvious. Of course, you must understand what happened. But many investigators, and some root cause tools, start by asking “Why?” when they should be trying to understand “What happened?”

Starting by asking “Why” is jumping to conclusions. And this can lead the investigator to find causes that they have jumped to because they didn’t first seek to understand.

How SnapCharT®s Help

In the TapRooT® System, the first tool an investigator uses is a SnapCharT®. The SnapCharT® is a visual depiction of the evidence. It focuses the investigator on “What happened?” Any assumptions (not verified facts) are easily identified by their dashed boxes. The investigator then continues to look for more evidence to verify the assumptions or show a different, but also possible, sequence of events and conditions.

The SnapCharT® is an evolving document. The TapRooT® Book and the TapRooT® Courses teach the different “seasons” of SnapCharT®s. Each season has a purpose, which determines the level of detail shown on the SnapCharT®.

The Autumn SnapCharT® includes all the Causal Factors and evidence needed to find the incident’s root causes. Occasionally, an investigator will discover additional information when using the Root Cause Tree® to find root causes. This info needs to be added to the SnapCharT® to make it complete.

Below is an Autumn SnapCharT®.

SnapCHart_Popular_Posts

Secret 4

Interviews are not about asking questions.

“What?” you might say … “I’ve always been taught to ASK questions as an interviewer.” What about the “open ended and close ended questions” routine that is commonly taught in some root cause training? And what about asking “Why?” five times? I thought I had to ask questions during an interview?

Let’s start with the popular 5-Why myth.

I won’t review all the problems with the 5-Why technique. I’ll just mention the one that most applies to interviewing. Consider this … what happens when you ask somebody a question like:

“Why did you do that?”

Does the person answer with lots of information or with justification?

The “Why” question turns off the “remembering” trail that we want the brain to go down and turns on the “justification” trail. After all, isn’t the purpose of an interview to collect information (not justification)?

Next, let’s look at the whole process of “questioning” during an interview. If the purpose of an interview is to collect information, we should use a process that stimulates remembering.

Researchers Fisher and Geiselman determined that the biggest problem with police interviews was the police interrupting the interviewees’ memory process with questions. It didn’t matter if the questions being asked were open ended or closed ended. Every time the interviewer interrupted the interviewee, his/her memory had to shift gears. S/he lost her/his train of thought and didn’t remember as much as s/he could. The interviewer didn’t get to important facts. (Facts were omitted when the interviewee was distracted by questions.)

Not only did interruptions for questions cause problems, but also the questions being asked didn’t help stimulate remembering. Fisher and Geiselman came up with a new interviewing process called “cognitive interviewing” that helps the interviewer encourage the interviewee to remember much more and thus improve the amount of information collected.

Another problem that was noted in Fisher and Geiselman’s research was that interviewees often tried to provide the interviewer with the “most important” information. They filtered what they told the interviewer. The interviewee didn’t understand that some detail that they thought was “unimportant” was something that the interviewer really needed. Because the interviewer didn’t know the detail, they couldn’t ask about it. Therefore, the information was lost.

The TapRooT® 5-Day Advanced Root Cause Analysis Team Leader Course includes cognitive interviewing combined with the TapRooT® SnapCharT® technique to improve interviews. This shifts the interviews from a questioning to a listening process. The cognitive interviewing process encourages interviewees to share all the info they know by encouraging them to remember. Also, the interviewee is told to provide details no matter how small or unimportant.

Secret 5

You can’t solve all human performance problems with discipline, training, and procedures.

If you look at most industrial accident/incident investigations, you find three standard corrective actions:

1. Discipline. Which starts with the common corrective action: “Counsel the employee to be more careful when …”.

2. Training. This may be the most used (and misused) corrective action of all.

3. Procedures. If you don’t have one, write one. If you already have one, make it longer.

The misuse of these three standard corrective actions is the reason that so many accident investigations don’t really cause performance to improve. They don’t solve the real problems.

What do we need to get better results? First, better root cause analysis. Second, development of better corrective actions based on the root causes of the problems. And third, corrective actions that provide the strongest safeguards to future errors.

TapRooT® provides the better root cause analysis and the Corrective Action Helper® Guide to help investigators develop better corrective actions. But the 2-Day, 3-Day, and 5-Day TapRooT® Classes also teach Safeguards Analysis to help investigators understand that all corrective actions are not created equal. Students learn that there is a hierarchy of potential corrective actions and that they should not just use the corrective actions that seem easiest to develop and implement. Rather, they should look for the strongest corrective actions that will ensure that a problem does not recur.

Secret 6

Often, people can’t see effective corrective actions even if they can find the root causes.

Why? Because they have performed the work the same way for so long that they can’t imagine another way to do it.

I didn’t initially believe this. I thought that once someone saw the root cause of a problem, the answer would be obvious. But students in a course finally convinced me that I was wrong.

Back in 1994, a team of students analyzed the root causes of a fairly simple incident. One of the root causes was that the valves being operated were not labeled. So far, so good.

But here was their corrective action:

Tell operators to be more careful when operating valves without labels.

They just couldn’t see that valves could be labeled. It was beyond their experience.

That was the day I decided that we needed to do something different to help people see different corrective action alternatives. This revelation eventually lead to the development of the Corrective Action Helper® Module of the TapRooT® Software and the Corrective Action Helper® Guide that each participant gets in our 2-Day and 5-Day TapRooT® Courses.

The Corrective Action Helper® Module/ Guide provides suggestions that can help investigators discover that there are other ways to solve problems beyond those of their experience. It does not guarantee that they will get the right answer but it does prod them in the right direction. Also, the Corrective Action Helper® Guide can be used by management to review the investigation team’s findings to see if they explored all the alternatives.

Secret 7

Now for the final secret…

All investigations do NOT need to be created equal
(but some investigation steps can’t be skipped).

I’ve seen people cringe when performing a root cause analysis of a problem is suggested. They think this means a team of selected experts spending months locked up in a room. After all, didn’t the CSB take three years and spend almost $3 million investigating the BP Texas City explosion?

It’s true that some investigations may take too long and cost too much. But that doesn’t mean that every root cause analysis needs to take too long and cost too much.

Root cause analysis should be scaled to the size of the problem and the risk of future accidents with similar causes. Small risk = small investigation. Big risk? Then spend more time and more investigative effort … dot each “i” & cross each “t.”

The hard part of responding appropriately is projecting the risk of the problem before the investigation starts. For example, sometimes an incident that seems quite simple can have complex causes that could, in different circumstances, cause a big accident.

Scale an Investigation

The TapRooT® System is flexible to accommodate any size risk. Use some techniques for every investigation. Others are just applied in major investigations.

For simple incidents, a single investigator draws a simple SnapCharT® of the sequence of events and identifies one to three easy to spot Causal Factors. They can do this working with those involved in a couple of interviews. Just one or two hours total.

Drawing a SnapCharT® is required because you have to understand what happened before you can find out why it happened.

Next, she takes those Causal Factors through the Root Cause Tree®. (Perhaps an hour of work.) Then another hour to develop some simple, SMARTER corrective actions based on the Corrective Action Helper® Guide and to document it with some short written sections in the TapRooT® Software. You are ready for approval. (About one half day’s work.)

What if management says that half a day is “too long”? After all, couldn’t you ask “Why” five times in about five minutes and then suggest a corrective action?

Of course, you could. But that isn’t root cause analysis. That’s just taking a guess and going with it.

Some small problems don’t deserve root cause analysis. Don’t waste time implementing poorly thought out corrective actions. Just categorize the problem and repair the failure. Paper cuts can’t cause fatalities.

The big accidents? Go all out. A full-blown investigation team with an independent facilitator. SnapCharT®, CHAP, Change Analysis, Equifactor®, Safeguard Analysis, and the Root Cause Tree®. Look for generic causes of each root cause. Then remove the hazard or target or change the human engineering of the system. Not the normal “training/ counseling” simple corrective actions. Something really effective at eliminating the root causes or the hazard.

Something in between? A response in between. Don’t go overboard. Just do what you need based on the size of the problem. And if you discover that a problem is bigger than you thought, let management know and change the scope of the investigation.

Applying the 7 Secrets

Now that you know the seven secrets, apply them in your investigations. The easiest way to do this is to apply TapRooT® as the standard incident investigation root cause analysis technology at your site. Start by attending one of our public TapRooT® Courses. Then get a site or corporate TapRooT® Software License and hold training at your sites. You’ll find the time (and lives) you save will be well worth the effort.

Contact us for information by CLICKING HERE.

Monday Accident & Lessons Learned: Accept Defeat – The Neuroscience of Screwing Up

Posted: January 4th, 2010 in Accidents, Current Events, Human Performance, Investigations, Root Cause Analysis Tips, Root Causes

Picture 14.png

When can an accident teach us something about investigating accidents? When the accident helps us understand the human brain and it’s limitations.

A story in Wired Magazine titled: “Accept Defeat: The Neuroscience of Screwing Up” explains how scientists often disregard information that conflicts with their “hypothesis” and how this is caused by the way the human brain is wired. I recommend reading the article to better understand this phenomenon.

But how does this relate to accident investigation? Here’s the answer…

Root cause analysis systems based on the theory of cause-and-effect require the investigator to develop a hypothesis and then look for evidence to prove or disprove the hypothesis. The theory of cause-and-effect requires the investigator to already understand the cause-and-effect relationships they are looking for. Thus, they can only find cause-and-effect relationships that they already understand.

However their brain, according to the research in the article, automatically keeps them from seeing evidence counter to their hypothesis or outside their experience.

That is why cause-and-effect root cause analysis techniques frequently have widely different results when used by different individuals looking at similar evidence. Each individual sees the “evidence” the way they want to see it to support their theory of the accident’s cause.

TapRooT® is not built on this cause-and-effect theory. Instead, it is based on unfiltered review of the evidence leading the investigator to develop a detailed explanation of what happened before they start to analyze why it happened. The evidence isn’t collected to verify a hypothesis. Rather, it is collected to expand the investigator’s knowledge and understanding.

Also, instead of depending on the investigator’s knowledge of cause-and-effect, TapRooT® has built-in expert systems to help the investigator see causes that may be beyond their current knowledge of the cause-and-effect relationships of the incident being investigated. These built-in expert systems help the investigator side-step their brain’s built-in simplifying mechanisms and find causes that they might not have originally suspected (or even understood).

Of course, any investigator can stubbornly hold to preconceived notions, but TapRooT® doesn’t fall into the “scientist’s trap” that this article talks about. It naturally helps investigators go beyond their preconceived ideas and previous experience.

That’s an important lesson learned!

If you don’t care about the brain-science behind why TapRooT® works and other root cause analysis techniques fail, that’s OK! Don’t worry … You don’t have to be a neuroscientist to use TapRooT®. We’ll teach you how to use TapRooT® in a 2-Day, 3-Day, or 5-Day Course and then you can take advantage of the advanced science that is invisible to the user but is built into the TapRooT® System.

What?!? You haven’t learned TapRooT®? Then now is the right time to get to a course and experience how TapRooT® can help you find root causes that you previously would have overlooked and develop corrective actions that you and your management will agree are much more effective. Don’t wait! Sign up for a course at:

http://www.taproot.com/courses.php

Root Cause Analysis Tip: Are Simple Techniques Sometimes the Best?

Posted: August 7th, 2009 in Investigations, Performance Improvement, Quality, Root Cause Analysis Tips, TapRooT

I received a piece of marketing material for a webinar claiming to teach “simple” root cause analysis techniques in just one hour.

The marketing material included the quote that these basic techniques:

are sometimes the best.

Of course, they lost all credibility with me when they claimed to teach root cause analysis in 60 minutes on the web. But the e-mail made me think …

What are the minimum tools needed to perform a good root cause analysis of a simple problem?

We’ve researched this question for over 20 years and I know the answer.

First, you need to understand:

Make the answer as simple as possible, but not simplier.” (Albert Einstein)

What is the minimum needed information to find a root cause?

1. You need to completely understand what happened before you can understand why it happened. And this understanding should NOT be made through verification of a hypothesis. Rather, the understanding should be an unbiased collection of evidence.

The tool that helps people build the story of what happened using evidence that is collected is a SnapCharT®. And example of a SnapCharT® can be found at this link:

Using the TapRooT® System-tm.jpg

Picture 14.png

2. Next, you need to identify all the Causal Factors. These are the problems that, if removed, would have prevented the incident or reduced its severity.

There are two techniques that are taught in TapRooT® Training to help investigators identify Causal Factors. The first is the Four Question Method and the second is Safeguards Analysis.

3. Finally, to analyze what caused the Causal Factor, you need a robust root cause analysis tool. There are many substandard tools available so … be careful. Many “experts” recommend a tool they are familiar with without doing thorough research of the tools limitations and understanding the serious shortcomings of supposedly “simple” tools. But we have dedicated our lives to understanding root cause analysis and developing a tool that does not fall into the trap of being just simple but inadequate.

The TapRooT® Root Cause Tree® have been carefully designed and tested to provide the simplest tool possible while yielding robust root cause analysis for equipment and human performance related Causal Factors. The research basis is extensive, so I won’t provide it all here. But I will provide several links so that you can start to understand it…

http://www.taproot.com/content/2008/11/07/defending-categorization-why-the-taproot-root-cause-tree-works-better-than-unguided-root-cause-analysis/

http://www.taproot.com/content/2006/02/28/the-curse-of-apparent-cause-analysis/

http://www.taproot.com/content/2007/12/04/comparing-taproot-to-other-root-cause-tools/

However, some people continue to cling to inadequate tools because they are “easy” and “sometimes the best.” (Makes one wonder when they are “sometimes the worst.”)

Usually this insistance on using easy, inadequate tools is because the person has failed to do what is needed to make real root cause analysis possible.

What did they miss? See this link to learn what is needed for efficient and effective root cause analysis:

http://www.taproot.com/content/2006/02/07/efficient-yet-effective-root-cause-analysis/

So these tools are the required minimum set (the essential tools) for a good root cause analysis. Anything less is root cause analysis malpractice.

We’ve found that a 2-day course is needed to effectively teach these tools to experienced investigators who want to apply them both reactively and proactively and then have them be used effectively.

So, don’t be fooled into economizing into “quick/easy” methods with fast but inadequate web based training. All you will get is inadequate investigations and recurring problems.

And if this approach seems to be too hard, consider skipping investigations altogether. If you aren’t going to perform an adequate investigation then you should consider that you may be better off by performing no investigation at all.

Defending Categorization – Why the TapRooT® Root Cause Tree® Works Better Than Unguided Root Cause Analysis

Posted: November 7th, 2008 in Investigations, Root Causes, TapRooT

The following is copyrighted material used by permission and taken from the TapRooT® Book – Changing the Way the World Solves Problems (Copyright 2008 by System Improvements, Inc.), Chapter 8.

– – –

Some cause-and-effect gurus object to use of the Root Cause Tree® (they call it categorization or a pick-list) because they feel that any categorization restricts the thinking of the investigator.

They maintain that the only way to ensure a complete, unbiased, unbounded root cause analysis is to attack each problem from the viewpoint of basic engineering and human performance principles and let the evidence lead where it may by the use of basic cause-and-effect deductive reasoning, testing of hypotheses, and identification of “factors.”

Our extensive investigation research and development, as well as basic psychological principles, show that this thinking is wrong. This section supplies evidence that will help anyone faced with this argument defend the good practices that TapRooT® and the Root Cause Tree® are based on.

TapRooT® and the Root Cause Tree® have extensive testing and field use that proves the Root Cause Tree® does not limit the thinking of investigators. Just the opposite is true. Once an investigator is trained in using TapRooT®, they find a broader range of causes and they are less restricted in their thinking than before they were trained in the use of TapRooT®. This is true even if they were previously trained in using a cause-and-effect based root cause analysis system.

Why do TapRooT® trained analysts find causes that they would have previously overlooked? There are several reasons.

First, when using TapRooT®, investigators use tools in addition to the Root Cause Tree®. These tools that are used before using the Root Cause Tree® encourage a better collection of information before the root cause analysis begins. SnapCharT® is especially helpful for organizing investigation information and spotting missing or conflicting information. Equifactor®, CHAP, Change Analysis, and Safeguards Analysis are excellent tools to help the investigator understand what happened before they start analyzing why it happened. Thus, when using TapRooT®, investigators are often better prepared to find Root Causes and less likely to jump to conclusions than they are when they use systems based primarily on cause-and-effect (which doesn’t have these built-in information collection tools).

Second, very few investigators have the broad knowledge, training, and experience in all of the fields needed to use cause-and-effect to analyze a complex accident. What kind of knowledge and experience would be needed? A short list includes:

– equipment engineering

– maintenance

– operations research

– management theory

– human factors/ergonomics

– training theory

I often take polls of people getting root cause analysis training and I find that less than 4% have formal training in human factors/ergonomics. And that’s just one of the necessary disciplines.

Therefore, most people need guidance to direct them to the wide variety of Root Causes that should be considered when investigating a problem. They get this guidance when using TapRooT® and the Root Cause Tree®. We have not seen this level of high quality guidance in any other system.

Third, even experienced gurus fall into a common trap. They develop “favorite cause-itis” – causes that they primarily look for. The concept of “finding the answer you want” has been proven by independent research. Thus, experienced investigators have a tendency to ignore information that does not fit their hypothesis and look for information that confirms their hypothesis. This tendency is called a confirmation bias. A short list (of thousands) of research papers from the past 40 years that confirm the existence of a variety of types of confirmation bias, and the effects of confirmation bias to many fields, include:

• Peter Watson (Quarterly Journal of Experimental Psychology, 12, pages 129-140, “On the Failure to Eliminate Hypotheses in a Conceptual Task,” 1960), (Quarterly Journal of Experimental Psychology, 20, pages 273-281, “Reasoning about a Rule,” 1968)

• C.R. Matson, M.E. Doherty, and R.D. Tweney (Quarterly Journal of Experimental Psychology, 29, pages 85-95, “Confirmation Bias in a Simulated Research Environment: An Experimental Study of Scientific Inference,” 1977)

• R.A. Griggs and J.R. Cox (British Journal of Psychology, 73, pages 407-420, “The Elusive Thematic Materials Effect in the Wason Selection Task,” 1982).

• Anthony Greenwald, Anthony Pratkanis, Michael Leippe, Michael Baumgardner (Psychology Review, 93-2, pages 216-229, “Under What Conditions Does Theory Obstruct Research Progress,” 1986)

• J. Koehler (Organizational Behavior and Human Decision Processes, 56, pages 28-55, “The Influence of Prior Beliefs on Scientific Judgments of Evidence Quality,” 1993)

• Raymond Nickerson (Review of General Psychology, 2, pages 175-220, “Confirmation Bias: A Ubiquitous Phenomenon in Many Guises,” 1998)

• E. Jonas, S. Schulz-Hardt, D. Frey, N. Thelen (Journal of Personality and Social Psychology, 80-4, pages 557-571, “Confirmation Bias in Sequential Information Search After Preliminary Decisions: An Expansion of Dissonance Theoretical Research on Selective Exposure to Information,” April 2001)

• Ted Kaptchuk (British Medical Journal, 326-7404, pages 1453-1455, “Effect of Interpretive Bias on Research Evidence,” June 2003)

• J. Fugelsang, C. Stein, A. Green, and K. Dunbar (Canadian Journal of Experimental Psychology, 58, pages 132-141, “Theory and Data Interactions of the Scientific Mind: Evidence from the Molecular and the Cognitive Laboratory,” 2004)

• Drew Westen, C. Kilts, P Blagov, K Harenski, and S. Hamann (Journal of Cognitive Neuroscience, “The Neural Bias of Motivated Reasoning: an fMRI Study of Emotional Constraints on Political Judgment During the U.S. Presidential Election of 2004,” 2006)

Thus, experienced investigators trying to confirm a hypothesis (the method used when building a fault tree or implied in the deductive reasoning used in most applications of 5-Why’s and cause-and effect), or develop lists of “factors” will not have an “unbiased analysis” that they hope to achieve by avoiding categorization. Just like everyone else, they need a system (like the Root Cause Tree®) that focuses on a broad spectrum of possibilities. They need to use facts to select or eliminate the conditions under which the problem occurs (and thus what best practices can be used to eliminate the condition – just like the Root Cause Tree® provides). They need the guidance of the 15 Questions, the Basic Cause Categories of the Root Cause Tree®, and the Root Cause Tree® Dictionary to make sure they avoid the “favorite cause” confirmation bias trap.

Fourth, almost all thinking is categorical in nature. For example, language is a categorization of certain sounds into standard meanings. Thus, a dictionary of a language is a book of categorized meanings and pronunciations. Thus, someone who opposes the use of the Root Cause Tree® because it is categorical is just replacing one well-thought-out, well-defined set of categories with another set. The new set is the one that they don’t realize that they have in their mind. Often, we have observed that the set of categories in a guru problem solver’s mind is more restrictive (as measured by the variety of outcomes in their investigations) than the categorization presented by the Root Cause Tree®. You can, therefore, think of using the guru approach (with no well-thought-out categorization) as trying to communicate without a standard language, without a dictionary, and without even having a standard alphabet. Imagine how effective this unstructured communication would be…

Finally, the Root Cause Tree® is not just categorization. The Root Cause Tree® is not a simple checklist (pick-list). It has an expert system (the 15 Questions, the Basic Cause Categories, and the Root Cause Tree® Dictionary questions) built into it. Thus, the problems encountered when using a “pick-list” of Root Causes have been solved by the structure and expert systems built into the Root Cause Tree®.

The comparison of the Root Cause Tree® to a pick-list of Root Causes is a false comparison. When you see this false comparison used by those who wish to justify the use of other, less developed root cause analysis techniques, you will then realize that their system can’t compare to the robust, proven tools used by TapRooT®, including the Root Cause Tree® and Root Cause Tree® Dictionary. Therefore, they chose to call TapRooT® a simple pick-list because that makes their system look superior in comparison to a simple pick list. But that is a false comparison, because TapRooT® IS NOT a pick-list.

Our research and experience, in addition to independent research on confirmation bias, show that the structure and categorization used in the Root Cause Tree® doesn’t need to be apologized for. Rather, the structure and categorization of the Root Cause Tree® is a vast advantage over other non-structured, poorly categorized techniques that don’t have expert systems built into them, such as 5-Why’s, cause-and-effect, fishbones, fault trees, and other “factor” trees.

The next time you are asked to defend the Root Cause Tree® versus a system based on cause-and-effect analysis, fault trees, factors, or 5-Why’s, you will be armed with the facts that show the superior design of the TapRooT® System.

Monday Accident and Lessons Learned: When You Don’t Have Proof – Make Up An Answer

Posted: September 8th, 2008 in Accidents, Current Events, Investigations, Root Causes

The BBC headline read:

‘Ice in fuel’ caused BA jet crash

Yet the article goes on to state that the investigation into the crash landing at Heathrow of the British Airways Boeing 777 jet continues because the investigators think that the odds that this actually caused the crash are very low.

In other words, if you don’t have proof of what caused the crash, but you can make up an unlikely hypothesis, that must be the cause if you can’t find anything else.

Here’s another article making the same conclusion, published by Associated Press:

http://ap.google.com/article/ALeqM5h74C0Fmf2iAMhGLsEYaGHy1WgqggD9300N8O1

The investigators are making recommendations to avoid ice in fuel.

My idea – a vent system that is closed with a nitrogen blanket. This would also prevent accidents like the TWA explosion over New York.

But remember, this is a recommendation that isn’t based on root cause analysis. It is simply adding an additional Safeguard to prevent future accidents based on a hypothetical explanation.

Monday Accident & Lessons Learned: Failure To Do Root Cause Analysis and Take Corrective Action Costs DaimierChrysler $50 Million in One Lawsuit

Posted: March 12th, 2007 in Accidents, Performance Improvement, Root Causes

What can you and your executive team learn from this press release from Lieff Cabraser Heimann & Bernstein, LLP? Read the release and see…

$55 Million Verdict Imposed Against DaimlerChrysler Corporation For Failing To Fix Known Transmission “Park-to-Reverse” Defect That Killed Young Father At San Pedro/Long Beach Maritime Terminal

— Millions Of DaimlerChrysler Vehicles In Use With Similar Park-to-Reverse Defect

Robert J. Nelson, Scott P. Nealey, and Chuck Naylor, counsel for Adriana Mraz and her three children in a wrongful death action against DaimlerChrysler Corporation, announced that a California-state jury today returned a $50 million punitive damages award against DaimlerChrysler for knowing and intentional failure to cure a defect in millions of its vehicles. On March 2, 2007, the same jury found DaimlerChrysler liable for the death of Richard Mraz and returned a verdict of $5.2 million in compensatory damages for Mrs. Mraz and her children.

On April 13, 2004, Mr. Mraz suffered fatal head injuries when the 1992 Dodge Dakota pickup truck he had been driving at his work site, the San Pedro/Long Beach Maritime Terminal, ran him over after he exited the vehicle believing it was in park. The jury found that a defect in the Dodge Dakota’s automatic transmission, called a park-to-reverse defect, played a substantial factor in Mr. Mraz’s death, and that DaimlerChrysler was negligent in the design of the vehicle, for failing to warn of the defect, and then for failing to adequately recall or retrofit the vehicle.
(more…)

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

Posted: March 5th, 2007 in Human Performance, Investigations, Root Causes

… or Defending Categorization
(an excerpt from a draft of the revised TapRooT® Book
available later in 2007, Copyright © 2007)

Some cause-and-effect gurus object to use of the TapRooT® System’s Root Cause Tree® because they feel that any categorization restricts the thinking of an incident investigator. They maintain that the only way to ensure a complete, unbiased, unbounded root cause analysis is to attack each problem from the viewpoint of basic engineering and human performance principles and let the evidence lead where it may by the use of cause-and-effect, deductive reasoning, and testing of hypotheses. Our extensive investigation research and development as well as basic psychological principles show that this thinking is wrong.

The deductive reasoning and “hypothesis proving” used in fault trees, 5-Whys, and cause-and-effect actually cause problems that we will explain in this article. We will explain how these problems are solved by the tools used in the TapRooT® System. For TapRooT® Users, this article supplies the evidence you need to defend the good practices that TapRooT® and the Root Cause Tree® are based on when you are faced with the argument that “categorization” is a problem.

TapRooT® and the Root Cause Tree® have extensive testing and field use that proves the Root Cause Tree® does not limit the thinking of investigators. Just the opposite is true. Once an investigator is trained in using TapRooT®, they find a broader range of causes – they are less restricted in their thinking – than before they were trained in the use of TapRooT®. This is true even if they were previously trained in using a cause-and-effect based root cause analysis system.

Why, when using TapRooT®, do analyst find causes that they would have previously overlooked? There are several reasons.

First, when using TapRooT®, investigators use tools in addition to Root Cause Tree®. These tools that are used before using the Root Cause Tree® encourage a better collection of information before the root cause analysis begins. SnapCharT® is especially helpful for organizing investigation information and spotting missing or conflicting information. Equifactor®, CHAP, Change Analysis, and Safeguards Analysis are excellent tools to help the investigator understand what happened before they start analyzing why it happened. Thus when using TapRooT®, investigators are often better prepared to find root causes and less likely to jump to conclusions than they are when they use systems based primarily on cause-and-effect (which doesn’t have these built in information collection tools).

Second, very few investigators have the broad knowledge, training, and experience in all of the fields needed to use cause-and-effect to analyze a complex accident. What kind of knowledge and experience would be needed? A short list includes: equipment engineering, maintenance, operations research, management theory, human factors, ergonomics, and training theory. Therefore, most people need guidance to direct them to the wide variety of Root Causes that should be considered when investigating a problem. They get this guidance when using TapRooT® and the Root Cause Tree®. We have not seen this level of high quality guidance in any other system.

Third, even experienced gurus fall into a common trap. They develop “favorite cause-itis”. The concept of “finding the answer you want” has been proven by independent research. Thus, experienced investigators have a tendency to ignore information that does not fit their hypothesis and look for information that confirms their hypothesis. This tendency is called a confirmation bias. A short list (of thousands) of research papers from the past 40 years that confirm the existence of a variety of types of confirmation bias, and the effects of confirmation bias to many fields, include:

  • Peter Watson (Quarterly Journal of Experimental Psychology, 12, pages 129-140, “On the Failure to Eliminate Hypotheses in a Conceptual Task,” 1960), (Quarterly Journal of Experimental Psychology, 20, pages 273-281, “Reasoning about a Rule,” 1968)
  • C.R. Matson, M.E. Doherty, and R.D. Tweney (Quarterly Journal of Experimental Psychology, 29, pages 85-95, “Confirmation Bias in a Simulated Research Environment: An Experimental Study of Scientific Inference,” 1977)
  • R.A. Griggs and J.R. Cox (British Journal of Psychology, 73, pages 407-420, “The Elusive Thematic Materials Effect in the Wason Selection Task,” 1982).
  • Anthony Greenwald, Anthony Pratkanis, Michael Leippe, Michael Baumgardner (Psychology Review, 93-2, pages 216-229, “Under What Conditions Does Theory Obstruct Research Progress,” 1986)
  • J. Koehler (Organizational Behavior and Human Decision Processes, 56, pages 28-55, “The Influence of Prior Beliefs on Scientific Judgments of Evidence Quality,” 1993)
  • Review of General Psychology, 2, pages 175-220, “Confirmation Bias: A Ubiquitous Phenomenon in Many Guises,” 1998)
  • E. Jonas, S. Schulz-Hardt, D. Frey, N. Thelen (Journal of Personality and Social Psychology, 80-4, pages 557-571, “Confirmation Bias in Sequential Information Search After Preliminary Decisions: An Expansion of Dissonance Theoretical Research on Selective Exposure to Information,” April 2001)
  • Ted Kaptchuk (British Medical Journal, 326-7404, pages 1453-1455, “Effect of Interpretive Bias on Research Evidence,”June 2003)
  • J. Fugelsang, C. Stein, A. Green, and K. Dunbar (Canadian Journal of Experimental Psychology, 58, pages 132-141, “Theory and Data Interactions of the Scientific Mind: Evidence from the Molecular and the Cognitive Laboratory,” 2004)
  • Drew Westen, C. Kilts, P Blagov, K Harenski, and S. Hamann (Journal of Cognitive Neuroscience, “The Neural Bias of Motivated Reasoning: an fMRI Study of Emotional Constraints on Political Judgment During the U.S. Presidential Election of 2004,” 2006)

Thus, experienced investigators trying to confirm a hypothesis (the method used when building a fault tree or implied in the deductive reasoning used in most applications of 5-Why’s and cause-and-effect), will not have an “unbiased analysis” that they hope to achieve by avoiding categorization. Instead, they need a system (like the Root Cause Tree®) that focuses on a broad spectrum of possibilities. They need to use facts to select or eliminate the conditions under which the problem occurs (and thus what best practices can be used to eliminate the condition – just like the Root Cause Tree® provides). They need the guidance of the 15 Questions and the Basic Cause Categories of the Root Cause Tree® to make sure they avoid the “favorite cause” confirmation bias trap.

Fourth, almost all thinking is categorical in nature. For example, language is a categorization of certain sounds into standard meanings. Thus, a dictionary of a language is a book of categorized meanings and pronunciations. Thus, someone who opposes the use of the Root Cause Tree® because it is categorical is just replacing one well-thought-out, well-defined set of categories with another set. The new set is the one that they don’t realize that they have in their mind. Often, we have observed that the set of categories in a guru problem solver’s mind is more restrictive (as measured by the variety of outcomes in their investigations) than the categorization presented by the Root Cause Tree®. You can, therefore, think of using the guru approach (with no well thought out categorization) as trying to communicate without a standard language, without a dictionary, and without even having a standard alphabet. Imagine how effective this unstructured communication would be…

Finally, the Root Cause Tree® is not just categorization. The Root Cause Tree® is not a simple checklist. It has an expert system (the 15 Questions, the Basic Cause Categories, and the Root Cause Tree® Dictionary questions) built into it. Thus the problems encountered when using a “pick-list” of root causes have been solved by the structure and expert systems built into the Root Cause Tree®. The comparison of the Root Cause Tree® to a pick-list of root causes is a false comparison. When you see this false comparison used by those who wish to justify the use of other, less well developed, root cause analysis techniques, you will then realize that their system can’t compare to the robust, proven tools used by TapRooT®, including the Root Cause Tree®. Therefore, they have developed a weak straw man to make their system look superior in comparison to a purposefully chosen weak system – a simple pick list.

Our research and experience, in addition to independent research on confirmation bias, shows that the structure and categorization used in the Root Cause Tree® doesn’t need to be apologized for. Rather, the structure and categorization of the Root Cause Tree® is a vast advantage over other non-structured, poorly categorized techniques that don’t have expert systems built into them, such as 5-Why’s, cause-and-effect, and fault trees.

The next time you are asked to defend the Root Cause Tree® versus root cause analysis based on cause-and-effect analysis, fault trees, or 5-Why’s, you will be armed with the facts that show the superior design of the TapRooT® System.
(more…)

What’s Wrong with 5-Whys??? – Complete Article

Posted: October 30th, 2005 in Root Causes

I wrote this as a series of articles, but I thought I would publish it once more as a complete single posting. So here is complete reasoning on wht you should not use the 5-Why technique.

– – –

A former TapRooT(R) User who now works for a company that uses the “5 Why” technique sent the following:

Hi Mark,

As a “former” licensed user of TapRooT while with **********, I was left wanting more information after reading the e-Newsletter. Perhaps you do not have time to respond in detail, but if you could point me in the direction……

What exactly about the “why” five fails to produce true root causes analysis?

My interest is based on the fact that ********** uses the Why five method. As a side note….my present employer, ******* ****** *******, also uses the why five method.??

Thank you in advance for any information you are able to provide.

Bruce

– – –

Bruce:

Here is your answer.

(more…)

Systems, Root Cause Analysis, & Performance Improvement

Posted: October 3rd, 2005 in Root Causes, TapRooT

What do systems, root cause analysis, and performance improvement have in common?

(more…)

Connect with Us

Filter News

Search News

Authors

Angie ComerAngie Comer

Software

Barb CarrBarb Carr

Editorial Director

Chris ValleeChris Vallee

Human Factors

Dan VerlindeDan Verlinde

VP, Software

Dave JanneyDave Janney

Safety & Quality

Garrett BoydGarrett Boyd

Technical Support

Ken ReedKen Reed

VP, Equifactor®

Linda UngerLinda Unger

Co-Founder

Mark ParadiesMark Paradies

Creator of TapRooT®

Per OhstromPer Ohstrom

VP, Sales

Shaun BakerShaun Baker

Technical Support

Steve RaycraftSteve Raycraft

Technical Support

Susan Napier-SewellSusan Napier-Sewell

Marketing & Communications Strategist

Wayne BrownWayne Brown

Technical Support

Success Stories

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

Bell South

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

Bi-State Development Corporation
Contact Us