In our courses, we teach the use of Safeguards in Step 3 (defining causal factors) and in Step 6 (developing corrective actions) of the TapRooT® 7 Step process.
I wanted to talk a little bit about Step 6 today. If you have been to one of our courses, you have seen this. If you have not but are in safety or IH, you are probably familiar with the hierarchy of controls.
Let’s start at the top. I’ll use a fictional workplace/examples:
“Removing the hazard” altogether is the best option, but it is not always possible. For example, your company, Company XYZ has a business process involving hazardous chemicals, and you have been doing this process for 20 years with no problems. One day, employees are exposed and several are sent to the hospital….a bad day at XYZ. We would like to remove the hazard, but if we do, what happens? Well, unfortunately XYZ goes out of business. Even the most hard-nosed safety people would not suggest that! But what if over that 20 year period a chemical has been developed that would perform the same process but is less hazardous to employees? You could make the switch, and that would be an example of “reducing the hazard.”
10 years ago, XYZ hired Joe Sixpack, but we had nowhere for him to sit, so we built a cubicle in the corner of the warehouse. There is no reason for where we put him, it was just an open space that looked good at the time. Unfortunately, 5 years ago we located a hazardous process near his cube, and today he got exposed….yet another bad day at XYZ. If we move his cube, that is an example of “removing the target.”
Yesterday, we hired Speed Racer as our new ace material handler. His “get aquainted tour” included an unannounced visit to see Joe…..on his forklift. Opps. We don’t have a place to move Joe, but we decided to put up a Jersey Barrier in the warehouse around Joe’s cube. That would be an example of “guarding the target.”
From there, we move into “good human factors design,” which is always a good idea. But then, we get into rules, procedures, signs, supervision, and training, which I don’t need to explain, but are the weakest of the methods to prevent problems. The other day I made that statement in a course and a training manager was aghast, and I felt really bad for him, but it’s true.
Where do your corrective actions fit into this hierarchy? Take out a stack of old reports and you just might be surprised.
One of our clients actually developed a policy around this issue, and if an incident reaches a certain severity/frequency, the corrective action must be a 1-3 or it requires VP approval. That is a great best practice.
If you happen to be attending the VPPPA (Voluntary Protection Program Participant’s Association) Conference this month, I will be doing a talk about Safeguards on Wednesday the 26th @ 10:30. Stop by our Booth (#503) and see us!
And while we are on the topic of corrective actions, one of our contract instructors, Ken Turnbull, has some rules of thumb for spotting weak corrective actions:
Can’t Close (assure, insure, ensure), example; Ensure employees follow procedure.
Pass the Buck (review, recommend, study), example; Recommend safety department review xyz policy.
Hidden Discipline (remind, review with, counsel, make present), example; Remind employees to work safely. Have Joe present the incident in staff meeting.
This blog is a call to action; corrective actions are the OUTPUT of your investigation. If you have weak corrective actions, the rest of your work is meaningless.
Thanks for visiting the blog and have a good rest of the summer.
What better way to learn and become proficient at using the new version 5 TapRooT® software than to attend a 1-Day Software Course? We have developed this course as an optional supplement to the normal TapRooT® courses, giving the students a chance to learn the ins and outs of the software tool. The course can concentrate on either the Single-User software, or (for our licensed clients) we can use your Enterprise installation to show you how to customize the global reporting and networking functions of the software to make your investigation process much more user-friendly.
Planning on holding a 2-Day TapRooT® Course? You can easily add the additional software day that is dedicated to working through examples, using the software to hone your newly-acquired root cause analysis skills.
Want to sharpen the skills of your already-trained TapRooT® investigators? We can teach the course as a stand-alone software introduction, with examples of how the new software can help make your investigations run more smoothly and efficiently.
Contact us at info@TapRooT.com for more information on our version 5 TapRooT® Software courses!
FACTS is an online diagnostic expert system to help investigators and companies readily determine if human fatigue may have been a causal factor in an accident/incident.
ABOUT CIRCADIAN®
CIRCADIAN® provides Fatigue Risk Management Systems, Shift Schedules, Software, and Training & Publications to solve the challenges of the 24/7 workforce.
FACTS is a web-based investigatory tool that helps users determine if human fatigue may have been a causal factor in an accident/incident. Developed by the world’s leading experts in sleep, fatigue, and circadian rhythms, FACTS generates results that correlate well (r = .91) with conclusions reached by experts who investigated NTSB and other industrial accidents.
Fatigue is one of the most pervasive yet under-reported causes of human error-related accidents, incidents, and injuries in both the industrial and transportation sectors.
Because fatigue is difficult to detect (i.e., no blood, urine or breathalyzer test exists to identify it) companies have a difficult time quantifying the true impact and cost of fatigue in their operations.
To bridge this gap, CIRCADIAN® created an online diagnostic expert system to help investigators and companies readily determine (by standardizing criteria and with high probability) if human fatigue may have been a causal factor in an accident/incident.
- – - END OF ANNOUNCEMENT
One additional note …
One of the developers of FACT will be at the TapRooT® Summit to share information about the technique and how to use it.
This presentation is in the Changing Behavior and Stopping Human Error track from 10:40-12 on Thursday, October 28.
One of the biggest trends in quality improvement was the term “The Cost of Poor Quality” tied with “Zero Defects”, with many COPQ financial models popping up in many Fortune 500 companies. In the safety world there was a similar drive with the term Cost of Compensation tied with “Zero Injuries” and OSHA driven recordables to be tracked.
The Quality Iceberg
The Safety Iceberg
Yet the focus for both safety and quality were lead by lagging visible indicators. In other words good or bad, the findings are just too late. You march your troops with the “Zero Defects” and “Zero Injuries” flags raised and once you reach your destination you turn around and see who and what equipment you have left.
Now don’t get me wrong, identifying and being able to comprehend the end damage is a vital part of the process and unfortunately not realized by some. It is just NOT where you should focus your drive and effort.
So what now you may ask? “Build quality in… do not inspect quality in!”
The phrase above often goes to deaf ears because it is misunderstand. “If you do not assess the quality of your work, then how do you know if it is to standards,” people would ask. “I have to trust everybody’s work?” In the safety world the phrase “Safety must be part of every action we do,” is often trumpeted. But how?!
Start with these 3 steps first:
1. First things first, Quality and Safety are NOT silo’s and they should work together. Setting up a task that can be worked efficiently, correctly and safely by employees is a combined goal and SHOULD NOT be competing goals.
To save money, many companies do not cross-train employee’s from different departments. Why not if it makes sense? For example, while many of our clients started using TapRooT® Root Cause Analysis in their safety departments first, the more people saw the process used, the more operations and facilities come onboard for the same training.
Now this cross-training concept also works in the opposite direction. As the quality department leaders started working with the safety, quality tools from Stakeholder Analysis to Force Field Analysis were also shared with the safety department. After all, inside all world class companies are different departments that are all part of the same company with one goal.
2. Building Quality and Safety into a process starts in the beginning stages of planning but can be recovered after the employees try to use an existing process (it just costs more time and money!).
When our clients use our Root Cause Analysis process to investigate defects and incidents it soon becomes apparent that the opposite of each one of our root causes are best practices that can be implemented proactively.
While most Quality Experts are excellent at mapping out front end value streams, process maps and spaghetti maps, there is often a gap in knowledge of research and industry best practices in human engineering, communication, procedures, training and work direction. So if you were a Quality Professional and had access to multiple experts in front of you everyday, would you utilize them? Here is small list of courses that can give you best practice access: Best Practice Courses
3. No process, no matter how well designed is perpetually stable and it must be audited/assessed periodically based on risk for unknown and known changes…. note: this is not the same thing as “inspecting in quality”!
This is one of the most misunderstood ingredients relating to Inspections.
If you have a hold point inspection that must be completed by an Independent Inspector BEFORE a task can be completed or a part received or shipped, you are admitting that you have a high risk potential that is not capable of being completely mistake proofed.
– OR-
You have a process or task where you have not truly identified the human and equipment behaviors with their associated Root Causes, and have decided that it is worth spending the extra money and time to inspect instead of fixing the problem. You refuse to build in quality.
Now this is not saying that you should not target high risk tasks proactively and continually audit or assess these areas to ensure nothing has changed or is different. This type of inspection must still occur.
Happy Wednesday and welcome to this week’s root cause analysis tips column.
During a recent 5-Day course, we were working on a major exercise that we call “The Water Hammer” and I was quite pleased with how well the students did. Part of the exercise involves students identifying causal factors from a SnapCharT® that we have given them. This particular class nailed the causal factors in a short period of time in what is a fairly involved incident with many causal factors. Later that day, when they were working on their final exercise with their own incident, one group was having a little trouble finding their causal factors, but when I went to the chart I could see them right away. Why could they not find them when they had done so well on the previous exercise? Because of the way they had worded things on the chart.
Let me make this simple point:
Good SnapCharT®=
All Causal Factors=
All Root Causes=
Good Corrective Actions=
RESULTS!
The bottom line is that the SnapCharT® is the foundation for everything else you do. You should keep in mind when compiling your chart that the more detail you can add the better, and wording does matter. Remember, causal factors look like:
Who did what wrong or what was done wrong?
What equipment failed or did not work as intended?
When you are building your chart, you should keep this in mind and word things accordingly; this will make your job much easier. Here are some examples of how causal factors might be worded:
Mechanic B did not close Valve A as required (who did what wrong)
Check-valve pin breaks (what equipment failed)
An important part of building your SnapCharT® is adding undesired actions or conditions.
If you want to get laser focused on causal factors and other best practices, why not attend the Advanced TapRooT® Techniques course prior to this year’s TapRooT® Summit? This course will help you get to the next level, and this discussion is just a sample of what we talk about in the course.
When we first released the new TapRooT® Book, I published a copy of the Table of Contents. After my article last week, some people have been asking, “What’s in the new TapRooT® Book?” To find out, go to this link:
Dave Janney and I recently had a great opportunity personally talking one to one to over 450 plus ASQ (American Society for Quality) Members in St. Louis at the ASQ World Conference. There were 1,000 plus members present but I want to focus on the one on one discussions in this tip of the week.
Discussion Tip 1: “The TapRooT® Root Cause Tree is definitely more than a Fish-Bone and 5-Why tool!”
A Director of Quality walked up to our booth and looked at the back of our Root Cause Tree. Seeing some of the Basic Cause Categories such as: Human Engineering, Management System, Training, Work Direction……. He stated, “that looks a little like the Categories on the Ishikawa Diagram, what is the difference? Why would I as an expert need to use it?”
So I put him through the test and covered up the multiple research and industry based Root Causes under our Basic Cause Category of Human Engineering. Then calling this the “Man/Person” section of the Diagram I asked, ” with your expert knowledge with man/person in quality, what human engineering questions would you ask?”
He stopped and realized that this was not his area of expertise. We have 7 areas of expertise to help you analyze your problems… In simpler form, you as the quality director have 7 more experts sitting next to you that are usually not present when developing your Ishikawa diagram.
Also remember, it is not how many questions you ask! What you ask and how you ask it is what will give you an effective Root Cause Analysis.
Discussion Tip 2: “I already have a list of common Root Causes developed by ABC Inc., why get a new process?”
This question came from a Tier 1 Supply Quality Leader. So my first question was, “which category do you see selected most often during a Root Cause Analysis?” His response, “depends on which department lead the investigation.”
Caution of the day, if the investigator is steering the analysis then you have a Root Cause Tool that allows bias instead of facts to run the investigation. The analogy is like telling your inspectors to measure the dimensions of a cube. Each person selects their favorite measuring device and goes at it. Just do not expect them to come up with identical end measurements.
Our TapRooT® process takes you through a standard/robust question process that needs facts to say yes to or no to and not opinions. It is this true and tried process (20 years in use) that allows the Quality Inspectors to remain consistent.
Now don’t get me wrong, TapRooT® Root Cause does not replace the quantitative tools used by certified quality leaders. It does however improve the qualitative portions of your analysis.
Look for more Quality Tips and Articles to come…. there is just so much more to continuous improvement. Question? Comments?
Happy Wednesday and welcome to this week’s root cause analysis tips column.
I would like to talk this week about management systems.The first, and most important question, is DO YOU HAVE ONE?If not, you should!
When we talk about management systems, what we mean is a structured way to manage the business and assess (and improve) performance.There are many kinds of management systems: quality management systems; environmental management systems; safety management systems; etc.While the components of these systems may be different, the approach is the same.And root cause analysis is an important part of making sure these systems run the way they are intended.
Maybe your organization is ISO certified.Maybe your safety department got you into VPP (OSHA’s Voluntary Protection Program).Maybe your environmental group got you into the EPA’s Performance Track.You have a structured way to manage your business.As part of your auditing and corrective action processes, you can use TapRooT® to perform root cause analysis.But the even better part is that you have the TapRooT® root causes and information in the Root Cause Tree® Dictionary to use as best practices that should be part of your management systems.Use this expert guidance to make sure you have all the pieces in place, then audit them for effectiveness.The stronger your management system is, the less problems you will have.
Beyond the usual monitoring activities like auditing, you should also have continuous improvement processes.Maybe you use Six Sigma, Lean, or……Lean Six Sigma!Maybe TQM.These are all good approaches to continuous improvement, but the root cause analysis techniques typically used in these processes are weak at best.But the good news is that you do not have to “throw the baby out with the bath water,” you can use TapRooT® to perform RCA more effectively within the framework of these existing programs, and you have our corrective action tools to help as well.
By the way, before I go, I mentioned VPP.If you are in safety and are not familiar with VPP, it is a great management system.VPP is a cooperative program between OSHA and business and works very well.You might want to check it out on OSHA’s website.If you are already involved in VPP, please come and see us at the TapRooT® booth (#503) at the 2010 conference in Orlando in August.I will be giving two talks at the conference; one technical session on Safeguards (one of our optional techniques) and one non-technical session on “Making the Business Case for Safety.”I hope you will stop by.If you would like a copy of my VPP & TapRooT® tips, please e-mail me, dave@taproot.com
We have had plenty of time for comments and I posted my idea yesterday … So here is a link to the blog post and comments so that you can catch up with the debate:
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
Chris,
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).
Regards,
Mike
_____________________________________________________________________
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.
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.
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.
But I don’t think we learned all that we could from that blog article. So, I’m going to resume the discussion and learning here.
Instead of continuing with the blame focussed arguments of the previous post, I’d like readers to consider this …
If you have to develop corrective actions that would keep this accident from EVER happening again, what Safeguards would you use?
Let’s do a simple Safeguards Analysis to get this process started.
The Hazard?
A moving vehicle .
The Target?
The pedestrian.
The current Safeguards:
The driver seeing the pedestrian and taking actions to avoid them (no matter when the pedestrian steps out).
The pedestrian looking both ways before crossing a road to avoid any traffic.
The first safeguard is impacted by driver training, laws, driver attention, driver distraction, visibility, and many other factors.
The second safeguard is impacted by pedestrian alertness, laws, visibility, the “walk”/”Don’t Walk” lights (or lack thereof) and many other factors.
If we want to stop this accident from ever happening again, do we just concentrate on making the two existing safeguards better? Or do we look at other safeguards or removing the Hazard or the Target?
In this example, the Gwinnett police decided to make an example of Lori Reineke by prosecuting her for vehicular homicide. What do you think? Will this stop these kinds of accidents from happening again by getting drivers to be more alert? Can drivers be totally alert all the time to avoid a pedestrians that walk in front of them?
Another angle could be to focus on pedestrians. To try to make them more alert. (Do you remember your mother’s warnings to look both ways before you cross the street?) Perhaps we could install additional auditory warnings if a sensor detected a moving pedestrian when the “don’t walk” sign is lit?
It would be pretty difficult to remove the Hazard. We probably can’t remove all vehicles from the road.
Also, it is difficult to remove the target. We probably can’t eliminate pedestrians.
What about maintain separation? Can we have pedestrian overpasses (underpasses) to keep pedestrians and traffic separated?
Or should we try to reduce the impact? How slow should the speed limit be? What about airbags in the bumper that deploy when a pedestrian impact is just about to occur?
Now you are starting to think about Safeguards … and not just placing blame.
What do you think? What kind of additional safeguards can we find? Leave your ideas here.
Also, do you think we can meet our goal of “never” having this kind of accident happen again?
Happy Wednesday and welcome to this week’s root cause analysis tips column.
This week I would like to talk about a root cause that we see quite often; Enforcement NI (NI=needs improvement).
In the Root Cause Tree® Dictionary, the first thing it says is “this root cause has to do with management’s actions to exercise control, influence behavior, and ensure the person who is responsible actually follows the SPAC (standard, policy, or administrative control) by holding people accountable.”
You end up here on the tree if an incident occurred because someone did not follow a SPAC AND there is evidence that this is not an isolated incident.If it is an isolated incident, it is not a case of Enforcement NI, so be careful.We get into some interesting debates about this in our courses; sometimes a student feels that there is an enforcement problem if adherence to a SPAC is not 100%.But if 99% of the people follow the policy (based on your audits) and one person did not, can you really say you have an enforcement problem?Nope.
Which brings me to my next point; Enforcement NI means there is not appropriate oversight and follow-up.If you don’t measure compliance, you will have a very hard time ensuring it.
The worst issue, however, (in my opinion) is when management is reinforcing the wrong behaviors. When front-line supervision looks the other way UNTIL something bad happens, that is reinforcing the wrong behavior. Let’s try a quick check of your organization, just for fun; if you had an incident where someone did not follow a policy and the supervisor says “he is one of my best guys” then you may just have this issue.He is “one of the best guys” because he gets the work done!But is he doing it right?
When enforcing policy, you have to be consistent.Only once you have obtained that state can you move into the last resort; discipline.You have to make sure the policies are relevant, they work in the real world, and that you have the proper resources in place to make them happen.Then you have to have a way to monitor performance and again, be very consistent in enforcing them.You also have to have a way to “catch” and reward the right behaviors….which brings me to my next point:
In our courses, we talk about the soon, certain, positive concept.Soon means right away, certain means for sure, and positive means I will hear about it when I am right as well as when I am wrong.This is all about consistency, and is the only way to get committed behaviors.Otherwise, you will get reluctant compliance and they might only do the right thing when you are watching.Look at what is being punished and rewarded in your organization, and you might be in for a surprise.You don’t have to wait for an incident to occur to realize Enforcement NI.
My last point is don’t get confused between Enforcement NI and Accountability NI root causes.Accountability NI in the Root Cause Tree® Dictionary means that there is a way to tell who is responsible for a SPAC.If it is clear who was supposed to do it, then it is not a case of Accountability NI.Be careful.By the way, the NOTES in the dictionary can be very helpful.There is a note that clearly talks about the distinction between these root causes, yet I still see people selecting both Enforcement NI and Accountability NI when someone did not follow a SPAC, even though it was clear who was responsible.When I see this, I realize that the person did not read the dictionary!
Enforcement is a tough nut to crack.It takes thought, effort, and consistency.It requires a “soon, certain, positive” approach.
Thanks for visiting the blog and we will see you next time.Happy investigating.
I’ve seen several investigations involving weather or natural disasters which just leave it at that. “Not much I can do about Mother Nature.” Take a look at this video:
Tornado Derails A Train
How do you deal with an incident that seems to be completely out of your control?
First of all, don’t do anything different. FOLLOW THE PROCESS! Start with a SnapCharT®, and see what questions need to be asked. You may find you have questions about:
- Training of the engineer on what to do in hazardous weather - Ability of the engineer to see hazards - Radio communications with operating base - Type of cargo - Load distribution
If you’re not sure what else you need to ask, you can use several tools:
1. Look ahead at the Root Cause Tree®. See if any of the 15 questions apply. 2. Try a Safeguards Analysis. Check to see if any of the 5 Safeguards questions we teach during TapRooT® courses apply in this case. 3. Don’t forget that the Dictionary® is checked full of great questions.
You may then come up with a few other things to check:
- Alertness of the engineer - Engineer’s physical condition - Availability of weather-related information - Condition of the train cars, tracks, and signals - Possibility of engineers being alerted by central base (signals, radio comms, computer alerts, etc) - Training of the engineer on what to do when a derailment occurs
I’m not saying you’ll find problems in all of these areas. I am saying that you should use the TapRooT® System to help you figure out what to check. You should realize that, “Well, a tornado hit, and there is nothing that we can do about that” is not a get out of jail free card, allowing you to ignore the issue. There may still be some problems that management did have control over that could have prevented the accident, made it less likely, or made it less severe. Use TapRooT® to verify you have done everything reasonably expected to prevent the incident.
The title of this Article could not be any further from the truth, but I hear it all the time in online root cause forums.
…… Yes, it is too late to prevent an incident that has already occurred.
….. Yes, after an incident we want to find the root causes that allowed a human or equipment behavior to occur or get worse.
….. Yes, we build corrective actions based on the incident analysis to prevent another incident from repeating….. What?
So you mean applying best practices (the opposite of the root causes found) will prevent future incidents and forces you to look forward to make sure they worked?
So where else can I apply root causes (absence of best practices)?
….. Designing processes and products. (Why create future root causes for someone else to figure out by accident?)
….. Setting up and assessing your training and hiring program. (So is it a Worker Selection, Supervision, and/or maybe a Training Root Cause?)
….. Revamping your audit or assessment program. (Where are the human factors questions in your audit?)
This important concept is actually why we teach proactive root cause analysis to our clients.., to learn more; e-mail: info@taproot.com and tell them Chris has a root cause to pick with you.
It got me wondering … “Can the choice of a root cause analysis tool increase or decrease the amount of blame in an investigation?”
I’ve thought about this a lot in the past – so I have some definite ideas. But I thought I’d post the question here to see what others have to say. Then I’ll chime in later.
What happens when it appears something completely unavoidable happens? As an example, I was recently asked about a truck that struck a deer. It was daytime, the operator was not speeding, he had seen other deer on the other side of the road and slowed down, he was not tired or in a hurry. The collision resulted in very minor damage to the truck. The investigator was not able to find any root causes. What do you do with this?
These types of investigations can sometimes feel frustrating. There must be something that we can find here!
Sometimes, there was just nothing done wrong. All current policies were followed, the policies look good, and sometimes “stuff happens.” When it appears that this might be the case, try the following:
1. First, verify that all the information is correct. I’m not questioning the integrity of the driver, but just make sure all the information makes sense and there aren’t any inconsistencies.
2. Perform a Safeguards Analysis. In this incident, what were the Hazards? Targets? Safeguards? In this example, the hazard was the energy of the moving vehicle. The Targets are probably multiple: the truck, the deer, and the driver. Now ask yourself, “What Safeguards were in place between the Hazard and the Targets?” You’ll find things like speed limit, seat belts, driver awareness, etc. Now, ask yourself the 5 Safeguards questions that are at the bottom of page 376 in the TapRooT® Book. See if there were any mistakes made in the application of the Safeguards you found.
3. If you are really adventuresome, you can try applying other optional TapRooT® tools. A CHAP Analysis will give you a very detailed understanding of exactly what was going on at the time of the incident. Maybe a Change Analysis will help you understand why we hit a deer this time, but not at other times.
When all this is done, you may find that there were no mistakes made. This puts you at the top of the Root Cause Tree®, under Natural Disaster / Sabotage. Your analysis has found that there are not any root causes. This is OK, as long as you are confident that your data is accurate and complete. Sometimes, “stuff” really does “just happen.” Note that this isn’t the norm, but it does occur.
The next thing to think about are Corrective Actions. Again, you can apply Safeguards Analysis to see if there are any new Safeguards that you might want to put in place. Take a look at page 379 in the TapRooT® Book to see which new Safeguards (Corrective Actions) would be most effective. For example, maybe something like those critter whistles that you put on your bumper may help by attempting to Remove the Target. Additionally, this particular incident report stated that they see deer along this road almost every day. Maybe we can Remove the Target by finding a different route that is less likely to encounter deer. Probably not possible here, but something to consider.
These are just some ideas. When you get to this type of problem, ensure your investigation is accurate and complete, using the optional TapRooT® tools. If everything looks good, then there may be no actual root causes, but there still may be opportunities for improvement.
In our courses we teach the final “R” in SMARTER to review for unintended consequences BEFORE you implement your Corrective Action. Whether you do a pilot study or review the action with the employees who will have to use it, do not let unintended consequences be your next Incident’s Causal Factor.
Happy Wednesday and welcome to this week’s root cause analysis tips.
This week I would like to talk about making sure everyone in your organization is on the same page.Who does investigations and audits?Who leads investigations and audits?And who reviews investigations and audits and approves funding for corrective actions?And, who is involved with implementing corrective actions?Do all of these people understand the process?In other words, is everyone on the same page?
One of the questions I am frequently asked is “who needs what kind of training?”I wanted to answer that question by discussing some of the different courses we offer; I think that will help.
For those involved with investigations or leadership who needs to understand the process, our 2-Day Incident Investigation and Root Cause Analysis course will provide the foundation to be able to participate and to do a thorough root cause analysis.We cover the TapRooT® seven-step process and all the major TapRooT® techniques in this course.This course is offered publicly on our website and is also available onsite if you have 10 or more people to be trained.
For those leading investigations, our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader training is the best course.This course is designed to fully prepare you to find problems in your organization and solve them.In this course we cover all of the major techniques and all of the optional techniques.We also cover the basic cause categories and spend one morning on proactive use of TapRooT®.We have several great exercises focusing on interviewing, defining causal factors, and root cause analysis, and we spend a lot more time in the software than we do in the 2-day.This course is also available on our website or onsite.
If you need management training to get everyone on the same page so they understand the reports they review and buy-in to your corrective actions but cannot afford the time to send leadership to a 2 day course, you might consider a special one day management session, which will allow everyone to get an understanding of the process without spending 2 days.This course can be done for you onsite, so please let us know if you would like to schedule a course.
Let’s not forget about the maintenance folks.We have a special 1-day Equifactor® equipment troubleshooting course that we schedule in conjunction with our 2-day courses.If you have not been to a course before, come for the entire 3 days, and if you have been to one of the 2- or 5-day courses, just come to the third day.View our schedule to see availability of Equifactor® courses.This course will allow your troubleshooters to have a defined process to follow; after all, do you want your troubleshooters “shooting from the hip?”I did not think so.
I would be remiss if I did not mention that we will be having several special 2-day courses on a variety of topics on the 2 days prior to this year’s TapRooT® Summit in San Antonio. We also offer all of these courses onsite.
So make a plan to get everyone on the same page.Get employees and management trained this year and join us for the Summit.It’s time to take action!
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 …
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 …
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 you are asking what is the worst 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 can we use a simple calculation ourselves first?
NIOSH 1991 Lifting Calculator. Centers for Disease Control and Prevention (CDC), National Institute of Occupational Safety and Health (NIOSH), 208 KB ZIP*.
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.”
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:
What would your answers be for the Homework Questions below?
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.
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?
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?
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 …
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 …
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.
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!
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.
(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.
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 …
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.
“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.
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
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.
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 …
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.
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 …
“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?
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 …
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.
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!
