site map Root Cause Methodology and Tools for Improved Operations
Home
About TapRooT®
Course Info
Summit Info
Software
Equipment Troubleshooting
Weblog
Store
Support
Contact Us

Archive for the ‘Root Cause Analysis Tips’ Category

TapRooT® Summit - Best Practice Presented by Buck Griffith

Wednesday, March 10th, 2010

Linda Unger & Michele Lindsay facilitated a TapRooT® User Best Practice Sharing Session at the 2009 TapRooT® Summit. The video below shows one of the best practices that was presented by Buck Griffith for his group. Watch and learn …


For information about the 2010 Summit, see:
http://www.TapRooT.com/Summit.php

TapRooT® Summit - Best Practice Presented by Steve Cavanaugh

Wednesday, March 3rd, 2010

Linda Unger & Michele Lindsay facilitated a TapRooT® User Best Practice Sharing Session at the 2009 TapRooT® Summit. The video below shows one of the best practices that was presented by Steve Cavanaugh for his group. Watch and learn …


For information about the 2010 Summit, see:
http://www.TapRooT.com/Summit.php

1 person likes this post.

Root Cause Analysis Tip: What does excessive lifting mean and is there an easier way to calculate it?

Wednesday, March 3rd, 2010

While performing your PROACTIVE TapRooT® Root Cause Analysis, you observe a person loading a pallet with 10′ L x 6″ dia. 30 pound metal pipes by himself. He lifts 30 pipes an hour 3 times a day from a rack waist high to a pallet placed on timbers floor level. This task used to be performed by two loaders before recent lay offs, so you go to the Root Cause category of Excessive Lifting and see these two questions in the Root Cause Tree Dictionary:

* Was the issue related to excessive lifting or force to move an object?

* Did the task require repetitive motion (lifting, twisting, bending, etc.) that lead to a musculoskeletal problem?

Since this is a Proactive Assessment there are no issues yet, so your are asking what is the worse issue that could occur by the lifting movements above? Now what does excessive mean? What would excessive lifting, twisting and bending be? We could bring in an external Ergonomic Expert… or we can use a simple calculation ourselves first?

A simple calculator: http://www2.worksafebc.com/calculator/llc/liftlower/Default.htm

201003012231

A little more technical: http://www.osha.gov/SLTC/etools/electricalcontractors/additionalreferences.html

NIOSH 1991 Lifting Calculator. Centers for Disease Control and Prevention (CDC), National Institute of Occupational Safety and Health (NIOSH), 208 KB ZIP*.

201003012227 201003012229

As you start doing these calculations, you should also see another Root Cause under Human Engineering start becoming very apparent: Arrangement / placement.

A question that comes to mind from the Root Cause Dictionary is:

* Did poor arrangement, placement, or situation of equipment, displays, or controls contribute to an issue?

So with these new found calculators and a better understanding of just a little bit of the Root Cause Tree Dictionary is this task a risk or not:

” You observe a person loading a pallet with 10′ L x 6″ dia. 30 pound metal pipes by himself. This task used to be performed by two loaders before recent lay offs.”

Post your response!

3 people like this post.

Monday Accident & Lessons Learned: Chief Dies After Electrical “Accident” on the Aircraft Carrier USS Romald Regan

Monday, March 1st, 2010

The Associated Press reported that Chief Electrician’s Mate John G. Conyers suffered a severe electrical shock and was later pronounced dead at Sharp Coronado Hospital.

The AP reported that the Chief was conducting “routine work” when he was killed.

Normally, Chiefs are supervising, not performing, work. And there is nothing “routine” about working with electricity aboard a ship. Complacency (routine) with electricity on a ship is a deadly combination.

One of my early shipboard jobs in the Navy was being the Electrical Division Officer aboard USS Arkansas (a nuclear powered cruiser). One of the first “performance improvement” programs I ever attempted was to re-instill respect for electricity and get 100% compliance with our lock-out/tag-out program to isolate and check dead all sources of voltage during electrical maintenance work.

People who work with any hazard (for example, electricity), tend to become complacent over time. I’m not sure if this happened on the USS Ronald Reagan, but it certainly is a problem that every manager/supervisor who supervises people who work with a hazard has to confront head-on.

Also, supervisors can frequently be tempted to do work and even take shortcuts to get a job done. This takes them out of their roll to supervise a job and make sure it is done safely and puts them into a dangerous situation where no one is looking over their shoulder to make sure the job is done safely. Once again, I have no evidence that this happened aboard the USS Ronald Reagan, but I’ll be interested in what the eventual accident report has to say.

What can we learn from this fatality BEFORE the investigation is even completed?

First, TapRooT® Users would be getting a complete picture of WHAT happened before they started analyzing WHY it happened. As you can see from my background, there are several problems that I would automatically look for. But, TapRooT® requires the investigator to look at the evidence first before starting the root cause analysis. They have to have a good, complete, accurate, detailed SnapCharT® before they identify the accident’s Causal Factors and find each Causal Factor’s root causes.

Second, TapRooT® Users have a systematic root cause analysis technique, called the Root Cause Tree®, that helps them be sure to check for the many different potential root causes of a problem (Causal Factor). The tree helps guide them to areas they may not have thought of to investigate before. It helps the investigator get beyond blame to find real, fixable root causes that, when fixed, can prevent future accidents.

Third, once the root causes are identified, TapRooT® has a module called the Corrective Action Helper® that helps the investigator develop effective corrective actions. This helps the investigator and management develop corrective actions that might be “outside the box” as far as their experience with corrective actions is concerned.

If you are a TapRooT® User, you have already learned these lessons (but it is good to have them reinforced).

If you are NOT a TapRooT® User, get to a TapRooT® Course NOW! Investigating smaller accidents, incidents, and near misses, as well as using the TapRooT® techniques proactively, can help you avoid major accidents and keep your employees safe.

For more TapRooT® information, including success stories from TapRooT® users, see:

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

And for more information about TapRooT® Courses, see:

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

3 people like this post.

Root Cause Analysis Tip: “Training”… the most misunderstand and misapplied Root Cause of them all!

Wednesday, February 24th, 2010

What would your answers be for the Homework Questions below?

201002240929
What is the answer when a TapRooT® instructor asks the class, “what are the three most frequent types of Corrective Actions?” Training shows up on every list! We then encourage students to look outside the box and even give industry accepted best practices in our Corrective Action Helper®.

STOP! Does this mean Training should not be a Corrective Action or a Root Cause? NO! It just means that you should understand the problem and behavior before you select Training as a “catch-all” or a “magic bullet”.

