Category: Root Cause Analysis Tips
Is it more important to identify where a defect occurred or when the defect become apparent?
Several children in 2016 were left disappointed after their Christmas Gift, Hatchimals, did not hatch.
In a statement to Global News, Spin Master said they have added extra resources to help customers in the wake of a spike in calls.
“While the vast majority of children have had a magical experience with Hatchimals, we have also heard from consumers who have encountered challenges. We are 100% committed to bringing the magic of Hatchimals to all of our consumers,” said a company spokesperson.
“We are committed to doing everything possible to resolve any consumer issues. We sincerely apologize and thank everyone who is experiencing an issue for their patience.”
Which stakeholder was impacted the most in the defective product issue above?
- The child?
- The gift purchaser?
- The distributor, like Amazon?
- The product manufacturer, Spin Master?
While this was just a toy that went bad, think about the same questions for any other product and ask the same question again, “Is it more important to identify where a defect occurred or when the defect become apparent?”
- Cracked syringe for onsulin injection
- Diary product that is expired
- Top-drive gears use on an oil-rig
Benefits of finding and analyzing a defect early in production:
- Company reputation
- Safety to customer
- Less delay between defect occurrence and relative evidence
- The ability to stop the production process immediately
Cons to having the customer report the defect:
- Magnitude of impact to safety and customer business can be greater
- Product fixes are closer to triage and damage control repairs as opposed to identification of root causes
- Degraded company reputation
- Harder to collect how the customer used the product in the field
- Takes more company resources to investigate the problem
- You have to earn the clients’ trust back no matter how well you remedy the problem
Timeliness of defect identification as well as finding the real root causes of the problem is vital for a business’s success and longevity. Recovering from a defect that escaped to the customer no matter what the fix is, becomes a loss of trust. So what are the recommendations to be proactive:
- Identify defect opportunities critical to customer success.
- Mistake-Proof for the critical opportunities when possible.
- Develop visible triggers and indicators at time of occurrence for defects that cannot be prevented 100 percent.
- Track and Trend types of defects, defect occurrence locations, gap between time of occurrence, time of identification and time to complete the corrective action.
- Track repeat occurrences and analyze for the failure of the previous corrective action…. Often related to poor root cause analysis and/or poor corrective action.
For continued discussion on the defect identification and correction, I look forward to your comments. Or even better, I look forward to seeing you in one of our TapRooT® Root Analysis Courses.
Our 2016 Global TapRooT® Summit was a great success last year! Our attendees helped one another by sharing some of their best practices. Here Charlotte Grainger discusses how her company has instituted a program requiring investigators to be recertified every three years.
(Click post title if the video is not displaying.)
I’ve heard many high level managers complain that they see the same problems happen over and over again. They just can’t get people to find and fix the problems’ root causes. Why does this happen and what can management do to overcome these issues? Read on to find out.
Blame is the number one reason for bad root cause analysis.
Because people who are worried about blame don’t fully cooperate with an investigation. They don’t admit their involvement. They hold back critical information. Often this leads to mystery accidents. No one knows who was involved, what happened, or why it happened.
As Bart Simpson says:
“I didn’t do it.”
“Nobody saw me do it.”
“You can’t prove anything.”
Blame is so common that people take it for granted.
Somebody makes a mistake and what do we do? Discipline them.
If they are a contractor, we fire them. No questions asked.
And if the mistake was made by senior management? Sorry … that’s not how blame works. Blame always flows downhill. At a certain senior level management becomes blessed. Only truly horrific accidents like the Deepwater Horizon or Bhopal get senior managers fired or jailed. Then again, maybe those accidents aren’t bad enough for discipline for senior management.
Think about the biggest economic collapse in recent history – the housing collapse of 2008. What senior banker went to jail?
But be an operator and make a simple mistake like pushing the wrong button or a mechanic who doesn’t lock out a breaker while working on equipment? You may be fired or have the feds come after you to put you in jail.
Talk to Kurt Mix. He was a BP engineer who deleted a few text messages from his personal cell phone AFTER he had turned it over to the feds. He was the only person off the Deepwater Horizon who faced criminal charges. Or ask the two BP company men who represented BP on the Deepwater Horizon and faced years of criminal prosecution.
How do you stop blame and get people to cooperate with investigations? Here are two best practices.
A. Start Small …
If you are investigating near-misses that could have become major accidents and you don’t discipline people who spill the beans, people will learn to cooperate. This is especially true if you reward people for participating and develop effective fixes that make the work easier and their jobs less hazardous.
Small accidents just don’t have the same cloud of blame hanging over them so if you start small, you have a better chance of getting people to cooperate even if a blame culture has already been established.
B. Use a SnapCharT® to facilitate your investigation and report to management.
We’ve learned that using a SnapCharT® to facilitate an investigation and to show the results to management reduces the tendency to look for blame. The SnapCharT® focuses on what happened and “who did it” becomes less important.
Often, the SnapCharT® shows that there were several things that could have prevented the accident and that no one person was strictly to blame.
What is a SnapCharT®? Attend any TapRooT® Training and you will learn how to use them. See:
2. FIRST ASK WHAT NOT WHY
Ever see someone use 5-Whys to find root causes? They start with what they think is the problem and then ask “Why?” five times. Unfortunately this easy methods often leads investigators astray.
Because they should have started by asking what before they asked why.
Many investigators start asking why before they understand what happened. This causes them to jump to conclusions. They don’t gather critical evidence that may lead them to the real root causes of the problem. And they tend to focus on a single Causal Factor and miss several others that also contributed to the problem.
How do you get people to ask what instead of why?
Once again, the SnapCharT® is the best tool to get investigators focused on what happened, find the incidents details, identify all the Causal Factors and the information about each Causal Factor that the investigator needs to identify each problem’s root causes.
3. YOU MUST GO BEYOND YOUR CURRENT KNOWLEDGE
Many investigators start their investigation with a pretty good idea of the root causes they are looking for. They already know the answers. All they have to do is find the evidence that supports their hypothesis.
What happens when an investigator starts an investigation by jumping to conclusions?
They ignore evidence that is counter to their hypothesis. This problem is called a:
It has been proven in many scientific studies.
But there is an even bigger problem for investigators who think they know the answer. They often don’t have the training in human factors and equipment reliability to recognize the real root causes of each of the Causal Factors. Therefore, they only look for the root causes they know about and don’t get beyond their current knowledge.
What can you do to help investigators look beyond their current knowledge and avoid confirmation bias?
Have them use the SnapCharT® and the TapRooT® Root Cause Tree® Diagram when finding root causes. You will be amazed at the root causes your investigators discover that they previously would have overlooked.
How can your investigators learn to use the Root Cause Tree® Diagram? Once again, send them to TapRooT® Training.
The TapRooT® Root Cause Analysis System can help your investigators overcome the top 3 reasons for bad root cause analysis. And that’s not all. There are many other advantages for management and investigators (and employees) when people use TapRooT® to solve problems.
If you haven’t tried TapRooT® to solve problems, you don’t know what you are missing.
If your organization faces:
- Quality Issues
- Safety Incidents
- Repeat Equipment Failures
- Sentinel Events
- Environmental Incidents
- Cost Overruns
- Missed Schedules
- Plant Downtime
You need to be apply the best root cause analysis system: TapRooT®.
Learn more at:
And find the dates and locations for our public TapRooT® Training at:
While we probably would not see a frequency chart in real life like the one above, we all have seen or perceived the above rejection reasons after sending in our root cause analysis report to senior management or a regulator. Below are a few reasons that have caused a report or corrective action in a report to be rejected.
1. Rejection Example 1 (FDA):
We have reviewed your firm’s response of February 3, 2010, and note that it lacks sufficient corrective actions.
Specific violations observed during the inspection include, but are not limited, to the following:
1. Your firm has failed to reject drug products that did not meet established standards or specifications [21 C.F.R § 211.165(f)].
In your response, you state that this product is no longer manufactured and that such practices do not represent your company’s current CGMP compliance standards. You have committed to have all current and future investigations reviewed and signed by the Vice President of Quality Operations. However, you did not review your records to ensure that other products that failed to meet AQLs were not distributed. In addition, your response does not include training of the QCU to ensure that they are capable of identifying and ensuring appropriate corrections of these types of discrepancies in the future.
Problem Assessed: Company did not look for extent of condition (generic/systemic issues) or a complete corrective action with follow through.
2. Rejection Example 2 (NRC)
Company failed to correct CAPA 15-171, closed November 30, 2015, for finding 60010. CAPA 15-171 corrective actions required a revision to work instructions to include a pressure setting for contact blocks 60010. After discussions regarding the pressure setting with Company quality inspectors, the NRC inspection team identified that Company had not updated the work instructions.
Problem Assessed: Original finding did not get addressed nor were there any root causes identified for the original issue.
Just like students in a classroom, each report writer learns what the senior executive or regulator expects when writing an investigation report, often through trial and error. Often in some industries it seems that more time is spent writing an investigation report than is spent on the actual investigation.
How can you reduce the number of rejections that you might face while still ensuring a concise root cause analysis with effective corrective actions. Follow the steps below.
1. Do not let the written report criteria drive the root cause analysis itself.
• Perform the root cause analysis using an unbiased process like we do in a TapRooT® investigation.
• Collect the type of information that is required for the written report however do not limit what is collected.
2. Define the criteria for each section of the written report and hold that criteria true when writing a report.
• There should be little overlap in terms such as Causal Factor, Root Cause and Incident. In other words, no gray areas for interpretations.
• When within your control, reduce redundancy in your written report.
3. The written report should be concise and include enough information to be a standalone document as needed for the audience reading it. There should be no doubt when reading a report as to:
• What was the incident
• What led up to the incident
• What was the response to the incident
• What were the causal factors for the incident
• What were the root cause for the incident
• How each root cause will be addressed, whether eliminated or mitigated.
While there will be additional criteria required by the report requester for the writer to meet, the truer one stays to the purpose of an investigation and its documentation, the higher the chance of reducing said incident in the future.
Want to learn how to create a paperless report? Check out our series here.
Our 2016 Global TapRooT® Summit was a great success last year! Our attendees helped one another by sharing some of their best practices. Listen as Robert Oliver talks about how his company uses weekly review boards to examine incidents.
(Click post title if the video is not displaying.)
Our 2016 Global TapRooT® Summit was a great success last year! Our attendees helped one another by sharing some of their best practices. Here Emad Gomaa talks about improving communication between the company and the customers.
(Click post title if the video is not displaying.)
Happy Wednesday and welcome to this week’s root cause analysis tips.
Many companies are ISO certified and some of those that are not have some type of management system. There are too many different systems and standards out there to discuss individually, but one of the common themes is continuous improvement.
Whether you use a commonly known management system or developed your own, one of your goals should be to improve your system/business. When I think of a management system, I think of it as a framework for how you manage your business. Whether required or not, incorporating continuous improvement is a smart thing to do.
While ISO has hundreds of standards, some of the most commonly known are 9000 (Quality) and 14000 (Environmental); coming down the pike soon is 45001 (Safety). There are also numerous industry specific standards. Many of the ISO standards use a common framework that includes the PDCA (plan, do, check, act) cycle. This is where TapRooT® can help.
PDCA is a simple process that has been in use widely since the 1950’s. I do not know many processes that have endured that long. So why? Because it is easy and it works.
As part of PDCA, you have to determine what to fix, how to fix it, and whether it works. Sounds a little like root cause analysis and corrective action, doesn’t it? So if you were going to use PDCA to help solve your problems, what would you use for root cause analysis? If I were you, I would use TapRooT®. Need help with corrective actions? Use the Corrective Action Helper®, SMARTER Matrix, and Safeguards hierarchy. You can incorporate TapRooT® tools into any improvement framework you use.
Also, don’t forget the importance of auditing. This should be part of your management system as well. We’ve taught auditing with TapRooT® for years, but we recently developed a new course specifically for Auditors, TapRooT® for Audits, and wrote a new book, TapRooT® Root Cause Analysis for Audits and Proactive Performance Improvement. The primary topic of the book is auditing, but we also have a short section on PDCA. We’ll be teaching this course in Charlotte, NC in May if you would like to join us. Or, if you are already TapRooT® trained, you can get the book on our store.
Thanks for reading the blog, and best of luck with your improvement efforts.
Our 2016 Global TapRooT® Summit was a great success last year! Our attendees helped one another by sharing some of their best practices. Watch as Megan Lowry talks about the use of fees to improve safety on the airport apron.
(Click post title if the video is not displaying.)
If you’re a TapRooT® User, you know that drawing a SnapCharT® is the first step in your investigation whether it is for a low-to-medium risk incident or a major Investigation. What is a SnapCharT®? It is a timeline of events, a fact-finding tool that helps an investigator understand what happened.
So why is a SnapCharT® essential to evidence collection? Here are three reasons:
- It is an investigator’s duty to support all the facts discovered on the SnapCharT® with evidence. Otherwise, the timeline is simply an assumption of events. One of the primary reasons investigators run into problems determining causal factors is because the sequence of events they developed was not supported by evidence.
- A SnapCharT® is a planning tool for evidence collection. It helps organize and understand what information is readily available and what needs to be collected immediately.
- A SnapCharT® helps an investigator establish a list of potential witnesses to interview. Also, instead of starting interviews with the generic, “Tell me what happened,” investigators can ask questions right off of their SnapCharT®s.
These are only three ideas about how you can use a SnapCharT® for evidence collection. Did you know we offer a 2-day course on all of the advance techniques of evidence collection and interviewing? Learn about it here.
We also have a new book, Evidence Collection and Interviewing Techniques to Sharpen Investigation Skills that will be released soon. Would you like to be added to the waiting list? Contact me at email@example.com and I will let you know as soon as it is added to our online store. Also, please don’t hesitate to contact me if you are interested in holding the course at your facility. As a co-developer of the course, I can answer your questions and help you determine if it’s a good fit.
Our 2016 Global TapRooT® Summit was a great success last year! Our attendees helped one another by sharing some of their best practices. Here is Debra Matson describing how they use opinion makers to improve their RCA performance.
(Click post title if the video is not displaying.)
Many forget that procedures were put in place to prevent a loss of control of a process, or if a regulatory driven requirement to use a procedure, a perceived risk of loss of control of the process. With that concept in mind, we can see in the image above that procedures are a lower and less reliable control in the mistake-proofing hierarchy and that it requires more external quality control assessments and observations.
But this article is not about how much quality control is needed to ensure that workers use a procedure as written to prevent mistakes. Instead, this article is about when workers make a mistake when they followed the mistake-proofing procedure as written. If a procedure is already at a weak level of control, how is it that an issue with writing of, auditing of or use of an ineffective procedure was allowed to exist?
To clarify how TapRooT® Root Cause Analysis defines a procedure, we look at the intent of how it is used and not necessarily what it is called. If a list of steps on how to perform a task is written down and must be read and followed while performing the task, it is a procedure to TapRooT®. For example,
- A metal placard on how to set up the lathe that you require the operator to read every time for set up is a procedure.
- The SOP for putting on your seatbelt listed in the car manual that you only reference occasionally to successfully put your seatbelt on is NOT a procedure.
Not every task needs a procedure as TapRooT® defines so why is this distinction about procedures and non-procedures important? Simple….
.. if the task to be performed cannot be done out of sequence and a step is so critical not to miss and the steps are too numerous to remember successfully, that procedure better meet the needs of the task and the worker.
You must assess the worker’s knowledge and the tools required to be used during the task as it relates to the procedure in use.
Years ago I was asked to analysis a quality defect that occurred on a large product assembly line after workers had cut off too much material. Initially management thought that the two assemblers did not follow the procedure as written and wrote them up per the discipline policy. After further analysis however, the assemblers did use it as written, but the procedure as written did not fulfill the successful implementation of the task. By the way, this procedure had been in use for years. How??
Procedure related root causes identified for why the assemblers cut off too much material from the product while assembling it using the procedure as written were:
- Details Need Improvement – The procedure stated to install a cutting tool but never identified that shims had to be put in plus to center the cutting tool into the assembly prior to cutting the excess material off. The person who did this task for 20 years had just retired and the task was given to two experienced assemblers new to this task.
- Graphics Need Improvement – The picture of the access opening with the tool placed in it included no indication of centering nor any measurements.
There was another root cause that was not due to how the procedure was written but tied to the tool that was specified to be used:
- Tools/instruments Need Improvement – The cutting tool cutouts never perfectly aligned to the access opening in all areas of the assembly. The long term assembler would always use the tool up to a point and then cut by hand using his own measurements and skill.
This then made us look at our audits and tool calibration as this tool and procedure had been inspected numerous times throughout the years but never at the task level. Your take home today:
.. if the task to be performed cannot be done out of sequence, and a step is so critical not to miss, and the steps are too numerous to remember successfully, that procedure better meet the needs of the task and the worker.
If you want to see examples of other poorly written procedures and want to learn how to assess and correct this procedures at the task level, join us at an upcoming 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training Course.
Our 2016 Global TapRooT® Summit was a great success this year! Our attendees helped one another by sharing some of their best practices. Listen as George Kooi describes how their
leadership validates Corrective Actions through approval of the Corrective Actions https://vimeo.com/194840836
(Click post title if video is not displaying.)
Whether analyzing customer complaints, process defects or safety findings, the use of 5 Whys for problem-solving has been in place for many years; if you are still using it for low risk issues, below are links to additional articles to help you be more effective in its use:
This blog article, however, is to understand what many mean when asking why or how it is perceived when asked why during problem solving. I thought I would make it easy and define what why means using the Oxford Dictionary. I asked myself why after I did that!
– Expressing surprise or indignation: Why, that’s absurd!
– Used to add emphasis to a response: You think so? Why, yes.
– For what reason or purpose: Why did he do it?
– [with negative] Used to make or agree to a suggestion: Why don’t I give you a lift?
– (with reference to a reason) on account of which; for which: The reason why flu jabs need repeating every year is that the virus changes.
– The reason for which: Each has faced similar hardships, and perhaps that is why they are friends.
– A reason or explanation: The whys and wherefores of these procedures need to be explained to students.
– Old English hwī, hwȳ ‘by what cause’, instrumental case of hwæt ‘what’, of Germanic origin.
Interestingly enough, the origin appears to be more representative of problem solving than any of the new definitions that appeared in the online Oxford dictionary. The majority of the new definitions appear to miss the mark in problem-solving.
Take the Interrogative adverb, “Why did he do it?” This can easily be perceived as blame waiting for an excuse of why he did it. Once the problem solver gets the excuse, then the investigation is complete. Especially if you are interviewing the person involved in the problem.
Why as a noun, defined as a reason or explanation, is often inferred to mean this is why the person was supposed to follow the rules, but it does not allow or encourage the rule to be reevaluated if it does not work as intended or is just plain wrong.
The exclamation why is one we should all relate to, “I’ll keep asking why until you change your tune.”
As an effective problem solver, review the definitions of why listed above and ask yourself, “Am I using why in problem solving the way it was originated or not? Have I stopped at why when I should have gone further into true effective root causes?”
Finally ask yourself, “Have I made these mistakes asking why on moderate to high level problems?”
If the answer is “yes” to the questions above, stop asking why and join us in one of our upcoming TapRooT® root cause analysis courses.
Here is a video that discusses some root cause tips, common problems with root cause analysis, and how TapRooT® can help. I hope you enjoy!
Like what you see? Why not join us at the next course? You can see the schedule and enroll HERE
Happy Wednesday and welcome to this week’s root cause analysis tips column. This week we will talk about Causal Factors.
The TapRooT® Definition of a Causal Factor is:
“A mistake, error, or failure that directly leads to (or causes) an Incident or fails to mitigate the consequences of the original error.”
This definition is one major thing that distinguishes TapRooT® from some other methods. We don’t just find the first thing that went wrong, we find EVERTHING that went wrong. I’ve had people say to me that “but if I fix the first problem the incident would not have happened.” That is actually true, but if I only focus on the first thing that went wrong (which is sometimes the most obvious), then I do not address everything else that is wrong with my system. It also allows people to fall into the trap of determining “the causiest causal factor” and ignoring everything else.
Consider this diagram:
So when looking for Causal Factors, I find the first error/failure (initiating error), and they look for chances to stop/catch/mitigate. Each time I fail to stop/catch/mitigate, it is a new Causal Factor.
You will also notice that we could have an initiating error later in the timeline was well. It could be completely unrelated but allowed the hazard to reach the target.
Here is an example:
*Someone turns the wrong valve and allows a hazard (this is an initiating error).
*A second check of the valve configuration was not completed as required (a chance to stop/catch the first error).
*Someone lights a cigarette in an unauthorized area (another initiating error).
*Emergency response team did not arrive for 30 minutes (chance to mitigate the consequences).
Each one of these would be a Causal Factor.
Defining Causal Factors does not have to be difficult. The more you do it, the more comfortable you will be. I find that the concept of stop/catch/mitigate can really be helpful in making sure you find ALL the problems that led to an incident.
So thanks for visiting our blog. I hope you don’t have an incident anytime soon, but if you do, I hope you find the information helpful. If you’re interested in learning more about identifying causal factors and finding the root causes of incidents, register for our 2-Day TapRooT® Root Cause Analysis Training.
Our 2016 Global TapRooT® Summit was a great success this year! Our attendees helped one another by sharing some of their best practices. William McClung describes how they allow leadership to be a champion for their investigation.
(Click post title if video is not displaying.)
After Mark Paradies presented a talk on root cause analysis at the 2016 PDA/FDA Joint Regulatory Conference, a question was asked,
“How can we use TapRooT® Root Cause Analysis specifically to help solve “biological” driven problems that occur during biopharmaceutical product processing?”
The group had many general questions during his talk titled, “Identification of True Root Cause – and Impact to the Quality System,” and liked the points that he made. The question above however made me wonder why some industries or some industry-specific issues appear more complex than others when it comes to problem solving.
We use Safeguard Analysis to help identify the factor hazard/safeguards/target during our TapRooT® Root Cause Analysis. We look for errors of loss of control in these factors to find if these changes impacted the big problem that we are investigating. We also look for these changes formally by using a Change Analysis Table, taught in our 5-Day Courses. The linked Safeguard Analysis article above walks you through a near miss incident with a fast moving train and people. Once you identify your Hazards, your Targets, and any Safeguards we ask simple questions such as:
– was there an error that allowed a Hazard that shouldn’t have been there, or was larger than it should have been;
– was there an error that allowed a Safeguard to be missing;
– was there an error that allowed a Safeguard to fail;
– was there an error that allowed the Target to get too close to a Hazard; or
– was there an error that allowed the Incident to become worse after it occurred.
So here is the complexity question, what makes a near miss with a train incident different or a biopharmaceutical product processing near miss more complex to investigate than a train incident? Can we use the same root cause process for both types of problems?
Let’s walk through how we can turn the complex into the simple.
Simplifying the Issue:
In safety investigations, either the target got hurt or almost hurt. If the target got hurt, how badly?
In biopharmaceutical investigations, either it is a True Batch Failure, a False Batch Failure, a Safety Compromised or a Non-Standard Efficacy issue.
The similarity between seeming complex productions verses a train incident? Either a hazard got to the Batch (target) knowingly or unknowingly and was the loss of control caught in time?
The other questions would be….
1. How easy would it be to document the process of transactions that occurred during the Batch Process?
2. How easy would it be to identify the hazards of say…moisture, catalyst issues, enzyme or bacteria controls for the Batch Process? Simply, did they get the recipe right?
3. Finally, once identified, can the SME’s identify the error opportunities listed above?
If you are in the Biopharmaceutical Industry whether from the GCP or GMP side, give us a call or just sign up for a course and apply it.
When we first started the development of TapRooT® back in the 1980s, we developed this definition of a root cause:
The most basic cause (or causes)
that can reasonably be identified
that management has control to fix
and, when fixed, will prevent
(or significantly reduce the likelihood of)
the problem’s recurrence.
The modern definition of a root cause, which was proposed in 2006 by Mark Paradies at the Global TapRooT® Summit and really isn’t so new, is:
The absence of best practices
or the failure to apply knowledge
that would have prevented the problem.
This modern definition of a root cause leads to this definition of root cause analysis:
Root Cause Analysis
The search for the best practices
and/or the missing knowledge that
will keep a problem from recurring.
Since most people (including, in the past, me) say that root cause analysis is the search for why something failed, this reversal of thinking toward looking for how to make something succeed is truly a powerful way of thinking. The idea changes the concept of root cause analysis.
Even though a decade had passed since proposing this new definition, I still have people ask:
“Why did you change the definition? I liked it like it was!“
Therefore, I thought that with the new TapRooT® Books coming out, I would explain our reasoning to show the clear advantage of the modern definition.
The modern definition focuses on the positive. You will search for best practices and knowledge. You aren’t looking for people to blame or management faults. Yes, a best practice or knowledge is missing, but you are going to find out how to do the work more reliably. Thus, the focus is on improvement … the opportunity to improve vision!
The same thing can be said about the old fashioned definition too. But the old definition focused on cause. The difference in the definitions is a matter of perspective. Looking up at the Empire State Building from the bottom is one perspective. Looking down the Empire State Building from the top is quite another. The old definition looked at the glass as half empty. The new definition looks at the glass as half full. The old definition focuses on the “cause.” The modern definition focuses on the solution.
This shift in thinking leads people to a better understanding of root causes and how to find them. When it is combined with the Root Cause Tree® and Dictionary, the thinking revolutionizes the search for improved performance.
The concept of looking for ways to improve has always been a part of the TapRooT® System. It is the secret that makes TapRooT® such a powerful tool. But the modern definition – the new perspective – makes it easier to explain to others why TapRooT® works so well. TapRooT® is a tool that finds the missing knowledge or best practices that are needed to solve the toughest problems.
One last note about the modern definition: In the real world, absolutes like “will prevent” can seldom be guaranteed. So the root cause definition should probably be augmented with the additional phrase: “or significantly reduce the likelihood of the problem’s recurrence.” We chose not to add this phrase in the definition to keep the message about the new focus as strong as possible. But please be aware that we understand the limits of technology to guarantee absolutes and the ingenuity of people to find ways to cause errors even in well-designed systems.
That’s the reasons for the definition change. You may agree or disagree, but what everyone finds as true is that TapRooT® helps you find and fix the root causes of problems to improve safety, quality, productivity, and equipment reliability.
Attend a TapRooT® Course and find out how TapRooT® can help your company improve performance.
Our 2016 Global TapRooT® Summit was a great success this year! Our attendees helped one another by sharing some of their best practices. Here Rajesh Malik talks about how his company encourages students to go back and apply what they learned in the TapRooT® course to their previous investigations.
(Click post title if video is not displaying.)
If you don’t understand what happened, you will never understand why it happened.
You would think this is just common sense. But if it is, why would an industry allow a culture to exist that promotes blame and makes finding and fixing the root causes of accidents/incidents almost impossible?
I see the blame culture in many industries around the world. Here is an example from a hospital in the UK. This is an extreme example but I’ve seen the blame culture make root cause analysis difficult in many hospitals in many countries.
Dr. David Sellu (let’s just call him Dr. Death as they did in the UK tabloids), was prosecuted for errors and delays that killed a patient. He ended up serving 16 months in high security prisons because the prosecution alleged that his “laid back attitude” had caused delays in treatment that led to the patient’s death. However, the hospital had done a “secret” root cause analysis that showed that systemic problems (not the doctor) had led to the delays. A press investigation by the Daily Mail eventually unearthed the report that had been kept hidden. This press reports eventually led to the doctor’s release but not until he had served prison time and had his reputation completely trashed.
If you were a doctor or a nurse in England, would you freely cooperate with an investigation of a patient death? When you know that any perceived mistake might lead to jail? When problems that are identified with the system might be hidden (to avoid blame to the institution)? When your whole life and career is in jeopardy? When your freedom is on the line because you may be under criminal investigation?
This is an extreme example. But there are other examples of nurses, doctors, and pharmacists being prosecuted for simple errors that were caused by systemic problems that were beyond their control and were not thoroughly investigated. I know of some in the USA.
The blame culture causes performance improvement to grind to a halt when people don’t fully cooperate with initiatives to learn from mistakes.
TapRooT® Root Cause Analysis can help investigations move beyond blame by clearly showing the systemic problems that can be fixed and prevent (or at least greatly reduce) future repeat accidents.Attend a TapRooT® Root Cause Analysis Course and find out how you can use TapRooT® to help you change a blame culture into a culture of performance improvement.
Foe course information and course dates, see:
A poorly written procedure can lead to unsafe work, reduced productivity, and organizational failures. A few tips can help you avoid these pitfalls. Procedures are action-oriented. They outline steps to take, and the order in which to take them. They are instructional, and may be used in training and orientation. Well-written procedures are solid, precise, factual, short, and to the point.
Here are five tips for writing better procedures:
- Avoid phrases like “as necessary,” “as applicable,” or “may include” because phrases like these are confusing. When would it be necessary? When is it applicable? When may it include something? Be clear, specific, and to the point.
- Be consistent with terminology. Clarify terminology for those who may not be familiar with it and use the same terminology in each step.
- Add visual aids like images, diagrams, or sketches to facilitate understanding of the process.
- Organize long procedures into sections. List less than ten steps per section. People lose focus when presented with a procedure with too many steps.
- Avoid using pronouns. Poor: “Turn it to the left.” Good: “Turn Lever A3 to the left.”
One reference that we recommend in the TapRooT® Corrective Action Helper® Guide is Procedure Writing: Principles and Practices, (1999) by Douglas Wieringa, Christopher Moore, and Valerie Barnes, published by Battelle Press, Columbus, Ohio.
Learn more in our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training (Click here to view course list).
Our 2016 Global TapRooT® Summit was a great success this year! Our attendees helped one another by sharing some of their best practices. Here Michael Miraglia details how his company creates what they call a “review cell” to investigate an incident.
(Click post title if video is not displaying.)
Happy Wednesday and welcome to this week’s Root Cause Analysis Tips. The topic this week is strength of safeguards.
We teach a lot of great stuff in our TapRooT® courses. In fact, our 5-day course is over 400 slides. In my opinion, this concept is the most important, and this is my favorite slide:
The diagram shows that the best corrective action is to remove the hazard; if we cannot do that, maybe we can reduce it (chemical substitution, for example).
If we can’t do a #1, possibly we can move the target away from the hazard (moving a desk in the warehouse away from forklift traffic, for example).
We keep moving down the list from strongest to weakest. But we start at the top.
So here is my question: If I were to pull out of random stack of investigations from any company, anywhere, what kind of corrective actions do you think I would see? What about your company? If you said 5’s and 6’s, you now know the reason that you have repeat incidents.
Please do not misunderstand me; I am not saying training and supervision are not needed, what I am saying is they are weaker safeguards. They can be good corrective actions and sometimes are the only ones feasible, but we should always start at the top of the matrix and work our way down.
In my last column I talked about layers of protection. Pretty simple, more layers means more protection. However, since all Safeguards are not equal, many layers of weak safeguards does not equal a few layers of strong ones.
If you just did this one thing in your company, I am confident that you would improve a great deal. Remember, corrective actions are the output of your investigation. You can do a great job on the investigation, but if you have weak corrective actions, you are WASTING YOUR TIME.
So please think about it. Thanks for visiting the blog, and enjoy your week.
Beginning your investigation can sometimes be quite a challenge. Deciding on who to talk to, what documents you need, what questions you need to ask, etc. can lead to feeling slightly overwhelmed. As General Creighton Abrams said,
When eating an elephant, take one bite at a time.
In other words, you just need to get started with the first step, and then methodically work your way through to the end.
In TapRooT®, that first bite is the SnapCharT®. The rest of your investigation is going to depend on the data you gather in that SnapCharT®, so it is critical that you begin in a simple, methodical manner.
Let’s say you get that initial notification phone call (usually at 3:00 am). You don’t get much information. Maybe all you know is, “Ken, we had a pipe rupture this morning during a hydrostatic test. Looks like the mechanics didn’t know what they were doing. They had hooked up a test pump to the piping, started the pump, and almost immediately ruptured the piping. We’ve cleaned up the water, and no one was hurt. We need you to investigate this.” This is a pretty common initial report. Not a lot of data, some opinions thrown in, and a request for answers. Without a structured process, most investigations would now start off with some interviews, asking pretty generic questions. It would be really nice if we could start off with some detailed, intelligent questions.
This is where the SnapCharT® comes in. Once you receive that initial phone call, just build your SnapCharT® with the information you have. It honestly won’t have much data, but that’s OK; it’s only your starting point:
However, with this initial SnapCharT®, it is now easier to visualize what you already know, and what you still need to know. For example, I’d have a lot of questions about the pump, the mechanics themselves, recovery actions, etc. I’d use the Root Cause Tree® to help me figure out what questions to ask. I’d take each Event and ask, “What do I already know about this Event, and what questions do I have about it?” These would all be added to the SnapCharT®. It might look more like this:
Keep in mind that these questions were developed before I even went to the scene or questioned anybody about the facts. I still need to interview people, but I now have a much better set of questions to begin my investigations. Many more questions will arise as I ask this initial set of questions, but I’ll feel much better prepared to start talking to people about the issue.
The SnapCharT® is a simple yet effective tool to help the investigator get started with the investigation. It may seem like an inconsequential step, easy to dismiss. However, using the SnapCharT® as your very first tool, before you start gathering data, can greatly speed up the investigation. It allows you to start on the right path, with a set of intelligent questions to ask. Once you have this moving, you’ll find the rest of the investigation falls into place in a logical, easy to follow format. ALWAYS START WITH A SNAPCHART®!
LEARN MORE about TapRooT® essentials in our 2-day course (View schedule and register!)
Above is the start of an OSHA/EPA Fact Sheet titled: “The Importance of Root Cause Analysis During Incident Investigation.”
OSHA and EPA want companies to go beyond fixing immediate cause (which may eliminate a symptom of a problem) and instead, find and fix the root causes of the problems (the systemic/underlying causes). This is especially important for process safety incidents.
The fact Sheet explains some of the basic of root cause analysis and suggests several tools for root cause analysis.
UNFORTUNATELY, many of the tools suggested by the fact sheet are not really suited to finding and fixing the real root causes of process safety incidents. They don’t help the investigator (or the investigative team) go beyond their current knowledge. Thus, the suggested techniques produce the same ineffective investigations that we have all seen before.
Would you like to learn more about advanced root cause analysis that will help your investigators learn to go beyond their current investigative methods and beyond their current knowledge to discover the real root causes of equipment reliability and human performance related incidents? These are techniques that have been proven to be effective by leading companies around the world.
Yes? Then see: http://www.taproot.com/products-services/about-taproot
And choose one of our upcoming public TapRooT® Courses to learn more about the TapRooT® Root Cause Analysis System. See: