May 12, 2010 | Barb Carr

Root Cause Analysis Tip: Part 3: Behind Closed Doors with SnapCharT® Discussion in LinkedIn

For those of you that have NOT joined our TapRooT® Root Cause Analysis Users and Friends Group you missed this recent discussion. The question asked:

When you mapped out your first SnapcharT® on your first Incident Investigation after your first class what “Ah ha” moment did you get?

Often people are surprised when they map out their first chart and then have a person not familiar with the Incident read it…. what did you learn?

I started this discussion so that our clients can share a learning process with our friends in this group.

“Ah ha” is used to make the”Aha” moment a greater moment of realization.
From: Mike Rodriguez, Safety Specialist at ConocoPhillips


I have to chuckle. I can’t remember my first chart and they were E&CF charts back then. However, to this day, the use of a chart proves to be the most effective method for “painting the picture” of what happened.

I have done hundreds of investigations with the tool and it reliably leads to understanding what happened. Of course you have to f”eed the machine” so if you’re not getting those “ah ha” moments it may be you haven’t gathered all the information.

How do you get “all” the information? Get to the field. Take those pictures, measurements, interviews…Review the SPAC. Put it all on the Spring SnapCharT(r). Let the incident talk to you. Review the 15 questions from the TapRooT(r) Tree(r). Put your findings in the Spring SnapCharT(r). Let the incident talk to you. And, the loudest, clearest talking tool is a SnapCharT(r).


From Me: Chris Vallee, Senior Associate and TapRooT® Instructor at System Improvements

Thanks Mike for kicking off the discussion. Many people get new posts at the end of the week so I am looking for more engagement as time goes.

I like the idea of painting a picture with all the small parts…. here is an example of painting:


From: Marco Flores-Verdugo, Propietario, TECMEN SA de CV

It is difficult to remember my first SnapCharT(R) outside the classroom environment, but I can remember two very distinctive aha moments with two consulting jobs: one a thermoelectric that had a very bad accident, they were trying to blame the network. Nothing was checking out. After building a SnapCharT(R) with the results of the interviews, which lead to an audit of the automation system, we found out that the automation circuit had been modified in the field and was blocking all the self-protection sensor signals. They had three problems – the control system was modified, blocking all but one control computer; second, the control buttons were very near and an operator pushed the wrong button, and third, the generator field DISCONNECT button was not labelled according to the drawings, nor to the circuits or to the diagrams, so when time came to activate it it was not found. There were some issues in training too. They had been trained two years before and there was no refreshing of the concept once the plant finally started-up. Fortunately nobody died, but it certainly was a close call. When the client saw the SnapCharT(R) he could not believe it, that so many things were wrong and nobody had detected them before.

The second one was sea-borne fire in a transport ship. The captain could not believe that they were looking in the wrong place all the time. It was an eye-opener. _____________________________________________________________________

From: Mark Paradies, President at System Improvements
I remember my first two Aha! moments. They were in early 1986.

1. That there are multiple causal factors (not analyzing the cause of an accident – analyzing the causes of multiple causal factors).

2. That a guy who wrote an incident report was just making things up so he could get the report done because they couldn’t figure out what really happened and they had to meet a report deadline.


From: Marco Flores-Verdugo, Propietario, TECMEN SA de CV
I have to agree with Mark.
Many many times the reports are made up with little or none robust data .
You need to have something , once we had an explosion, w 3 injured in a plant in SEA, the report was made in Mexico ,without consulting with the plant!
To add insult to injury , the report was sent to SEA so that they know now what happened, and how to fix it. this was done again and again. The preffered analysis method were isle meetengs, at the home office.

From Me: Chris Vallee, Senior Associate and TapRooT® Instructor at System Improvements

Thanks Mark and Marco for your comments.

The question often asked during an investigation is whether something is a fact, a judgment, or just plain made up. How do you get though this piece… pictures, videos, reports, and immediate interviews when possible… pre-planning is so vital to a good SnapCharT®.

From: Mark Paradies, President at System Improvements

In that first case it was easy. The way they told the story … It just couldn’t physically happen. The system just didn’t work that way.

Went out to the field and talked to field folks. They showed us what they were doing to “troubleshoot” the problem. They had basic problems in the way they were trying to analyze the issue. When we fixed these, we realized that the problem only happened when the electronics heated up. Thus when tests were performed “cold” in the shop, everything worked great. The units would then be rotated back into “spares”. When they were used to replace another unit, it would take time (hours to days depending on how they were being used) to heat up. When they finally got hot … they would fail again, get replaced by another “spare”, and then go back to the shop for troubleshooting …

This had gone on for years! People said things like, “Those XXXXXX never do work right!” when about a dozen bad units were causing all the problems.

The SnapCharT® helps you see the logic (or lack thereof) behind what is happening. You have to understand what is happening before you can understand why it is happening.


From: Marco Flores-Verdugo, Propietario, TECMEN SA de CV

Interesting Mark ,
A recent issue with a track detector in an automated transfer car at a switching furnace was traced to very much the same problem, the only extra problem is that the manufacturer in (Italy I believe) was aware of the problem and did not warn the users, this we found out while making the SnapChart(R).

Another case presented in one of my classes, that I remember, was a problem with a customer that wanted to charge a large fee (several million Dollars), for what he said was a forced shut-down due to lack of supply. The client, in this case, started making the SnapCharT(R). We started exchanging questions, rabbits started to jump everywhere. They called the Management. The Management called the General Director. Then the World General Director was called, he flew to Monterrey to be in the class. At the end they were not liable for anything. There were many things wrong in their chain of supply and in their customer’s communication network. Fortunately they did not have to pay anything and the funds were used to fix their own system. They really loved the SnapCharT(R) and the TapRooT(R) system. Now they are frequent attendees to our classes. A real “aha” moment, if any.

Show Comments

Leave a Reply

Your email address will not be published. Required fields are marked *