Understanding Training?

First off understand that Training has one initial goal: IMPROVE or SUSTAIN PERFORMANCE on a particular BEHAVIOR.

Second, Training is directed to the person doing a particular task. Regardless of the higher level regulatory requirements and internal company policy of how the training program should look or run… Training must be effective for the user.

Third, Training is not an independent function that can stand up on its own…..

A. Employee Hiring must be tied to core skills and task required of the employee.
B. Finance, Engineering, Quality Departments, and Safety must be tied to the Training and Hiring Group to ensure new processes and needs are incorporated and tie in the business case.

Here is a recent article where we discussed “common sense’s” role in Training: Root Cause Analysis Tip: Part 2: Behind Closed Doors with A Common Sense Discussion

Finally, understand that there are four other Basic Cause Categories that will have an impact on what and who is trained:

A. Human Engineering (Level of Usability and Complexity of equipment and task)
B. Work Direction (Level of Qualifications and Supervision for and during the task)
C. Procedures (Quantity of steps performed during a task and risk of missing a step or performing the step incorrectly)
D. Communication (Focusing on person’s ability to understand AND apply the terminology)

Lastly, I asked about Training Effectiveness as it relates to metrics in the Homework Questions above. What might the Chart below depict as it relates to Training?
201002240957
Often, I have seen this chart track two types of measures: Training Expenditures and Defect or Incident Expenditures…. usually there is a strong correlation between both charts once mapped out after the fact. What do your metrics show?

2 people like this post.

TapRooT® Summit - Best Practice Presented by William Missal

Wednesday, February 24th, 2010

Linda Unger & Michele Lindsay facilitated a TapRooT® User Best Practice Sharing Session at the 2009 TapRooT® Summit. The video below shows one of the best practices that was presented by William Missal for his group. Watch and learn …


For information about the 2010 Summit, see:
http://www.TapRooT.com/Summit.php

1 person likes this post.

TapRooT® Summit - Best Practice Presented by Ryan Cezair

Wednesday, February 17th, 2010

Linda Unger & Michele Lindsay facilitated a TapRooT® User Best Practice Sharing Session at the 2009 TapRooT® Summit. The video below shows one of the best practices that was presented by Ryan Cezair for his group. Watch and learn …



For information about the 2010 Summit, see:
http://www.TapRooT.com/Summit.php

1 person likes this post.

Root Cause Analysis Tips - Proactive; Work Smarter, not Harder!

Wednesday, February 17th, 2010

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

One of the questions I get frequently is “what if I don’t want to do an investigation on every issue?” A good example would be large numbers of audit findings, near misses, or minor injuries (like a paper cut). I would like to share my views on that question in this week’s tips.

You know your issues and your resources. It is a business decision how much time you want to spend on any given issue. One of the things we talk about in our courses is the iceberg theory; even if you have not been to a course you might be familiar with this theory.

When really serious incidents happen (the top of the iceberg), most organizations will do a thorough investigation with root cause analysis. But what happens for things further down the berg, such as a recordable injury or minor spill? What we say is that you should still do investigations on as many of these as you possibly can. The more you do, the more problems you will fix. But what about the things below the water…………?

Granted, you might not have time to do investigations on all your issues. And if you did, and did not take the time to do them properly, you would really be wasting your time and resources, and reacting to trends that are not valid. What I would suggest would be that in these cases, you do a really good job of categorization and trending, and then do a thorough root cause analysis on the major trends. You can simply Pareto out your issues and start attacking the main ones. But how…?

In our courses we teach you how to map out a process and audit proactively to identify the “significant issues,” the equivalent of causal factors in a reactive sense. Have you ever thought about doing that with your trends?

If you Pareto your audit findings or minor injuries, for example, you will see your biggest issues. You then map out the process to see what the problems are, and then do root cause analysis and corrective actions on those problems. You might find that some of the items you Pareto out might be part of the same process. For example, let’s say you are working in a retail environment and two of your biggest audit findings are “compliance signage missing” and “compliance signage with incorrect revision dates.” You have two issues, but they are both related to the same process, so you map out the process related to issuance and placement of signage, do root cause analysis and corrective action, and you can get both of these off your Pareto chart! Then you move to the next issue…!

I hope this discussion helps you think about things in a different way. Like they say, work smarter not harder. None of us has time to waste.

By the way, in order for this to work for you, your trends have to be valid. One of our special pre-summit courses is the two-day advanced trending course, but did you know that we also offer this course onsite? If you are interested in having us come to your site to conduct this course, call us at 865-539-2139.

Root Cause Analysis Tip: Reviewing a TapRooT® Investigation

Tuesday, February 16th, 2010

Several people have asked me:

“What should management look at
when reviewing a TapRooT® Investigation?”

I thought…

“That’s a great question,
I should write something so that
everybody can read and comment about it.”

I thought that I would provide the guidance by breaking up the suggestions by the 7-Step TapRooT® Reactive Investigation Process that is detailed in Chapter 3 of the TapRooT® Book (Copyright 2009, used here by permission).

NOTE: If you don’t understand the terminology or reasons for the management actions below, it could be that you need more TapRooT® Training!

201002151421.jpg

TapRooT® 7-Step Reactive Investigation Process

STEP 1

So let’s start with Step 1: Planning the Investigation - Getting Started.

Since we are just getting started, there is nothing for management to review. However, management does have several responsibilities.

a. Management needs to set criteria for what gets investigated. This should be documented in the site’s incident investigation procedure. Management should then make sure that all incidents are reported and investigated. Occasionally, management will identify an incident that doesn’t meet the criteria, but still, in their opinion, deserves a complete investigation and root cause analysis.

b. Management should make sure that their site is prepared for investigations. This includes having an investigation procedure, trained investigators, and investigation review process, and trained management. See the TapRooT® Book (Chapters 3 and 6 and Appendix A and C) for more information.

c. Management should ensure that evidence is preserved for the team.

d. Management should make sure they they have assigned an adequate investigative team to perform the investigation and that the team has all the resources and support that they need. Depending upon the seriousness of the investigation, the team may include independent facilitators or coaches to help the team and outside experts for technical guidance. Management should assign an independent (not from the organization involved in the incident) Team Leader for all but the most minor investigations. The Team Leader should be thoroughly trained (probably in the 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Course).

e. Management should agree to an initial investigation scope (although the team should have the freedom to enlarge the scope based on the facts discovered during the investigation).

STEPS 2 & 3

Next, come Steps 2 & 3. I include these together because the main aspect that management will be reviewing is the team’s SnapCharT® with the incident’s Causal Factors. Management should make sure that:

