Category: Root Cause Analysis Tips
A Look at 3 Popular Quick Idea Based Root Cause Analysis Techniques: 5-Whys, Fishbone Diagrams and BrainstormingAugust 26th, 2015 by Chris Vallee
Today’s root cause tip will walk through a few popular quick-idea based root cause analysis techniques used by many.
Do a quick search using Google or Yahoo search engines for “Root Cause Analysis Training” and these techniques often pop up in your internet browser: 5-Whys, Fishbone (Ishikawa) Diagrams, Brainstorming and of course, TapRooT® Root Cause Analysis. Now type in “free” or “quick root cause analysis templates” and you will not find TapRooT®. Is that good or bad? Of course my dad always taught me that what is earned and worked for was always more satisfying and led to a stronger sense of accomplishment. The end product also lasted longer.
Why would a person search for root cause analysis training on the Internet? If I were to brainstorm the whys as defined in dictionary.reference.com:
- a sudden impulse, idea, etc.
- a fit of mental confusion or excitement.
-1890-95; brain + storm; originally a severe mental disturbance
Then I might suggest the following “whys”:
- The person was bored.
- A student was doing research.
- A training department was assigned to find and schedule quick low cost training techniques that can be taught online.
- You were assigned to find good root cause training to solve problems.
Now those weren’t too many suggestions on my part. But there is hope, because brainstorming is best served in groups. As defined in wikeipedia.org:
Brainstorming is a group creativity technique by which efforts are made to find a conclusion for a specific problem by gathering a list of ideas spontaneously contributed by its members.
But we have to establish a few rules per wikipedia.org:
- Focus on quantity…. The more the merrier.
- Withhold criticism…. No why is a bad why and you might shut down the quantity given by others that were made fun of.
- Welcome unusual ideas
- Combine and improve ideas… we can build off other peoples’ whys for a really good why to solve a problem.
Okay with our new rules and group in place, we came up with more whys to why someone was searching for root cause analysis on the internet:
- The person was bored.
- A student was doing research.
- A training department was assigned to find schedule quick low cost training techniques that can be taught online.
- You were assigned to find good root cause training to solve problems.
- The current root cause techniques are not working very well.
- You are planning a party and this would be a great team game. (This one was my favorite suggestion)
Fishbone (Ishikawa) Diagrams
Brainstorming not quite good enough in our quest to solve why people are searching for root cause analysis on the internet you think? Let’s do a guided search for whys with our group using a Fishbone (Ishikawa) Diagram.
- Agree on a problem statement as a group. Ours is “why are people searching for root cause analysis on the internet?”
- The problem statement is placed at the head of the fish as seen in the diagram above.
- Now Brainstorm the major categories of the cause of the problem and list them underneath each category. For our fishbone from wikipedia.org, we are going use Methods, Machines, Material and Measurements.
a. Methods: How the process is performed and the specific requirements for doing it, such as policies, procedures, rules, regulations and laws
b. Machines: Any equipment, computers, tools, etc. required to accomplish the job
c. Materials: Raw materials, parts, pens, paper, etc. used to produce the final product
d. Measurements: Data generated from the process that are used to evaluate its quality
Caution, there are many categories to chose from which may lead the group into different directions each time they use one. We could have also used the categories as listed in wikipedia.org:
The 7 P’s
The 5 S’s
Here is our refined fishbone. I have to admit, it does look a little better than the brainstorming list above. Did not take that much time at all.
- As each idea is given, the facilitator writes it as a branch from the appropriate category.
- Again ask “why does this happen?” about each cause.
- Write sub-causes branching off the causes. Continue to ask “Why?” and generate deeper levels of causes. Layers of branches indicate causal relationships.
Item number 4 gets into looking for causal relationships within our suggested causes which leads into our 5 whys discussion next.
Let’s take one of the “causes” listed above and get to a good root cause with our group to understand why people are searching for root cause analysis on the internet?
Here are the simple instructions for performing a 5 Whys as listed in wikipedia.org:
5 Whys is an iterative question-asking technique used to explore the cause-and-effect relationships underlying a particular problem. The primary goal of the technique is to determine the root cause of a defect or problem by repeating the question “Why?” Each question forms the basis of the next question.
- Why are people searching for root cause analysis on the internet?
Answer: Because there is no database to search in on their computer and the boss wants training answers now.
- Why is there no database on the computer to search from?
Answer: Because these are computers produced in 1995 and a knowledge database cannot be installed.
- Why do we not have new computers that can have databases installed?
Answer the company is short money.
- Why is there no money left to purchase computers?
Answer: Because we have lost money on repeat incidents.
- Why do we have repeat incidents?
Answer: Because we do not have a good, effective, cost reducing Root Cause Analysis Process. I have a great solution for this problem….. look here for future courses in TapRooT® Root Cause Analysis.
Okay, I agree this was a very high level and superficial exploration of the 3 Popular Quick Idea Based Root Cause Analysis Techniques: 5-Whys, Fishbone Diagrams and Brainstorming.
However, the steps that we explored are valid steps and flow of the actual processes. The ending results from superficial creation of whys are very true and have been the cause for repeat problem occurrences.
If you are going to use these process, as they are often still required for everyday issue resolution for some and for others are actually considered their only root cause tools, then head off some of the issues with a couple of these best practice suggestions.
- Never start with Brainstorming. This is a great tool for suggesting corrective actions tied to actual root causes, but should not be used for evidence collection and figuring out why something happened.
What to do instead? Go Out And Look (GOAL). Never armchair troubleshoot from a conference table surrounded by people.
- Only use a Fishbone (Ishikawa) Diagram if:
a. You have collected evidence
b. You standardized and defined your fishbone cause categories
c. You have the right experts in the room
d. Cause or Corrective action ideas do not drive the actual what and why questions.
- Only use 5 Whys for trying to identify the actions or inactions that allowed an issue to occur and not the actual root causes. Why?
a. There is a tendency to look for only one cause when using the process; even if you ask 5 Whys for each action or inaction found on the Fishbone (Ishikawa) Diagram, there is still a tendency to look for only one cause in each section. I have never just had one cause for any problem that I have investigated.
b. It is not how many questions one asks but what one asks.
c. When used to collect evidence or understand evidence, there is a tendency for “group think” to occur that drives which direction the evidence and causation linkage goes. Look up the Space Shuttle issue tied to the o-ring failure for a group think example that was detrimental to life.
d. There is nothing to push the investigations outside what they know as a whole and what may be missing from the investigation. In that case, always bring in different knowledgeable and people new to the problem for constant checks and rechecks. Also look for outside industry best practices and knowledge to help get better investigations completed.
So in closing…..
- If it looks too easy and requires less work, you get what you put in it.
- If there is a large amount of guessing, you are also guessing at the corrective action.
- If the right expert is not in the room when using the tools explored, nobody will know what to ask or to verify.
- If the people using the process are the only thing driving the evidence collection, bias has a stronger natural tendency to take over.
I look forward to your examples of using these processes and also comments on some of the traps you did or did not avoid while using these 3 tools.
What is the easiest way to tell a good root cause analysis program from a bad one?
The involvement of senior management.
How do you know if a root cause analysis program is about to fail?
Senior management changes and the new management shows no interest in the root cause analysis program.
What level of senior management is involved in the best root cause analysis programs?
All the way to the corporate board.
The answers to the three questions above show that senior management involvement is extremely important to the success of any root cause analysis program. The better the root cause analysis program, the more senior management involvement counts. That’s why I thought I’d take this time to explain how senior management should be involved in a root cause analysis program.
I’ve seen a few leading companies where the Corporate Board was knowledgeable of the safety/process safety/quality improvement programs. The best had a senior manager who was responsible for reporting key reactive and proactive statistics to a special board committee with primary responsibility for safety and other improvement efforts. The committee, that included the CEO, also was provided with overviews of the most serious incident investigations and summaries of improvement efforts.
This board’s interest ensured that people paid attention to the programs and that budgets weren’t slashed for key improvement initiatives (because they were supported by the board).
Of course, VPs or Division Managers were interested in their division’s reactive and proactive improvement performance. What VP or Division Manager wouldn’t be if the Corporate Board was going to see their statistics. They wanted to be able to manage performance so they became involved in improvement efforts. The held divisional meetings to review progress and presentation of root cause analyses of their biggest problems. They held Plant Managers and Unit Leaders responsible for their performance making improvement programs succeed.
Involved Plant Managers demand good root cause analysis and schedule reviews of detailed root cause analyses of significant problem investigations. They make sure that their key improvement programs are staffed with well trained, insightful leaders and that they have plentiful staff and budget to perform investigations, review reactive and proactive statistics, sponsor training throughout the plant, and look outside the company for improvement ideas. They are the site sponsors of the improvement programs. They are trained in the root cause analysis tools being applied at the plant. Because they are trained, they offer insightful critiques of the investigation presentations. They reward employees for their participation in root cause analyses and the improvement programs.
WHAT DOES YOUR COMPANY DO?
Is your senior management involved in performance improvement?
Do you have best practices for management involvement that I’ve missed and should be included here?
What do you need to do to improve your management involvement?
If you have support, are you ready for management turnover?
Rome wasn’t built in a day. Don’t worry if your program doesn’t have all the management support that it needs. But don’t ignore your program’s shortcomings. Work on getting more management support all the way up to the corporate board.
When safety/improvement performance is seen as equally important, you know you have achieved a level of support that most improvement managers can only dream about.
When it comes to effective root cause analysis and problem solving, are you jumping to the “ultimate why” or the “ultimate fix” without truly knowing the “ultimate what” behind the problem?
It is not how many questions you ask or even how many solutions that you throw at a problem; instead, it is how you define the scope of your problem that needs to be solved, what you learn when you find out what happened during the problem’s occurrence, what you ask based on what you learn and how you fix what you find out.
The sequence of what happened, why “the what” happened and then fixing what you find for good problem solving sounds simple, right? Then why do so many people not follow this critical sequence of problem solving? A personal experience comes to mind from a recent investigation failure that I observed. Note that you should always start with defining what the problem is that needs to be analyzed before you start a root cause analysis.
The problem scope of the investigation failure mentioned above was to understand why there was a repeat of an incident after a team had completed their incident investigation and implemented their created corrective actions.
What are the probable costs of not analyzing an incident?
1. Hazards to people, equipment, processes or a customer not identified and therefore will not be removed, isolated or mitigated.
2. The next associated incident has a worst outcome:
a. A loss of life, injury or other harm to people
b. Damage to the environment
c. Equipment run to unplanned failure
d. Loss of a process or production system
e. A loss of client from repeat defects and failures
f. Government or other independent Agency involvement
3. A backlog of incidents and rework of incidents that includes a backlog of corrective actions.
Below are some of the facts that I collected for the repeat incident failure that I observed:
1. The investigation team had a natural tendency to take shortcuts by using experienced-based guessing to reduce investigation time.
If you already “know” the whys of a problem or you know the solution that you want to implement, then you do not need to verify what happened.
This team’s shortcuts then became “longcuts” due to guessing and expert driven tunnel vision that led them into erroneously based evidence collection and why selections. This error ended in wasted time and poor corrective actions that did not lesson or mitigate the problems that caused the original incident.
2. Poor problem solving skills for many of the team were taught previously in “well meaning” problem solving training… 5-Why’s, Ishikawa Diagrams and Brainstorming Solutions.
Items one and two above support each other and are easily adapted by expertise driven problem solvers. Just call these factors above co-enablers. These methods tend to feel good because they support your own experiences and they are quick and easy tools to learn and use. These tools assume that all right experts are sitting in the room, all the right people went out to look at the problem and no guesses or assumptions were made. Not the case on most situations during problem solving.
A good root cause analysis process does not replace the need for a company’s process experts, workers or managers. It instead should pull good information from these people in an unbiased and effective manner. It should also ensure good corrective actions are developed, implemented, verified and validated.
The problems identified above encouraged the company’s problem solvers to deviate from an effective problem solving sequence of what, why and then fix during root cause analysis, which caused this team’s incident to repeat.
So what happens when investigators follow the “Ask Why First” method instead of trying to learn what happened first?
1. The investigators tend to pull from their own experiences first and quickly try to fit their experiences to the problem being analyzed. This is the first stage of failure called guessing. Never assume what happened is the same as to what really occurred during a problem. Also, if you never experienced the problem before, you will have no experience to fit the problem to.
2. Investigators often throw multiple “possible” root cause options at a previously “known” problem. The more causes the merrier, right?
Actually no. For every cause you throw at a problem not based on facts of the incident, you now have to take time to collect information, causing you to waste time. Often you choose which cause is the most important to you before you know the facts and then ignore collecting any other “unimportant” information.
3. Depending on the previous problem solving training received, investigators often drive the evidence collection with linear brainstorming why questions (5 Whys style).
You increase the probability of delaying, if not actually ignoring, viable evidence. This process also tends to let you drive to find just one “real root cause”. This problem is a critical error. After all, even a fire, like any other problem that you may investigate, has more than one ingredient and cause. This can also produce “tunnel vision” designed to find the “most important” or “rootiest root cause”.
Let’s look at the “Fix the Problem First” method. Many well-meaning problem solving methods state that solving the problem is more important than finding all the whys or what’s of the problem that needs to be resolved. Management doesn’t care how you fix the problem as long as you solve it, right? What could go wrong if we just try to brainstorm a solution first and by-pass the whole finding a cause thing?
1. The focus of the investigation tends to be for the investigators to quickly put things back to normal, to stabilize the environment for damage control. This is not problem solving in reality, it is actually called triage. Triage is where you quickly assess the issue, make a best solution guess and then put that guess into action. Reduction of time to solution is vital in triage.
There is a need for triage with immediate actions, however this should not be practiced during good problem solving because it becomes a “Broke-Fix” mentality as opposed to understanding the problem to improve preventing the problem from occurring again.
2. If you have a fix in mind, you have an agenda. This agenda looks for supporting evidence to validate the selected fix and also tends to filter out other important issues.
The level of your organization chart that is driving the solution during this process can also set the stage for what is acceptable for the investigators at that site to discuss and address at the employee level. This often restricts getting all the facts and restricts what is allowed to be changed.
So how does starting with “What happened first” during problem solving prevent the issues listed above?
1. Identifying what happened before the problem that needs to be resolved occurred and what happened after it occurred, with proper detail and supporting evidence, reduces the case for assumption led decisions.
2. Writing down what happened, increases the ability to identify more clearly the conflicting statements from interviews and gaps in a process being investigated.
3. Writing down what happened, allows you to identify what worked right. This helps validate good processes and demonstrates that you’re using a root cause analysis process that looks for the good, the bad and the missing best practices. This is good for morale and increases the probability for effective and sustaining corrective actions.
4. You now have good documentation to help you find out why the problem that needs to be resolved occurred and why the fix is justified. This documentation can reduce the amount of corrective actions rejected by managers and regulators.
5. You are now using a good root cause process to not only figure out why the problem occurred but what also why actions or inactions failed to mitigate the problem or made it worse.
6. At the end of the day your initial gut feeling of what happened, why it happened and how to fix it is either substantiated or rejected based on facts and not emotions.
The sequence of What, Why and then Fix… There is No Other Sequence for good Root Cause Analysis.
For extra credit after reading this TapRooT blog article, let me know what movie the ultimate answer “42” came from and what the question really was for the answer.
You can also join me to learn more about effective TapRooT® Root Cause Analysis by attending one of my classes. We can talk about the movie over coffee or a soda and make a SnapCharT® for why the world was going get destroyed for a new galactic highway.
People are often surprised when they learn the reasons they haven’t taken root cause analysis training are invalid. Here are the top three excuses people give that are wrong:
1. Most employers aren’t seeking that skill when hiring.
Root cause analysis is a top skill valued by employers because mistakes don’t “just happen” but can be traced to well-defined causal factors that can be corrected. A bonus to root cause analysis training is that root causes identified over time across multiple occurrences can be used for proactive improvement. For example, if a significant number of investigations point to confusing or incomplete SPAC (Standards, Policies, or Admin Controls), improvement of this management system can begin. Trending of root causes allows development of systematic improvements as well as evaluation of the impact of corrective actions. What boss doesn’t appreciate an employee who can prevent HUGE problems and losses from occurring? Promoting your root cause analysis skills is an impressive topic of conversation on any job interview.
2. It takes too long to learn enough to really use it on my job.
In just 2 days you can learn all of the essentials to conduct a root cause analysis and add this impressive skill to your resume. You will be equipped to find and fix the root causes of incidents, accidents, quality problems, near-misses, operational errors, hospital sentinel events and other types of problems. The essential TapRooT® Techniques include:
- SnapCharT® – a simple, visual technique for collecting and organizing information to understand what happened.
- Root Cause Tree® – a systematic, repeatable way to find the root causes of human performance and equipment problems — the Root Cause Tree® helps investigators see beyond their current knowledge.
- Corrective Action Helper® – help lead investigators “outside the box” to develop effective corrective actions.
There are all kinds of training programs you can enroll in for your career development that take months, even years, to complete. A 2-day investment for this valuable training program will equip you with a powerful skill that will set you apart from the rest.
3. I don’t have enough technical knowledge to take training like that.
It doesn’t matter if you have a high school diploma or an MBA. It doesn’t matter if you do not know much about root cause analysis beyond the description provided below. Our attendees, at every level of education and technical skill, find that they can engage in the training and take away root cause analysis skills to implement immediately. It is not a “sit and listen” training – attendees do hands on exercises to develop their new knowledge in the course.
Root cause analysis is a systematic process used in investigating and fixing the causes of major accidents, everyday incidents, minor near-misses, quality issues, human errors, maintenance problems, medical mistakes, productivity issues, manufacturing mistakes and environmental releases.
Root cause analysis training provides:
- the knowledge to identify what, how and why something happened, and this knowledge is vital to preventing it from happening again.
- the understanding that root causes are identifiable and can be managed with corrective actions.
- an ease of data collection, root cause identification, and corrective action recommendations and implementation.
Still not convinced root cause analysis training is for you?
GUARANTEE for the 2-Day TapRooT® Incident Investigation and Root Cause Analysis Course: Attend this course, go back to work, and use what you have learned to analyze accidents, incidents, near-misses, equipment failures, operating issues, or quality problems. If you don’t find root causes that you previously would have overlooked and if you and your management don’t agree that the corrective actions that you recommend are much more effective, just return your course materials/software and we will refund the entire course fee.
CLICK HERE to register for the 2-Day TapRooT® Incident Investigation and Root Cause Analysis Course.
Welcome to this week’s root cause tips column. So what is the most important information or criteria in a good root cause analysis? (By the way, this is a trick question)
I started a list:
• A timeline of what happened
• Complete evidence
• Identification of causal factors
• Safeguards analysis (what failed)
• Safeguards Analysis (what worked)
• Root Causes substantiated by evidence
• Generic (system) Causes identified
• Corrective Actions that eliminate the root causes
• Corrective Actions that are implemented
• Corrective Actions that have been verified effective
So what do you think? Have I missed anything? Please comment below if you have any other ideas.
And which are the most important?
Yes, it is a trick question. They are ALL important.
For example, what if you did a really good job of collecting evidence and got good root causes but wrote weak corrective actions? Have you ever seen training as a corrective action for root causes that had nothing to do with training? Of course you have, that’s my point.
What if you had great corrective actions but they were never implemented (or checked to see if they were effective)?
The fact of the matter is you have to have all these things for an effective investigation and root cause analysis. It is easy to miss things, we’re all human and we all have different experiences, knowledge, and biases. But the good news is that this is all built into how TapRooT® functions. Just follow the process and you will have a good root cause analysis.
You must know WHAT happened before you can determine why. This is why evidence collection is so important.
You must know WHY before you can write corrective actions. If you do not have good evidence you will miss causal factors and root causes. ALL root causes have to be substantiated with evidence.
You must FIX the root causes. Your corrective action has to specifically address the root causes, has to be implemented, and has to be verified.
Think of it as a chain link fence. If any part of the chain is broken, the fence is compromised, and in this case, so is your investigation.
If you are interested in learning the TapRooT® Root Cause Analysis, our 2-day course offers all the process essentials needed to conduct an investigation including:
- SnapCharT® – a simple, visual technique for collecting and organizing information to understand what happened.
- Root Cause Tree® – a systematic, repeatable way to find the root causes of human performance and equipment problems — the Root Cause Tree® helps investigators see beyond their current knowledge.
- Corrective Action Helper® – help lead investigators “outside the box” to develop effective corrective actions.
Check out our schedule for a course near you: http://www.taproot.com/courses#2-day-incident
I hope I’ve given you some food for thought. Thanks for visiting our blog and happy investigating.
You have established a good performance improvement program, supported by performing solid incident investigations. Your teams are finding good root causes, and your corrective action program is tracking through to completion. But you still seem to be seeing more repeat issues than you expect. What could be the problem?
We find many companies are doing a great job using TapRooT® to find and correct the root causes discovered during their investigations. But many companies are skipping over the Generic Cause Analysis portion of the investigation process. While fixing the individual root causes are likely to prevent that particular issue from happening again, allowing generic causes to fester can sometimes cause similar problems to pop up in unexpected areas.
6 Reasons to Look for Generic Root Causes
Here are 6 reasons to conduct a generic cause analysis on your investigation results:
1. The same incident occurs again at another facility.
2. Your annual review shows the same root cause from several incident investigations.
3. Your audits show recurrence of the same behavior issues.
4. You apply the same corrective action over and over.
5. Similar incidents occur in different departments.
6. The same Causal Factor keeps showing up.
These indicators point to the need to look deeper for generic causes. These generic issues are allowing similar root causes and causal factors to show up in seemingly unrelated incidents. When management is reviewing incident reports and audit findings, one of your checklist items should be to verify that generic causes were considered and either addressed or verified not to be present. Take a look at how your incident review checklist and make sure you are conducting a generic cause analysis during the investigation.
Finding and correcting generic causes are basically a freebie; you’ve already performed the investigation and root cause analysis. There is no reason not to take a few extra minutes and verify that you are fully addressing any generic issues.
When an employee is a witness to an incident that occurs in the workplace, what he or she witnessed becomes valuable information for evidence collection and finding and fixing the root causes. Retrieval from memory is hard work, and when an interview is not set up properly, a witness will not remember important details.
The two short videos below are actors playing the role of interviewer and interviewee in a mock incident investigation interview for a General Motors incident investigation training module. They created one “good” interview, and one “bad” interview scenario.
Let’s take a quick look at the bad scenario, what not to do when interviewing.
- The interviewer did not communicate open, friendly body language during the greeting or try to “break the ice.” Notice that the interviewer appeared uninterested in the interviewee when she sat down, and he gestured with palms down which may convey to the interviewee that he already knows what happened. Soon thereafter, he actually says the words “I know what happened” and “I gotta ask you some questions so I can fill out this report.” At this point, the interviewee may feel like the interview is just a formality and he doesn’t need her information. This mistake is a good way to completely shut the interviewee down right off the bat.
- The interviewer asked closed-ended, leading questions. “Was Larry wearing a seatbelt?” “Was Larry speeding?” “Was Larry out partying again last night?” The interviewer put the interviewee on defense with this line of questioning. Also, these questions are limited to a “yes” or “no” answer and will not elicit much information, and they are leading. The interviewer already told her “I know what happened” so she may have been afraid at this point to say “yes” or “no” because it may not be the same thing the interviewer “knows.” Overall, interviewees want to provide good information so when interviewers lead them into thinking they already have “the right” information, the interviewees may doubt what they witnessed so they can also give “the right” answer.
- The interviewer does not set up the cognitive interview properly and interrupts constantly. Interrupting when an interviewee is delivering a narrative (i.e., telling the story as she remembers it) is the worst mistake an interviewer can make because it causes the interviewee to lose her train of thought and valuable information she may provide. The interviewer has already made the mistake of assuming the principle role with his “I already know what happened” attitude so the interviewee will wait for him to ask specific questions without volunteering anything. The interviewer also said “I only have a few questions here.” This makes the interviewee feel like he is in a hurry so she should keep her answers brief.
How the interview could be improved:
- Begin the interview with a friendly tone to develop rapport. This includes open body language (smile, eye contact, open palms). Tell the interviewee about the purpose of the interview (to find the root causes of the incident so they can be corrected and kept from occurring again). If the interviewee was injured or witnessed a tragic accident, ask her how she is feeling or how she is doing since witnessing the accident. Be human. Research proves that the amount of information an interviewee remembers changes based on the tone established during the first few minutes of the interview.
- Save closed-ended questions to follow-up something specific the interviewee said. When the interviewee is telling her story (the narrative) of the incident and a question pops into the interviewer’s mind about what she said, don’t interrupt. After the witness gives her narrative, try open-ended questions before closing in on small details with closed-ended questions. This will keep the interviewee in memory retrieval mode for a little longer. The interviewer should write down questions and ask them after the interviewee has completely finished her narrative, and the questions should pertain to the narrative. For example, “You stated that you were on Workstation 3 when the incident occurred. Is that your normal workstation?”
- Set up the cognitive interview. There are three steps to setting up a cognitive interview. The first step is to tell the interviewee explicitly to assume the principle role. “I didn’t see the incident, so I’m relying on you to tell me what happened.” The second step is to ask the interviewee for the narrative. “Picture, in your mind’s eye, where you were right before the incident occurred. Think about where you were standing, what you were thinking and feeling at the time. Get a clear picture of your surroundings.” The third step is to ask the witness to report small details. “Tell me everything you remember about the incident no matter how trivial.” Then don’t interrupt!
Let’s take a quick look at a “good” interview.
Comment below on the techniques the interviewer used that made this interview better than the first as well as any mistakes in the first video that were not discussed above.
For more information about how to conduct an investigative interview, attend our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training.
I love to use Safeguard Analysis to examine incidents and determine Causal Factors.
What were the Safeguards keeping this officer safe and how did they fail? (A failed Safeguard is usually a Causal Factor.)
Watch and leave a comment about your ideas …
For the drug and medical device manufacturing industries, the US Code of Federal Regulations 211.22, Good Manufacturing Practices, states that if manufacturing errors occur, quality control should make sure that the errors “… are fully investigated.”
From past FDA actions it is clear that stopping the investigation at a “human error” cause is NOT fully investigating the error.
Here are three reasons people fail when they are investigating human error issues and when they develop fixes:
- They did not use a systematic process. 5-Whys is not a systematic process.
- The system they used did not guide them to the real, fixable causes of human errors (most quality professionals are not trained in human factors),
- The system did not suggest ways to fix human errors once the causes had been identified (the FDA expects effective corrective actions).
What tool provides a systematic process with guidance to find and fix the causes of human error? The TapRooT® System!
If you would like to read more about how TapRooT® can help you find the root causes of human error, see:
To learn about how to use TapRooT® to improve your investigations of human error, We suggest attending the 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training. See the list of public course held around the world at:
With your hard work and effort and a system that will find and fix the root causes of human error you can succeed in fixing human error issues and in meeting the FDA’s expectations.
Ever take your laptop to training to take notes? According to psychological research, (The Pen is Mightier than the Keyboard), if you want to retain what you learn during training, using a laptop to take notes is not a good idea.
The research indicates that the act of taking notes on a laptop seems to interfere with our ability to remember the information. Mueller & Oppenheimer, psychologists for the research, believe that’s because learners on laptops are mindlessly typing everything the instructor is saying. When tested, laptop users performed similar to pen notetakers on factual questions about the notes, but significantly worse on conceptual questions.
Since we can’t take notes as fast nor capture as much information with a pen, we are required to think and actively listen for what’s most important to write down. Thus, we store information into memory as we think about it.
One of the root causes of memory failure during learning appears to be the way we take notes. Will this research change the way you take notes in training? Leave your comments below.
“Doctor… how do you know that the medicine you prescribed him fixed the problem,” the peer asked. “The patient did not come back,” said the doctor.
No matter what the industry and or if the root causes found for an issue was accurate, the medicine can be worse than the bite. Some companies have a formal Management of Change Process or a Design of Experiment Method that they use when adding new actions. On the other extreme, some use the Trial and Error Method… with a little bit of… this is good enough and they will tell us if it doesn’t work.
You can use the formal methods listed above or it can be as simple for some risks to just review with the right people present before implementation of an action occurs. We teach to review for unintended consequences during the creation of and after the implementation of corrective or preventative actions in our 7 Step TapRooT® Root Cause Analysis Process. This task comes with four basic rules first:
1. Remove the risk/hazard or persons from the risk/hazard first if possible. After all, one does not need to train somebody to work safer or provide better tools for the task, if the task and hazard is removed completely. (We teach Safeguard Analysis to help with this step)
2. Have the right people involved throughout the creation of, implementation of and during the review of the corrective or preventative action. Identify any person who has impact on the action, owns the action or will be impacted by the change, to include process experts. (Hint, it is okay to use outside sources too.)
3. Never forget or lose sight of why you are implementing a corrective or preventative action. In our analysis process you must identify the action or inaction (behavior of a person, equipment or process) and each behaviors’ root causes. It is these root causes that must be fixed or mitigated for, in order for the behaviors to go away or me changed. Focus is key here!
4. Plan an immediate observation to the change once it is implemented and a long term audit to ensure the change sustained.
Simple… yes? Maybe? Feel free to post your examples and thoughts.
We can all remember some type of major product recall that affected us in the past (tires, brakes, medicine….) or recalls that may be impacting us today (air bags). These recalls all have a major theme, a company made something and somebody got hurt or worse. This is a theme of “them verses those” perception.
Now stop and ask, when is the last time quality and safety was discussed as one topic in your current company’s operations?
You received a defective tool or product….
- You issued a defective tool or product….
- A customer complained….
- A customer was hurt….
Each of the occurrences above often triggers an owner for each type of problem:
- The supplier…
- The vendor…
- The contractor…
- The manufacturer….
- The end user….
Now stop and ask, who would investigate each type of problem? What tools would each group use to investigate? What are their expertise and experiences in investigation, evidence collection, root cause analysis, corrective action development or corrective action implementation?
This is where we create our own internal silo’s for problem solving; each problem often has it’s own department as listed in the company’s organizational chart:
- Customer Service (Quality)
- Manufacturing (Quality or Engineering)
- Supplier Management (Supply or Quality)
- EHS (Safety)
- Risk (Quality)
- Compliance (?)
The investigations then take the shape of the tools and experiences of those departments training and experiences.
Does anyone besides me see a problem or an opportunity here?
Incident Investigation & Root Cause Analysis Sessions Offered Exclusively June 3-5, 2015 in Las VegasApril 29th, 2015 by Barb Phillips
I was at a conference yesterday and one of the talks was about advanced root cause analysis. The presenter’s company had their own “home grown” root cause analysis system and they discovered that they were not getting consistent results. Improvement was needed!
They studied their system and discovered something that was missing – management system causes. In the TapRooT® System we have called these “Generic Causes” since we copyrighted the first TapRooT® manual in 1991.
It made me think … Why did they wait 24 years to discover something we’ve known about since before 1991?
Next, I talked with an engineer who had been trained in a common cause and effect system. He wasn’t too pleased with the results he was getting. He wanted to know how TapRooT® could help. Was it different?
I shared how TapRooT® works (see this LINK for the explanation) and it took quite a bit of effort to get beyond the cause and effect model that he thoroughly understood so that he could understand why he was missing things. He was really smart. He asked very insightful questions. He latched onto the reasons that the less systematic cause and effect analysis led to inconsistent results. He saw how TapRooT® could help investigators go beyond their paradigm and get consistent results.
By the end of this second conversation I started thinking … How did we get so far ahead of common root cause systems?
I think I know the answer.
It starts with the Human Factors training that I received at the University of Illinois. It really showed me how to think about human centered design – including designing a root cause analysis system that people could use consistently.
Second, I was fortunate enough to work in the Nuclear Navy where there was an excellent process safety culture and for Du Pont where there was an excellent industrial safety culture. This helped me see how management systems made a difference to performance. (My boss and I at Du Pont actually coined the phrase “Management System” that is now commonly used throughout industry.)
Third, I was well trained by my mentor at the University of Illinois, Dr. Charles O. Hopkins, how to do applied research. So the research I did studying root cause analysis in the mid-1980’s and early 1990’s really paid off when we created the TapRooT® System.
Fourth, we had a really good team that brought out the best in each other during the early development.
Next, we were lucky to have some excellent clients in the nuclear, oil, and aviation industries that were great early adopters and provided excellent feedback that we used to quickly improve TapRooT® root cause analysis in the early and mid-1990’s.
Finally, I made friends with and/or listened to many industry gurus who were experts in safety, process safety, quality, and equipment reliability. Their influence was built into TapRooT® and helped it be a world-class system even in it’s early stages. These experts included:
- Jerry Ledderer, aviation safety pioneer
- Dr. Charles O. Hopkins, human factors pioneer
- Smoke Price, human factors expert
- Larry Minnick, nuclear safety expert
- Rod Satterfield, nuclear safety expert
- Dr. Alan Swain, human reliability expert
- Heinz Bloch, equipment reliability expert
- Admiral Hyman Rickover, father of the Nuclear Navy and process safety expert
- Dr. Christopher Wickens, human factors expert
- Dr. Jens Rassmussen, system reliability and human factors expert
- W. Edwards Deming, quality management guru
- Admiral Dennis Wilkerson, first CO of the Nautilus and first CEO of INPO
That’s quite a list and I was lucky to be influenced by each of these great men. Their influence made TapRooT® root cause analysis far ahead of any other root cause tool.
So that’s why I shouldn’t be surprised that others are finally catching on to things that we knew 25 years ago. Perhaps in a century, they will catch up with the improvements we are making to TapRooT® today (with the help of thousands of users from around the world).
If you would like to learn the state-of-the-art of root cause analysis and not wait 25 to 100 years to catch up, perhaps you should attend a TapRooT® Course in the next month or two. See our course schedule for upcoming public courses at:
And get information about all the courses we offer at:
And if you would like to learn about the state of the art of performance improvement, attend the 2015 TapRooT® Summit coming up on June 1-5 in Las Vegas. Get more information and download the brochure at:
But don’t wait. Every day you wait you will be another day behind the state-of-the-art in root cause analysis and performance improvement. Don’t be left behind!
TapRooT® Root Cause Analysis
Changing the Way the World Solves Problems
One of the final steps in performing a TapRooT® Root Cause Analysis is finding Generic Causes.
What is a Generic Cause? It is the reason that a root cause is widespread.
For example, a root cause for an error made while using a procedure might be that the procedure has more than one action per step.
4. Remove the drum lid and the polyethylene liner lid, place liner in prepared drum and place in loading position at the final packaging hut. Insert plastic bag in drum liner. Seal the plastic bag with tape to the inside of the drum loading insert.
The fix for this specific root cause might look something like this:
4. Remove the drum lid and the polyethylene liner lid. . . . . . ___
5. Place liner in prepared drum. . . . . . . . . . . . . ___
6. Place prepared drum in loading position at the final packaging hut. . ___
7. Insert plastic bag in drum liner. . . . . . . . . . . . ___
8. Seal the plastic bag with tape to the inside of the drum loading insert. ___
If the team then went to check other procedures and found that this problem was widespread, they would then have a generic problem. The question then becomes: “Why is the problem of ‘more than one action per step’ so widespread? What is the generic Cause that allows us to produce poor procedures?
The root cause analysis team may find that the people writing procedures have no guidance for writing procedures and no training on how to write procedures.
This should cause the team to look for other generic procedure problems.They might also find that procedure formats are confusing, the level of detail is inconsistent, there are excessive references, and the graphics need improvement.
The Corrective Action Helper® Guide provides guidance to fix these kinds of Generic Causes. But the widespread generic procedure problems probably indicate that the company or site doesn’t really know how to produce good procedures. Therefore, the Corrective Action Helper® Book recommendation to fix specific Generic Causes might not be enough guidance.
For example, the Corrective Action Helper® Guide says that for generic “greater than one action per step” problems, the investigators should consider:
“…a general procedure improvement program to remove multiple actions per step from the rest of the facilities procedures.”
However, if the procedures are in really bad shape, more must be done.
Of course, the Corrective Action Helper® Guide provides even more information – references. And if the investigators read the suggested reference, they may look for the additional problems and develop a plan to improve their procedures that is more comprehensive.
That would be great. But how many read the references? My guess is … not that many. After all, in today’s downsized, super-efficient workplace, people just don’t have time.
That’s why System Improvements is here to provide assistance.
If you run into generic problems that you think may be important to fix, we can help.
At a minimum, we can coach your team on the development of generic corrective actions.
Beyond that, we can put an evaluation team together to evaluate the scope of the Generic Cause and develop a plan to improve performance by eliminating the Generic Cause and upgrading current systems.
Finally, if you really need help, we can put together a team to help implement the fix. In this cause, a team of experienced procedure writers to help your company fix their current procedures and coach your procedure writers how to write better procedures in the future.
We can even make rerun visits to audit the status of the corrective actions and the work of your procedure writers.
So when you find a Generic Cause that you know your company isn’t good at fixing (or doesn’t have the time to explore and fix), remember that System Improvements can help.
Don’t let problems repeat because Generic Causes are left un-fixed. Get help. Call us at 865-539-2139 or CLICK HERE to send us a message. We can help you improve!
Eliminating waste is at the core of Lean Manufacturing. But even without a lean program, any manufacturing manager knows that process downtime can be costly.
Process downtime can cause:
- delayed orders,
- missed schedules,
- missed earning projections, and
- increased costs,
Improving process reliability is the same as improving safety, quality, and equipment reliability. When a process reliability problem happens, it needs to be investigated and the root causes need to be found and fixed.
How do you find and fix the causes of process downtime? You can use the same tools that experts use to find the root causes of other to find the root causes causes of safety incidents, equipment failures, and quality issues. The TapRooT® Root Cause Analysis System.
An example of a process reliability improvement success story is share at:
And they used TapRooT® to go from losing money to a profitable operation. How did TapRooT® help? Watch the video and read about how to use TapRooT® to find root causes at:
Root Cause Analysis Tip: Protecting Your Root Cause Analysis from Discovery – Work Product and MotivationMarch 10th, 2015 by Mark Paradies
Saw an interesting short piece on McGuireWoods web site. It describe a case between Chevron Midstream Pipelines and Sutton Towing LLC.
It seems the court decided that a “legally chartered” root cause analysis that was performed at the direction of in-house Chevron attorneys was not different from normal root cause analysis that the company performed after any incident.
Why? Because of the motivation to perform this root cause analysis was the same as any other RCA. The judge relied on several pieces of evidence:
- A Chevron engineer “who agreed in her deposition that the ‘primary purpose of a root cause analysis’ is to ‘prevent a similar accident from happening again in the future,'” and “that it is ‘part of the Chevron ordinary course of business to conduct a root cause analysis’ after an incident.”
- “Chevron Pipeline’s President’s statement in an employee newsletter that ‘[w]e are conducting root cause analyses of both incidents and will apply lessons learned. Our ultimate goal remains the same – an incident and injury-free workplace.’”
- “Chevron’s failure to provide the court examples of Chevron’s ordinary root cause analyses — noting that Chevron’s argument that its ordinary ‘incident reviews’ were different from its ‘legally chartered’ investigation ‘would be more convincing if there was actually another root cause analysis from which to distinguish the legally chartered one.'”
As Thomas Spahn, attorney from McGuireWoods wrote:
“To satisfy the work product motivation element, companies must demonstrate that they did something different or special because they anticipated litigation — beyond what they ordinarily would do, or which they were compelled to do by external or internal requirements.”
Of course, we always recommend that the statements in an incident report be carefully written and accurate. The words used can make a huge difference if your report is introduced as evidence in court.
Remember, what you write may not be interpreted or used as you intended it after the fact. An even if you think your investigation is protected as part of an attorney’s work product, the court may not agree.
Sometimes I get the impression that some managers think that performance improvement is an optional activity that can be cut to meet budget goals. That view surprises me because I think that performance improvement is an essential activity that can’t be cut because it supports activities that:
- Stop Fatalities
- Reduces Regulatory Conflict
- Avoids Major Financial Losses
- Keeps Clients Happy
- Eliminates Bad Press
- Improves Operational Efficiency and Equipment Reliability
After all, can you really afford deaths, regulatory initiatives, major losses, unhappy clients, bad press, and broken, inefficient operations?
If your performance improvement program isn’t world class, you are inviting disaster. And disaster is expensive. Every cent you save by reducing effective performance improvement efforts will come back to you in expensive accidents, incidents, plant upsets, equipment downtime, and regulatory headaches.
So, the next time management has a great idea to cut the performance improvement budget, remind them what the budget does for them. Remind them of the losses avoided and the good nights of sleep they get and how bad it will be when things go haywire.
Tune in to this week’s TapRooT® Instructor Root Cause Analysis Tip with Chris Vallee. He shares a great process quality tip and news about his upcoming Process Quality & Corrective Action Track at the 2015 Global TapRooT® Summit, June 3-5, 2015 in Las Vegas, Nevada!
Was this tip helpful?
Check out more short videos in our series:
Equifactor® – Are You Using it to Prevent Equipment Failures? (Click here to view tip.)
Be Proactive with Dave Janney (Click here to view tip.)
Conduct Real-Time Peer Reviews with Mark Paradies (Click here to view tip.)
What Makes a World-Class Root Cause Analysis System with Ken Reed (Click here to view tip.)
I was thinking about the ways that trying to be cheap when doing root cause analysis could cost companies millions of dollars, when a discussion with a legal counsel gave me an additional idea. Then I thought,
“I need to share these ideas to keep people from making these mistakes.”
1. CHEAP INVESTIGATIONS
I’ve seen many companies assign supervisors to investigate accidents “in their spare time.” This is definitely a cheap investigation. But the problem is that the results could cost the company millions of dollars.
For example, let’s say that a near-miss doesn’t cost anything and no one is seriously injured. Therefore, a supervisor does a quick investigation without looking into the problem in too much detail. He recommends re-training those involved and the training is conducted days later. Case closed!
However, the root causes and failed safeguards for a bigger accident are never fixed. Nearly a year later, a major accident occurs that could have been prevented IF the root causes of the previous near-miss had been found and fixed. However, because a “cheap” investigation was performed, the causes were never identified and 10 people died needlessly. The company spent $1 million on an OSHA fine and almost $100 million more on legal and settlement costs.
What do you think? Was the savings of a cheap investigation worthwhile?
One key to a world-class incident investigation and root cause analysis program is to spend time identifying which “small incidents” are worthy of a good investigation because they have the potential to prevent major accidents. These near-misses (of a big accident) should be treated as seriously as the big accident itself with a thorough investigation , management review, and implementation of effective corrective actions to prevent recurrence of the causes (and, thus, the big accident that’s waiting to happen).
2. CHEAP CORRECTIVE ACTIONS
I’ve seen companies try to perform a thorough root cause analysis only to try to take the cheap way out when it comes to corrective actions.
You have probably all seen “cheap” corrective actions. Try these:
- Caution workers to be more careful when …
- Re-train employees to follow the procedure.
- Re-emphasize to employees the importance of following the rules.
These seem cheap. (Cautioning employees is almost free.) But the change very little and will be forgotten in days or at least in several months. Plus, new folks who join the organization after the caution, re-train, or re-emphaize occurs, won’t get the repeated emphasis.
What happens? The incident tends to repeat after a period of time. And repeat incidents can be expensive. Thus by saving on corrective actions, you may be costing your company big bucks.
Instead, for investigations that could prevent major accidents, investigators should propose (and management should insist upon) corrective actions that remove the hazard, remove the target, or significantly improve the human factors of the safeguards that are used to prevent a repeat of the accident. These may not be cheap but they will be infinitely more effective.
What if one of these three choices can’t be implemented? Then one or more additional safeguards that are effective should be developed.
3. CHEAP TRAINING
The legal counsel that I was talking to told me that MOST “TapRooT® Users” he ran into during their preparation for trails had never been formally trained in TapRooT®. The attorney had attended one of our public TapRooT® Courses. He was amazed that management at fairly major companies would assign people who had never been to ANY formal root cause analysis training to investigate serious incidents that had potential for expensive legal outcomes.
In one instance, the person using TapRooT® had obtained one of our old TapRooT® Books from a friend. He then “used” the technique after reading “some” of the book. He didn’t have a Root Cause Tree® Dictionary or a Corrective Action Helper®. However, his reading didn’t provide him with the knowledge he needed to use TapRooT® correctly when investigating serious incidents (or not serious ones for that matter).
Don’t get me wrong, the TapRooT® Book is a great read. But I would never recommend it as the only source of training for someone who will be investigating serious accidents (fatalities and major environmental releases). What would I recommend? The 5-Day TapRooT® Advanaced Root Cause Analysis Team Leader Training.
The attorney also mentioned that he frequently meets TapRooT® Users who are out of practice using TapRooT® and really need a refresher because they don’t have many serious accidents to investigate and don’t get any feedback even when they do an investigation. My answer to that was ….
- They should be using TapRooT® proactively to get practice using the techniques.
- They should set up a company peer review process to help users get better at applying the techniques.
- They should attend the Incident Investigation and Root Cause Analysis Track at the Global TapRooT® Summit at least every two years to keep up with the latest improvements in the TapRooT® Techniques.
By the way, what had the “cheap training” cost the company? Over $50 million dollars in settlement costs.
HIGHLY QUALIFIED, COMPETENT, PRACTICED TapRooT® INVESTIGATORS ARE IMPORTANT INVESTMENTS
The first thing management needs to understand is that they need to invest in their incident investigators. Saving on training on root cause analysis is a stupid idea.
THOROUGH ROOT CAUSE ANALYSIS OF INCIDENTS THAT COULD HAVE BEEN MAJOR ACCIDENTS ARE IMPORTANT INVESTMENTS
Once you have excellent investigators, make sure they have the time and resources needed to investigate all incidents/near-misses that have a potential to become major accidents. Saving money on investigations is a fool’s mission.
CORRECTIVE ACTIONS THAT COULD PREVENT MAJOR ACCIDENTS ARE IMPORTANT INVESTMENTS
Management should insist upon effective corrective actions that go beyond training. Saving money by implementing “cheap” corrective actions is a false savings that will come back to haunt the company.
DON’T MAKE THESE MISTAKES! Invest in effective root cause analysis and prevent major accidents from occurring.
Many people know how successful TapRooT® is at stopping safety incidents. But I had a potential TapRooT® User call me to ask:
“Can TapRooT® be used to solve quality issues?”
I was surprised by the question. Of course, the answer is YES!
We’ve had people using TapRooT® to solve quality problems ever since we invented it. In our first consulting job back in 1989, we used TapRooT® to solve engineering and construction quality issues.
Why didn’t this potential TapRooT® User know that TapRooT® could be applied to quality issues?
The only answer was … We had not told him!
Quality issues, just like safety issues, are mainly caused by human errors. And TapRooT® is excellent at helping people find the correctable root causes of human errors.
Why does TapRooT® work on all kinds of problems (including ones that cause quality issues)? Because TapRooT® doesn’t care what the outcome of an error is. TapRooT® is looking for the correctable cause (or causes) of the error.
For example, an operator working in a factory may open the wrong breaker and stop the wrong piece of equipment. When he makes this mistake, he doesn’t know if the outcome will be a safety incident, a maintenance headache, an operations problem, or a quality issue. He wan’t planning on making the mistake and he certainly wasn’t deciding what kind of outcome his mistake would result in. And fixing the reason for his mistake will stop the problem no matter what outcome occurred after the error.
That’s why the examples in our standard 2-Day and 5-Day TapRooT® Courses apply not only to safety, but also to quality, maintenance, operations, and even hospital patient safety issues.
So if you are wondering if TapRooT® would work for the type of issues that your company faces, the answer is YES!
When using TapRooT®, most of the terms are pretty self-explanatory. TapRooT® is pretty easy to understand and use. However, there are a few terms that we use that may be a little different than those you might be used to. I thought I’d give a few definitions to help make things just a little bit clearer.
Root Cause Tree®: This is the heart of the TapRooT® system. It is contains the guidance and the root causes needed by the investigator.
Root Cause Dictionary®: Contains a list of bulleted yes/no questions that guide your investigator through the Root Cause Tree®.
SnapCharT®: This is a visual representation of the investigation. It is used to document the evidence you find during your investigation, allows you to identify Causal Factors, and is used with the Root Cause Tree® during the analysis. It contains the Incident, Event, and Condition shapes.
Incident: This is the reason you are performing the investigation. It is the problem that lead you to start your TapRooT® process. It is a circle on your SnapCharT®.
Event: An action performed by someone or a piece of equipment. They are arranged in chronological order as rectangles on the SnapCharT®.
Condition: A piece of information that describes the Event that it is attached to. Represented by an oval on the SnapCharT®.
Root Cause: The absence of best practices or the failure to apply knowledge that would have prevented the problem (or significantly reduced the likelihood or consequences of the problem).
Causal Factor: Mistake or failure that, if corrected, could have prevented the Incident from occurring, or would have significantly mitigated its consequences.
Generic Cause: A systemic problem that allows a root cause to exist.
Root Cause Analysis Tip: What is a corrective action worth? – A Gambler’s View of Corrective Actions (A Best of Article from the Root Cause Network™ Newsletter)December 3rd, 2014 by Mark Paradies
Adapted from the January 1995 Root Cause Network™ Newsletter, Copyright © 1995. Reprinted by permission. Some modifications have been made to update the article.
A GAMBLER’S VIEW OF CORRECTIVE ACTIONS
WHEN TO BET/WHEN TO FOLD
A winning gambler knows the odds. He knows that in the long run, he can beat the odds. Therefore, he looks for opportunities to bet more when the odds are in his favor. And when the odds are against him, he folds and waits for a better hand.
Preventing accidents is a numbers game. The pyramid blow provides a typical example of the ratio of accidents to incidents to near-misses to unsafe conditions.
In this pyramid, every incident must have the potential under slightly different circumstances to become the major accident at the top of the pyramid. Also, every near miss must have the potential to become an incident that could have become the top level accident. Finally, every unsafe condition could have caused a near-miss that could have become an incident that could have become the top level accident.
Thus, every unsafe act included at the bottom level of the pyramid must have the potential with the right set of circumstances to “cause” the top level accident.
The ratio above might not be exact. Your facility might be different. But we will use the ration of 1000 unsafe acts for every major accident as a starting point for out calculation of odds that we describe below.
The point is that every corrective action that fixes an unsafe condition has some odds of being the corrective action that could be preventing a major accident. Thus, we should try to understand the value NOT ONLY of the benefits that the corrective action immediately brings, BUT ALSO the reduction in the odds of a major accident that this corrective action provides.
THE COST OF A MAJOR ACCIDENT
To calculate the value of preventing a major accident, we need to calculate the potential cost of a major accident at your facility.
Of course, we don’t know the exact cost of the biggest accident (or even a typical major accident) that you face at your company. After all, they still don’t know what the cost of the Deepwater Horizon accident will be even after years of litigation. So, we have to make an educated guess that can be scaled to show how the cost could change.
For example, we might say that the cost a typical major accident would be $1,000,000,000.
Then, if you think your accident might be ten times worse (or ten times less), you can multiple or divide the results we calculate by 10.
ASSESSING THE ODDS
Why do we have to use “odds” to perform this calculation? Because you can’t tell exactly which unsafe condition will be related to your next major accident. We don’t know what corrective action that we implement today will prevent the next Deepwater Horizon, Three Mile Island, or Exxon Valdez type accident that costs billions of dollars. No one is that prescient. That’s why preventing major accidents is a numbers game. To prevent the next major accident you must reduce thousands of unsafe conditions.
Because the exact odds of any one unsafe act being a key factor in the next accident is unknowable, we assign equal potential to every unsafe condition that has potential to cause a major accident.
If the pyramid above represents your accident pyramid, then for every major accident, there are 1000 unsafe conditions that could contribute to it. Or another way to think about it is that we can’t predict the exact combination of factors that will cause the next major accident but if we do 1000 things to fix problems that could be involved in a major accident, we will stop one major accident.
Thus the odds that any one corrective action will stop a major accident is 1000 to 1.
CALCULATING THE VALUE OF A CORRECTIVE ACTION
I’ve seen people value corrective actions by using the value of the incident they would prevent.
For example, if the failure of a machine caused a delay that lost the company $100,000, the value of the corrective actions to prevent future failures would be $100,000. It’s never clear to me if this value should be divided between all of the corrective actions (for example, if there are 10 corrective actions, each would be worth, $10,000) or if each corrective action is worth $100,000. But the idea is that the corrective actions can be valued by the costs that will be saved from future similar incidents prevented.
What this equation leaves out is the value of an even worse accident that could also be prevented by the corrective actions.
Thus to calculate the value of a corrective action, you not only need to calculate the direct benefit, but also the amount that that corrective action contributed to the prevention of a major accident (if, indeed the corrective actions could help prevent a major accident).
But let’s stop here to correct misconceptions. A corrective action meant to stop paper cuts probably have very little value in preventing major accidents. Thus, we are not assigning severe accident risk to every corrective action. We would only assign the value to corrective actions that could help prevent major accidents.
The, the value of a corrective action is the direct cost that the corrective action saves us PLUS the value of the unknown major accident that it could prevent divided by the odds.
For example, if a corrective action saved us $10,000 in direct costs for a similar incident and if the value of a major accident at your facility is $1,000,000,000 and if we estimate that it will take correcting 1,000 unsafe acts to prevent the next accident, the value of our corrective action is…
VALUE = $10,000 + ($1,000,000,000/1000)
VALUE = $10,000 + $1,000,000
VALUE = $1,010,000
Thus valuing corrective action at their benefit for preventing a similar incident is UNDERVALUING the corrective actions.
And I believe we frequently undervaluing corrective actions.
Because we aren’t considering the value that a gambler sees. We are folding when we should be betting!
We should be investing much more in effective corrective actions thereby win by preventing the next major accident.
YOU CAN IMPROVE THE ODDS
There is even better news that can help you make the corrective actions you implement even more valuable (effective).
The TapRooT® Root Cause Analysis System can help you do a better job of analyzing potential problems and developing even more effective corrective actions for the root causes you uncover.
Think of TapRooT® as a luck rabbit’s foot that increases your odds of winning.
Of course, TapRooT® is much better than a lucky rabbit’s foot because instead of being built upon superstition, it is built upon proven human performance and equipment reliability technology that makes your investigators much more effective.
So don’t wait. Stop undervaluing your corrective actions and if you haven’t already started using TapRooT®, see our upcoming courses list, click on your continent, and get signed up for a course near you (or in a spot that you would like to visit).