Category: Root Cause Analysis Tips
“Don’t collect evidence by accident!”
A phrase that I repeat often while teaching our TapRooT® Root Cause Analysis Method, along with…
Go Out And Look (GOAL)
I know, the phrases above may look like another safety/quality slogan of the day but are they? Maybe they should be the simplest guidance to increase the probability of not losing relative facts after an industrial injury, facility/property damage, environmental release, product defect, customer complaint or near miss/hit to any of the above.
Here is a list of issues that occur by not following the concise instructions above:
- Lost/Missing evidence
- Evidence spoliation (whether intended or not)
- Guessing driven by assumptions tied to past problems
- Regulatory Write Up for delayed incident reporting (extent and magnitude of problem not understand in time by not Going Out And Looking)
Why would any established industry, often overseen by a regulatory agency, have to worry about collecting evidence by accident or GOAL? Don’t many companies have procedures and work instructions on how to manage an industrial accident or regulatory write up? The latter question is where the problem resides. Actually, it starts before a major incident occurs.
Companies are good in many cases at handling major accidents and their evidence collection. What often drives what gets looked at is the company’s Incident Matrix. The matrix in many cases stops employees from Going Out And Looking and encourages last minute evidence collection by accident. Below is a typical matrix.
If the employee has “7 days?” or “as soon as practical”, what does that do to evidence collection delays or GOAL? What does that do to how the employee collects evidence and how the root cause analysis is performed? If the “big problems” have an investigation protocol, do the employees use the same protocol for the unsafe practice issues?
The process you create to manage investigation resources can hurt if not managed correctly.
For more thoughts on collecting evidence and the impact to the business based on your company’s own protocols, read the following….
How many companies are using TapRooT® for their “hard,” “high-risk” incident analyses and using something like 5-Whys for the “simple” stuff? Yep, I thought so. A lot of companies are doing this for various reasons. I’ll get into that more in a minute.
Now, another poll:
How many of you are performing effective root cause analyses on your “important,” “high-consequence” investigations, and performing nearly useless analyses on the “easy” stuff? Of course, you know this is really exactly the same question, but you’re not as comfortable raising your hand the second time, are you?
Those of you that follow this blog have already read why using inferior RCA methods don’t work well, but let me recap. I’m going to talk about 5-Whys specifically, but you can probably insert any of your other, less-robust analysis techniques here:
- It does not use an expert system. It relies on the investigator to know what questions to ask.
- Because of this, it allows for investigator bias. If you are a training person, you will (amazingly enough) end up with “training” root causes.
- The process does not rely on human performance expertise. Again, it relies on the skill of the investigator. Yes, I know, we’re all EXCELLENT investigators!
- It does not produce consistent results. If I give the same investigation to 3 different teams, I always get 3 different sets of answers.
- There is no assistance in developing effective corrective action. When 80% of your corrective actions fall into the “Training” “Procedures” and “Discipline” categories, you are not really expecting any new results, are you?
So, knowing this to be true, why are we doing this? Why are we allowing ourselves to knowingly get poor results?
- These are low risk problems, anyway. It doesn’t matter if we get good answers (Why bother, then?)
- It’s quick. (Of course, quickly getting poor results just doesn’t seem to be an effective use of your time.)
- It’s easy (to get poor results).
- TapRooT® takes too long. Finally, an answer that, while not true, at least makes sense.
So what you’re really telling me is that if TapRooT® were just easier to use, you would be able to ditch those other less robust methods, and use TapRooT® for the “easy” stuff, too.
Guess what? We’ve now made TapRooT® even easier to use! The 7-step TapRooT® process can now be shortened for those “easy” investigations, and still get the excellent results you’re used to getting.
We now teach the normal 7-Step method for major incidents, where you need the optional data-collection tools. However, we are now showing you how to use TapRooT® in low to medium-risk investigations. You are still using the tools that make TapRooT® a great root cause analysis tool. However, we show you how to shorten the time it takes to perform these less-complex analyses.
The 2-Day TapRooT® Incident Investigation Course concentrates on these low to medium-risk investigations. The 5-Day TapRooT® Advanced Team Leader Course teaches both the simple method, but also teaches the full suite of TapRooT® tools.
Don’t settle for poor investigations, knowing the results are not what you need. Take a look at the new TapRooT® courses and see how to use the system for all of your investigations. You can register for one of these courses here.
Our 2016 Global TapRooT® Summit was a great success last year! Our attendees helped one another by sharing some of their best practices. Here Tim Dearman informs the audience how his company keeps subject matter experts in each of their key business units to help during investigations.
(Click post title if the video is not displaying.)
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 firstname.lastname@example.org 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.)