a. The team has a detailed, logical SnapCharT® that is based on the evidence (facts) about the incident. Each Event and Condition should have a factual bases and not be an assumption (unless the reason for not verifying the assumption is adequately explained).

b. The evidence cannot support alternative scenarios.

c. All facts (not just those that supported this sequence of events) were considered.

d. Each Event includes the “Who did what” or “What did what” to clearly indicate the action that occurred.

e. ALL Causal factors have been identified (including those that were a “catch” for an error). May want to consider the using Safeguard Analysis to check the completeness of the Causal Factors.

f. The Causal Factors are the big picture causes of the incident and are not root causes. (They meet the definition of a Causal Factor and are at the “most general” end of the “So What?” chain.)

g. All Causal Factors have the associated information about them grouped together under the Causal Factor.

h. Only job positions (not people’s names) are used on the SnapCharT®.

i. Emphasis adjective are not used on the SnapCharT® (just state the facts - quantified when possible).

j. The Causal factors are repeatable and sufficient to cause the Incident.

STEPS 4 & 5

Next come Steps 4 & 5 - finding the incident root and generic causes. For these two steps, management should ensure that:

a. The team took each Causal Factor though the Root Cause Tree®.

b. Each root cause has evidence to support the finding and that the evidence provides a “Yes” answer to one of the questions in the Root Cause Tree® Dictionary.

c. The evidence is on the team’s SnapCharT®.

c. Management System root causes were considered.

d. The team checked for previous similar incidents and previous ineffective corrective actions.

e. Generic causes were considered for each root cause that was discovered.

f. The scope of the problem (Extent of Condition) and the scope of the cause (Extent of Cause) was considered in analyzing the root causes’ generic causes.

g. There is evidence to support the finding of generic causes.

STEPS 6 & 7

The final management jobs in Steps 6 & 7 are to ensure that sufficient corrective actions are adopted and implemented to prevent recurrence of this incident and, if applicable, similar incidents. Therefore, management should ensure that:

a. Each root cause/generic cause has a corrective action.

b. The corrective action is SMARTER.

c. The investigation team considered the recommendations in the Corrective Action Helper® (check their recommendations against the Corrective Action Helper®).

d. For a significant incident’s root causes, Type 1-4 corrective actions are used (see below). Preference should be given to removing the hazard if possible, next removing the target, and then guarding the target.

201002151526.jpg

(From the TapRooT® Book. Copyright 2008. Used by Permission.)

e. Any corrective action that includes a “re” should be questioned. (For example: retrain, remind, and re-emphasize.) “Re” corrective actions are just repeating actions that didn’t work in the past. Why do we expect them to work now? Also, note that if the corrective action is counseling an employee to remind them about rules or procedures, this is “re” corrective action and should not be used alone, but must be combined with other behavior change techniques.

f. Reject any corrective action that includes these words - Ensure, Assure, Insure, Make Sure - unless the team can explain how they will make sure that the change occurs (and this additional information should be included in the corrective action to make it specific).

g. Corrective actions that are studies be carefully evaluated to see why the study has to be delayed and can’t be completed before the investigation is concluded. (Examples of studies are: Investigate, Evaluate, Consider, Analyze.)

h. Any corrective actions that require behavior to change have considered what factors are causing current behavior and how these will be removed and what rewards/incentives and punishment will be clearly linked to the desired behavior to make it occur.

i. Training is not used as punishment or to embarrass an employee.

j. The scope of the problem (Extent of Condition) and the scope of the cause (Extent of Cause) were considered in developing corrective actions and are documented on the SnapCharT®.

k. The people responsible for implementing the corrective actions and the people impacted by the corrective actions agree that the corrective action will be effective.

l. Corrective action will be sufficient to eliminate significant risk or if additional Safeguards or process redesign need to be considered because the risk is so significant.

m. Corrective actions are assigned to the appropriate individual/organization for implementation.

n. The organization responsible for corrective actions has adequate resources to implement the corrective action by the assigned due date.

o. The corrective actions are tracked, and if significant enough, verified, and validated. Management should periodically be updated on corrective action status, especially overdue corrective actions.

p. Significant corrective actions are periodically checked (audited) to ensure their continued effectiveness.

q. Significant corrective actions that may impact other facilities are shared within a corporation.

r. Names of employees are not used in the report.

s. Emphasis adjective are not used in the report (just state the facts).

t. Pictures are used effectively to help explain what happened in the report and presentation.

u. Rewards are given for good investigations.

v. Evidence and reports are retained to meet any legal requirements.

Not every one of these “management must” items must be performed by a manager for each investigation. Management can set up systems , review teams, or review boards to help ensure the quality of investigations.

- - - -

Now for your comments … What do you think? Additions? Deletions? Modifications?

And how is your site doing to make sure the TapRooT® Process is being used correctly, efficiently, and effectively?

By the way, many of the points above originally were shared as best practices at the TapRooT® Summit. If you would like to keep up with the latest TapRooT® best practices, attend the 2010 TapRooT® Summit in San Antonio on October 27-29.

5 people like this post.

TapRooT® Summit - Best Practice Presented by Renauld Washington

Wednesday, February 10th, 2010

Linda Unger & Michele Lindsay facilitated a TapRooT® User Best Practice Sharing Session at the 2009 TapRooT® Summit. The video below shows one of the best practices that was presented by Renauld Washington for his group. Watch and learn …


For information about the 2010 Summit, see:
http://www.TapRooT.com/Summit.php

Root Cause Analysis Tip: Part 2: Behind Closed Doors with A Common Sense Discussion

Thursday, February 4th, 2010

Part 2, as promised, is a discussion on our TapRooT® Users and Friends LinkedIn Group.  This begins with a question asked by Jason Laws, a plant manager and client. Join us if you want to get into this conversation or even just to contact Jason directly.

201002041519201002041520

“Common Sense, the Root Cause Tree and a perceived recent lack in the up and coming work force that I have noticed”

My Production Supervisor asked me the other day if there was a place in the root cause tree for Common Sense. I actually said, I didn’t think so. That when we come across “a common sense” causal factor the root causes are usually identified in a Management Systems, Training, and Procedures…. I may really be wrong there….I hate to think it would be in work direction and I am running into more and more unqualified candidates.

Where I have struggled recently is with this very idea. Some things, it would never have occurred to me that we would need to drill training down to that level.
(It was common to police up your work site at the end of a job. When cutting you always cut away, use the right tool for the right job, there is very little in the world that is fit to bang on other than nails, use a chalk line and plumb bob to put up a line of pipe supports, place the labels on the totes level and neatly, check the breaker when the pump won’t start, ….These are just the ones that have come to mind but the list continues.) [ I don't put in don't dead head or run a pump dry. I've been doing this too long to expect that.]

That does bring me to one point I have tried. That is the Poke Yoke or “Error Proof” things. All pumps go in with a Power Monitor shut off now. You can’t run it dry or dead head it.

Still, I am with my Production Supervisor…and have had the same conversation with my Maintenance Director. Is there a place for Common Sense in the root cause tree? Am I the only one? Is the work force changing? Has Nintendo killed the opportunity to get the basic knowledge I and others did with chores, play, hobbies and jobs when were young? If so, what can be done? If the answer is drill spac, training and procedures deeper down into the core knowledge, how do you know how far and how to you identify knowledge that you take for granted that really isn’t.

Sorry, if that was a bit of a ramble, but the Production Supervisor really got me curious.

Thanks All,

Jason

Now the rest of the discussion from the TapRooT® Users and Friends LinkedIn Group

Response from: Christopher Vallee, Senior Associate and TapRooT® Instructor

ah…back to the when I was young, I walked up hill to and from work and pushed double the product you youngin’s push out and with no mistakes!

First off Jason you are right, many of the new employees of today have different skills sets than us old folks…. of course they would tell us it was “common sense” not to upgrade your software with out….etc… AFTER we locked up our computer. After all, didn’t we know this was not compatible for this computer.. duh!

At the same time the craftsman-apprentice relationship from years back no longer exists in many industries. Often it is the junior employee training the junior employee. The senior experienced employee is too busy fixing things to train anyone and often retires without documenting what s/he knows from experience.

The thought that any worker selection process, training process, and mistake-proofing remain stable and does not need to be flexible is a myth. Look at job descriptions, many are outdated, impacting the hiring process and training process.

First attack at the problem:

1. Identify the core skills needed by the employee to perform the core critical tasks for her/his job. Look up AMOD/ DACUM

2. Identify where the employees actually get the needed training. Often training programs get stuck looking at just missed appointments and regulatory required training, thus losing contact with the how the training impacts operations. (Where did the senior workers get their knowledge?)

3. Review the employee’s supervisor’s skill’s and training as well. Often new managers are hired based on needing to have a degree but never get the technical training listed above. The employee then asks the supervisor is this good enough…. how would s/he know?

4. If the training program is outdated (or just broke), then temporarily bring in a knowledgeable mechanic that has a retired and let them help revamp the new program with hands on training.

So if the employee needs a mechanical aptitude to perform certain jobs, then why was s/he not tested prior to hiring? After all, what happened to the unskilled in years past if s/he could not meet the aptitude need? S/he was either trained or kicked out the door.

After all, if common sense where the answer, you would not need the root cause tree either. So GOAL (go out and look) to find what the core skills and tasks are and then ensure that these requirements are met. Also see what you can learn from the new employees as well.

Posted 1 month ago | Delete comment

Response from: Kenneth Reed, Senior Associate and TapRooT® Instructor
You’re right, Jason. There is no Root Cause labeled “common sense NI” anywhere on the Root Cause Tree®. Just like there is no “attention to detail NI” or “operator error.” Although they initially seem like root causes, in reality they are just a convenient way to shift blame.

For example, if I told you the Root Cause was “common sense NI,” what would be your Corrective Action? How do you fix “common sense?” You can’t! Just like you can’t fix “inattention to detail” or ” operator error.” Therefore, we would default to poor Corrective Actions like, “Counsel the employee on using common sense when using a knife.” Completely useless Corrective Action, with almost no hope for better performance.

Instead, we need to look a little deeper at the problem. This is what Chris was alluding to above. Why did the operator slice his hand open? Was it really just a common sense problem? Or is there something we as management can do to prevent this issue?

That’s where the 15 questions, the Dictionary®, and the Root Cause Tree® come in. We need to ask ourselves the questions on the tree to dig deep enough into the problem. Instead of asking, “why didn’t this guy use common sense when cutting that wire, and cut away from himself?”, maybe we should ask:

- Was the worker fatigued, impaired, upset, bored, distracted, or overwhelmed?
- Was he using the right tool? Did we provide him with the right tool?
- Was the right person performing this job?
- Was this job really required in the first place?
- Do supervisors ever watch their people do this particular job? Why not?
- Would a supervisor have stopped this evolution before an injury occurred? If so, why didn’t he? If not, why not?
- Was the worker properly trained for this task?
- since I’m sure the worker did not intend to cut himself, what lead him to think doing the job in this manner was OK?

I could go on, but you get the point. When you find yourself saying, “This was just a dumb person, not using common sense, just a simple human error that I have no control over,” it’s time to step back and let the system work for you. Let the Root Cause Tree® and Dictionary® help you ask the right questions.

I also know that sometimes we think that people should already know these things. There are 2 possibilities:

1. The person really didn’t know (to cut away from himself)
- Therefore, this is a training issue
2. The person DID know, but chose to do it anyway.
- This is when my discussion above comes into play.

Hope this helps a little.

Posted 1 month ago | Reply Privately | Delete comment

Response from Jason:
Thanks Chris and Ken. One thing I have been trying to do, and encouraging my people to do (though finding the resources is always the challenge) is to use TapRooT® in audit mode.

I have worked the tree through these issues and developed corrective actions to account….mainly training, human engineering and Management systems.

My frustration can come from I just haven’t seen or anticipated the lack of knowledge in the first place to head it off at the pass. I am not even sure some of these issues would have occurred to me if I was putting together an audit SnapChart®.

Thinking on this thread, maybe the broader use of CHAPs might catch some of this. In a resource starved environment, I am trying to bring the tools I have to the best and most efficient use.

So, with GOAL. Maybe an Audit SnapChart®, the 15 questions, a CHAP and the Dictionary® I prevent some of these.

The struggle that remains is to overcome the blind spot of assumptive experience and figure out what needs to be trained for in the first place. What are the things we take for granted that really aren’t.

Once again. Thanks guys. I appreciate the feedback.

Posted 1 month ago | Reply Privately | Delete comment

Response from: Christopher Vallee, Senior Associate and TapRooT® Instructor

Music to my ears Jason…. “proactive CHAP”. When people are first introduced to Critical Human Action Profile, they look for critical steps in a task that if skipped, done wrong, or in the wrong sequence, could have caused the incident or made it worse. A proactive audit can look for steps that are critical to safety and process.

As far as the “blind spot for assumptive experience”, this is a generic issue as you have described it. So what system should be controlling the hazard of having unskilled employees on the shop floor (or in the field)?

Steps of the process:

1. Company or Contractor Human Resources hire employees that have the skills and capabilities to perform their assigned core tasks.

Problem: Metrics that HR are usually measured by for the hiring process are retention and number of new employees. No tie made to direct labor and rework.

2. Training department has a structured training program that uses classroom and hand’s on training for the cores tasks (process and regulatory).

Problem: Training is often measured by Number of missed appointments and upkeep of regulatory training. No tie made to direct labor and rework costs.

3. Shops have floating experts identified for employees who need a little help.

Problem: The new are training the new. The senior employees are too busy to.

So ask your HR department and your training department, how do they know that they have been successful when hiring and training a person? Most likely it will not be tied to operations ROI. .

Have senior employees attend training with new employees to help all do right.

Look at your critical job’s and tasks to determine what skills and capabilities should be covered for each person and then use GOAL to identify what is missing.

Posted 1 month ago | Delete comment

1 person likes this post.

TapRooT® Summit - Best Practice Presented by Stephen Wagner

Wednesday, February 3rd, 2010

Linda Unger & Michele Lindsay facilitated a TapRooT® User Best Practice Sharing Session at the 2009 TapRooT® Summit. The video below shows one of the best practices that was presented by Stephen Wagner for his group. Watch and learn …


For information about the 2010 Summit, see:
http://www.TapRooT.com/Summit.php

Root Cause Analysis Tip: Using TapRooT® in Criminal Investigations

Saturday, January 30th, 2010

    I have had some discussions concerning how you might use TapRooT® in criminal investigations.  For example, how would TapRooT® work for a murder investigation?  After all, TapRooT® is designed to be used to get to the root cause of why people make mistakes.  When you have something like a murder, you are more into intentional acts.  Where would you put this on the Root Cause Tree®?  Some thoughts…

I would recommend looking under the Natural Disaster / Sabotage area.  This is where intentional acts would be categorized.  The investigation would then be turned over to a law enforcement-type investigation.

I’m not saying that TapRooT® is therefore not able to be used for any part of the investigation.  The SnapCharT® is an ideal tool for evidence collection, and in fact, law enforcement agencies use a rudimentary form of charting for just that purpose.

You could also use Safeguards Analysis to help you figure out how you might have been able to detect, prevent, or mitigate the consequences of the criminal act. 

Note that most crimes are not completely willful, and TapRooT® does a great job with that.  Drunk driving, friendly fire, etc may be analyzed using TapRooT® with great results.

TapRooT® Summit - Best Practice Presented by Jeffery Hubbartt

Wednesday, January 27th, 2010

Linda Unger & Michele Lindsay facilitated a TapRooT® User Best Practice Sharing Session at the 2009 TapRooT® Summit. The video below shows one of the best practices that was presented by Jeffery Hubbartt for his group. Watch and learn …


For information about the 2010 Summit, see:
http://www.TapRooT.com/Summit.php

Root Cause Analysis Tip: Where Do You Need to Install Cameras and Microphones to Improve Your Investigations?

Friday, January 22nd, 2010

USA Today reported:

WASHINGTON — Accident investigators uncovered such egregious behavior by train operators in the fatal 2008 accident near Los Angeles that they suggested Thursday that all railroads monitor crews with video surveillance.

In a controversial recommendation intended to draw a line in the sand against the rapid rise in accidents triggered by distractions from cellphones and other technology, the National Transportation Safety Board (NTSB) not only endorsed placing video cameras in train cabs, but said railroads should regularly monitor the videos to ensure that engineers follow safety rules.

These recommendations by the NTSB will not only help improve the accountability for and the enforcement of SPAC (Standards, Policies, and Administrative Controls), they will also make future investigations much easier.

Have you thought about video/audio monitoring of key personnel and workspaces to provide increased accountability, better enforcement of SPAC, and better root cause analysis?

Maybe now is the time to suggest it…


TapRooT® Summit - Best Practice Presented by Dan Evans

Wednesday, January 20th, 2010

Linda Unger & Michele Lindsay facilitated a TapRooT® User Best Practice Sharing Session at the 2009 TapRooT® Summit. The video below shows one of the best practices that was presented by Dan Evans for his group. Watch and learn …


For information about the 2010 Summit, see:
http://www.TapRooT.com/Summit.php

Root Cause Analysis Tips – Staying Current, Improving, and Leveraging Partnerships

Wednesday, January 13th, 2010

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

If you have been to a TapRooT® course, you may remember that in our opening comments, we talk about theory and the reasons businesses need advanced root cause analysis using an expert system; we say “the changing world of work requires advanced root cause analysis.” What is interesting about that statement is that if you think about it, people (i.e. human nature) really have not changed that much over thousands of years; their motivation and behaviors are very consistent. However, the work environment HAS changed; just think about the last 100 years. In fact, just think about the last 20 years; the change we have seen has been unbelievable. Our systems have to evolve with the times, and we as individuals need to continue to build our knowledge and effectiveness. It is not easy, and that is what I wanted to talk about today.

First of all, how do I continuously improve my organization’s use of TapRooT®? If you have been to a course and started using the system, you have become comfortable and have been seeing results. But don’t get too comfortable, there is still work to be done! First of all, have you read the TapRooT® book? If not, go read it! I can guarantee you will learn some things that will help you, and for those of you that are long time users, it will be a great refresher. Next, do you and other trained users share your investigations and audits to put another set of eyes on them and get feedback? This is a great way to help each other and sharpen your skills. Do you consistently follow the process and always use the Root Cause Tree® Dictionary and Corrective Action Helper®? The more disciplined you are, the better your results will be, and the time you spend in the dictionary and helper will sharpen your knowledge of the best practices available to you as part of the expert system. Finally, if you are very effective in your area, how else can the organization benefit? Is the organization fully integrated? Do safety, environment, quality, regulatory compliance, security, continuous improvement, production, and reliability groups all use TapRooT®? If not, think about how you can expand the company’s use of a system that has provided results to your group. If you need help thinking about ways to expand TapRooT® in the organization, give us a call.

Now that we talked about using TapRooT® in your organization, let’s get personal. What are you doing to expand your knowledge and your network? I believe this is very important. What kind of industry groups do you belong to? What kinds of publications do you subscribe to? What blogs do you visit (in addition to this one!) Have you planned recurrent or new training and conference attendance for this year? Do you need another certification to advance your career? Do you have peers from your and other organizations you can bounce ideas off of or just ask for help? It is amazing what you can learn from meeting people in your business/discipline and other businesses/disciplines. In fact, you might learn more from someone outside your world than from within it! All of these things I mentioned take time and effort, some of them are free, and some cost money. But they can all work for you if done properly.

By the way, before I close, are you a member of Linkedin? If not, you should join! Get connected to your peers. Join some groups, and monitor the discussions. This is free and you have access to some really smart people. All of us at System Improvements have profiles, so invite us to connect! And join the TapRooT® Root Cause Analysis Users and Friends Linkedin group! We want to make this a forum for all of us to discuss TapRooT® and other important topics, and we can only do that if you are onboard! Please join us.

I hope some of what I’ve talked about has given you some things to think about and more importantly, take action on. After all, the “changing world of work” requires it! Best wishes for your improvement efforts this year. Let us know how we can help.

Root Cause Analysis Tip: Use of Checklists

Wednesday, January 6th, 2010

Yesterday, I posted an article that discussed the advantages of using checklists in the medical profession (see this link).  I thought I’d talk a little more about checklists, and how the use of checklists shows up on the Root Cause Tree®.

Let’s look at a reactive incident, where someone made a mistake while performing a common yet labor-intensive evolution.  For example, a mechanic was starting up an expensive compressor, and he forgot one step, causing serious damage to the machine.  He has done this evolution several times and is familiar with the equipment, but this time, one step out of 16 was missed.  This is a very typical example, and your analysis must take into account many different possibilities.  Happily, TapRooT® walks you through the analysis to make sure you don’t forget to check everything.  The Root Cause Tree® and Dictionary® will have you check many potential problems (fatigue, equipment design, work environment, supervision, etc).  However, I’d like to concentrate on:

“When should we expect to have a checklist in place?”

Looking at the Corrective Action Helper® under no procedure, we get some ideas concerning when a step-by-step checklist makes sense. 

- First of all, if a new checklist had been in place, would performance have improved?  Would this mistake have been prevented?  Sometimes, the task is so obvious that having a checklist would not fix anything.  If this is the case, don’t write a silly checklist just for the sake of having a checklist.  For example, if someone forgets to wear his seatbelt, I highly doubt that putting a checklist in the cab of the truck telling the driver when and how to put on a seatbelt is going to make any difference.  This is an obvious evolution, and other corrective actions (audits of seatbelt compliance, proper rewards for wearing seatbelts, consistent enforcement of the rule) will be much more effective.

Additionally, situations where other factors have made it easy for the operator to make the mistake (poorly designed equipment, excessively fatigued workers, etc) probably need these other issues addressed first, and then evaluate whether a procedure would also help.

- The Corrective Action Helper® also states that a checklist makes sense for high risk, high consequence tasks that must be performed correctly every time and require considerable short-term memory.  Starting this expensive compressor is an example where checklist use should be considered.  Other examples include:
a. documentation of the work is required
b. extremely infrequent evolutions
c. tasks that must be performed under stress, like emergencies (both aircraft engines shut down due to a bird strike?)

What do you do when you have checklists, but people aren’t using them?  You are now under the enforcement root cause, and the Corrective Action Helper® has a load of great information on how tackle this problem.

What are your thoughts on checklists?  Do you have examples of checklists that helped?  What about a checklist that was completely useless at your facility?  Let me know what you think!

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

Monday, January 4th, 2010

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

Cell Phone Laws: Effective Corrective Actions?

Monday, January 4th, 2010

After an investigation, we often put corrective actions in place that, at first glance, seem like they ought to fix our root causes.  These corrective actions put rules in place that, if followed, will have a high likelihood of preventing that incident from happening again.  The problem is that the corrective action has to be able to be consistently applied and monitored.  If this is not possible, then the corrective action will most likely be completely ineffective. 

Let’s take a look at some of the new cell phone laws that have been put in place over the last several years.  The AAA has put together a chart of various distracted driving laws (link here).  Here are a few:

1.  It is illegal to text while driving in Tennessee.
2.  In California, rental cars must have safe operating instructions for cell phones.
3.  In Massachusetts, cell phone use is permitted as long as it does not interfere with the operation of motor vehicle. The driver must also keep one hand on the steering wheel at all times.
4.  In New Hampshire, drivers are accountable for distractions that contribute to a crash.
5.  In many states, it is illegal for drivers with learner’s permits to use a cell phone.

Let’s take a look at the law that prohibits cell phone use by drivers with a learner’s permit.  Some states have expanded this to include any teen drivers, regardless of their license status.  The purpose is obvious:  We want young drivers to concentrate on their driving, so let’s put a law in place that gets rid of that distraction.

On the surface, this seems like a good idea, right?  We want to influence teen drivers to keep their cell phones off while driving.  But what is the reward these drivers receive for following the rule?  Using our Soon, Certain, Positive motivators, we can see that the reward for following the rule is extremely uncertain.  How do you realistically enforce this rule?  Do we expect law enforcement officers to see someone using a cell phone and then determine the age and license status of the driver before they pull them over?  Of course not.  The only way this law can be enforced is if:
1.  There has already been an accident or other rule violation AND
2.  The police have evidence that the person was actively using the cell phone while driving.

Therefore, this law will very rarely be implemented.

This type of rule is a reactive rule.  Only after an accident has occurred can the rule be applied, and then only if the violation can be proven.

So how can we make this law more effective?  We need to be able to proactively enforce the rule.  This means that there needs to be an easy way for law encorcement to know when the law is being violated.  By the same token, the drivers need to know that there is a good chance that they will be caught when they are violating the rule.  I recognize that we can’t make these laws perfect.  For example, we could put a jamming device in the car that prevents cell phone use whenever the car is running.  However, this is not a REASONABLE corrective action, and therefore is a poor rule.  However, we could make the law more effective by extending the law to ALL drivers.  Now law enforcement is much better equipped to proactively enforce the rule, before an accident actually happens.  When they see someone (anyone) using a cell phone while driving, they can enforce the rule.

Take a look at the other 4 examples I gave at the top of the post.  Can these rules be effectively implemented?  How could you make these rules stronger and more likely to succeed?  You should evaluate all of your corrective actions this way if you are to expect better performance.

Root Cause Analysis Tips - What is your 2010 Plan?

Wednesday, December 30th, 2009

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

It is the end of the year, so I thought I would talk about goals. How are you going to improve performance in 2010 and what are your goals?

Many of the goals set in organizational environments are easy to predict (albeit important). For example, in the safety world, a common metric for goal development would be recordable or lost time rates. Environmental, spills and exceedences. Quality, product defects. Reliability, downtime. You get the picture. These are all good metrics and you should have goals for them. However, they are downstream and reactive. You should have upstream and proactive goals as well.

What kind of projects do you have planned for 2010? Are they included in your goals? We teach in our courses about using the root causes on the tree and the dictionary as best practices that should be in place. If you have the processes in place, you can audit them. But…you say, this sounds like a lot of work and we don’t have time! Let me float an idea by you:

For 2010, why not make one of your goals to review one basic cause category per month, make sure you have the best practices in place, and add them to your audits. By breaking it up into manageable chunks, you will be able to improve your business while managing your resources. And with 7 basic cause categories, you will be done by July! How many other yearly goals can be met by July?! Of course, the auditing would be ongoing but you are already doing that anyway. Right?

Another goal could be number of employees trained in TapRooT®. I know, this sounds self-serving but I really am trying to help you improve your business! If you are going to train people, why not establish a goal and take credit for the work you are doing? Plan now for who needs to be trained and make a schedule. If you are a licensed company with certified instructors, have your process owners and instructors develop a plan. If you are not licensed and/or do not have certified trainers, consider PUBLIC COURSES, or contact us for a license or onsite course quote.

Congratulations on all your 2009 improvements and best wishes for 2010. Let us know how we can help.

Happy New Year!

Root Cause Analysis Tip: Understanding the Safeguard is just as important as understanding the Hazard

Wednesday, December 23rd, 2009

200912230849 200912230851

A 1959 Chevrolet crashes into a 2009 Chevrolet Malibu…. who wins? Now open the Video.

Crash-1 here is another link to the Video: http://www.youtube.com/watch?v=_xwYBBpHg1I

Did you get it right? How would the SMART car hold up?200912230854

During our TapRooT® course section, I often ask students whether they think Ice is a hazard (uncontrolled energy). The first answer is often yes. The next question then is whether all ice is a hazard and the answer is… only when you walk or drive on it. Now we get to the uncontrolled energy of motion. For years many have used safety checklists looking for daily “hazards” such as no safety glasses, tripping hazards, and no fall protection… just to realize that we were looking for failed safeguards and not the uncontrolled energies that they were to protect us from. So the first tip is to have all employees look for uncontrolled energy daily.

Once you identify a hazard with no safeguard it may seem easy to select a new safeguard… but is it? Follow through is just as important in safeguards as it is in throwing a ball in the right direction. Each step is vital. If you had selected the older heavy car (1959 Bel Air) because it looked stronger what would the unintended consequences of that choice have been? Final tip of the day, make sure you have a knowledgeable person help with the selection of or improvements of safeguards.

Monday Accident & Lessons Learned (and a Root Cause Analysis Tip): Sometimes a Safety Feature Can Cause Unintended Consequences

Monday, December 7th, 2009

Watch this video…

What was the parachute meant to do?

Save the pilot if the engine failed.

What did the parachute do?

Cause a stall during a takeoff.

Can you think of corrective actions from past incidents that could have unintended consequences?

That’s why we have the final “R” in the SMARTER tool for developing corrective actions.

You should review potential corrective actions to make sure they don’t have unintended negative consequences.

Root Cause Analysis Tip: Using Equipment’s Role to help Build a Better SnapChart®

Tuesday, December 1st, 2009

200911301150
A mechanic has been burned from exposure to Hazardous Fluid and this is your Spring SnapChart®. What Events are missing from the SnapChart® above? As a trained TapRooT® Investigator, you probably want to know more about what the mechanic was working on and what PPE s/he was wearing.

In this case, the mechanic was walking by a closed system when the spray occurred. No work was being performed on or next to the ruptured line.

200911301206
Now the investigator could perform a Safeguard Analysis to find out what error allowed the Target (the mechanic) to get too close to the Hazard (the uncontrolled flow of Hazardous Material) but as a Safety and Health Incident Investigator, you still have missing events with what error allowed the Hazard to grow and what error allowed a Safeguard to fail. What do you do now if you are not an Equipment or System Expert?

First Hint, You have two key items that stand out: “Hydraulic Supply Control Valve” and “High Pressure Warning Light”. Does the Warning Light illuminate every time you open the Control Valve? How does the Control Valve Operate and What Triggers the Warning Light to come on? Think of it this way… when I turn the light switch on in a room does the light just turn on magically or are there missing events in between both Events mentioned?

So let’s work backwards from “High Pressure Warning Light Illuminated.” What triggered the light to illuminate? Have the equipment expert pull out the system diagram.

200911301240

So in order for this light to work per design… the Hydraulic Pump would need to be turned on, the Fluid would need to be pumped out of the Fluid Tank, the Fluid would need to go through the Control valve, and to the Cylinder; simultaneously, fluid is also being displaced back to the Fluid Tank through the Pressure Regulator where the Pressure Switch is installed. Hydraulic Pressure would have to exceed a certain set limit with an electrical signal sent to the High Pressure Light….. Looks like we have a lot of missing events.

200911301427
Keep in mind, as a trained TapRooT® Incident Investigator, you are still in the “What ” phase and do not know the Causal Factors or Root Causes. We do have a better idea on what happened and what Events were Missing. The next step would be to troubleshoot the failed equipment items using Equifactor® to collect more “What Facts”.

Why show this tip to non-equipment experts? Rarely have I seen an investigation that did not include some type of equipment. Understanding how a component is controlled and how it operates is key in mapping out a good SnapChart®. Often Health and Environment members avoid our Equifactor® because they do not have enough mechanical or system experience to answer the questions effectively…. of course if you think about it, as the investigator you are the facilitator getting answers out of the experts. This tool then helps you get the facts out of the experts.

Installing TapRooT® System Software in Windows 7

Wednesday, November 25th, 2009

With Windows 7 now available I wanted to let you know that we have an article that describes how to install the TapRooT® System Software in Windows 7.  The article can be found here.

Root Cause Analysis Tip: Don’t Follow Bad Root Cause Analysis Advice

Wednesday, November 25th, 2009

I saw two articles by Ronda Levine recommending “5-Whys” as a preferred root cause analysis technique and giving a 5-Why example. Here’s the example from the article:

After determining that the quality management project would focus on the cause of the image bleed on the t-shirts (because almost 2/3 of the t-shirts produced by her company show this defect), Brenda begins to ask “why” to determine the cause of the problem. At the top of a sheet of paper, she writes “2/3s of t-shirts produced bleed through the material from a severity range of barely noticeable to highly noticeable.”

Underneath this, she writes, “Why?”

“The t-shirt fabric is too thin.” This first response can’t be possible, because the company carefully researched the fabric and the ink for the project to ensure the materials would work. So, she looks for an alternate cause and comes up with:

“The ink isn’t drying fast enough.”

“Why not?” She asks the question, again, to get closer to the root cause of the problem.

“Because the presses are using too much ink.” If this is the answer, it would also solve another problem the company has been experiencing, the blurring of images printed on 1/3 of all shirts produced.

Another potential problem at this stage could be that the ink ordered wasn’t correct for the project. However, Brenda checks the inventory logs and finds that this isn’t the case.

“But why are the presses using too much ink?”

“Because the presses haven’t been properly calibrated.”

It seems as though this last answer is a contender. Brenda sits down with her project team and constructs a plan for changing the calibration on the machines.

Seems like this 5-Why example only has three whys. And is “the presses haven’t been properly calibrated” really a root cause? Seems like a Causal Factor (and just a single Causal Factor at that) in TapRooT®.

It seems like a better approach would have been to draw a generic SnapCharT® for the printing, quality control, and delivery process and then analyze all the Causal Factors rather than just one. But you would have to be TapRooT® Trained to understand how this process would work.

I left a comment at the posting referring people back to some of the previous articles I’ve written. Like this one:

http://www.taproot.com/wordpress/2009/08/26/more-bad-root-cause-analysis-advice/

I hate to be so negative, but if somebody doesn’t point out bad advice, many will start using 5-Whys thinking that it is a good idea. Therefore, I’m going to keep pointing out this “BAD ADVICE” until everyone knows the problems with 5-Whys and Cause-and-Effect.

Root Cause Analysis Tips - Work Direction

Wednesday, November 18th, 2009

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

This week I thought I would cover one of the basic cause categories - Work Direction. Work Direction speaks to who is in charge, and includes job preparation and supervision (selection of worker and supervision during work). The first notation in the dictionary under this basic cause category tells you to identify the “supervisor, team leader, or person in charge of the work.”

Let’s talk about preparation. First, let me ask a question; who is responsible for preparation, the worker or supervision? This is a trick question; the answer is “it depends” or “both.” I’m glad I could clear that up! But seriously, it does depend on your environment, the task being completed, and the associated risk. Workers are responsible for preparation and supervision is responsible for making sure preparation is adequate, so everyone involved has a piece of the pie; however, I am not one of these people who believes that everyone has to be supervised constantly, these folks are adults! You can be in charge of yourself (I hope) regardless of titles!

The first root cause listed under preparation is “no preparation.” That one is fairly straightforward – regardless of the type of preparation required, if it was not done this is what you would select. If preparation was done but did not work the way it should, then you would continue down to some of the other root causes under preparation.

For the root causes “work package/permit NI,” “pre-job briefing NI,” and “walk-thru NI,” you must consider whether those processes are used in your environment. If they are and they do in fact NI based on the facts in your investigation, then select them. If these are not part of your processes, you can consider selecting/adding them, but I would be very cautious because they are very broad in scope and will apply to many other processes. The best option is to select the root causes during step 4 and then consider whether you want to go that route during the corrective action phase of your work. I believe you should consider the risk before deciding to launch a new process like this; for example, if a mistake was made during a low risk process and your company does not use work permits, would you implement permits even though it might help? What other processes need permits? Be careful.

“Selection of worker” is also fairly straightforward; do you have the right trained people for the work and are they in the right condition to perform the work? “Supervision during work” is a little trickier, because again, we cannot supervise every one all the time or we have in effect added cost (and many times unnecessary cost). Risk has to be considered. If you have selected the proper worker/team and the task is low risk then you do not need someone looking over their shoulder. It is very easy to say they would not have made a mistake if the supervisor was there, but it is not that easy. Don’t make supervision a convenient scapegoat. Make sure you have the right processes in place and supervision should be less of an issue.

And……..don’t forget to read the dictionary!

Thanks for visiting the blog, and see you soon. Happy investigating.

Root Cause Analysis Tip: Equifactor Reference and Custom Tables

Thursday, November 5th, 2009

When using the Equifactor® module of the TapRooT® Software, you have the opportunity to store some very specific data in each Symptom or Possible Cause that can help your equipment experts with their troubleshooting efforts.  Each of these Equifactor® items has an associated Equifactor® Reference area that allows you to store your own custom data.

For example, if I want to add a new Equifactor® item for troubleshooting a diesel engine that hesitates, you would start with the System Configuration - Equifactor Maintenance, and adding your own custom Diesel Engine troubleshooting table.  You might start with this:

You could then add any extra information about that item by clicking “Edit” and adding your custom information:

You can even add a picture of your problem by clicking on “Image.”

Once you are done, you could then start a new incident and open your Equifactor® tables.  You can access the Equifactor® Reference section either by right-clicking on the item, or clicking the Equifactor® Reference button at the bottom:

The new information is now available, including the picture you attached:

This information will make a great tool for your new troubleshooters!

How Does TapRooT® Work?

Sunday, November 1st, 2009

How does TapRooT® Work?

Here’s a paper that outlines an environmental incident and how TapRooT® helped the investigator dig into the problem.

Just click on the paper below to download the pdf…

Using The Taproot® System

Root Cause Analysis Tip: Have you done your TapRooT® Homework?

Wednesday, October 21st, 2009

Trending positive or negative changes in safety is less about the numbers than you may think. To put it simply, if I do not know….

… where the number come from?
… what the number (baseline) used to be?
… what I changed to get a different number?
… who got the number for me?
… what does the number have to do with risks?

..then I might as well just report LTI’s and incidents only and hope things will get better. So what could I do to help me? Start with something I have in front of me right now, TapRooT® Categories:

Departments: Do you assign departments in your software by area of responsibility or area of risk (accident location)? Hint: Location by area of responsibility already shows up next to the names you assign to the incident.

Classifications: Do you just have “Incident”, “Near Miss”, and “Violation” as categories or do you have Injury, process hazard, and customer issues as well listed in the incident classification section? Hint: you can select more than one classification at a time in the software for each incident. This would allow you to pick type of hazard and type of incident at the same time.

Risks: Have you listed the actual hazard in each Causal Factor instead of just the error? Hint: Mechanic did not close valve (Hazard: Uncontrolled Pressure). You could then chart each type of hazard. Trying to trend by type of error does not work as well unless investigators write their causal factors the same exact way. For example, mechanic left valve open would not be grouped in with mechanic did not close valve.

The point is you must understand the processes that your safety metrics are trying to measure. You should be able to proactively measure what you changed and see what impacted your LTI’s. Doing your homework helps you assign where your critical resources (people and equipment) need to be assigned before something bad happens. Numbers are just numbers without meaning.