Author Archives: Chris Vallee

Root Cause Tip Warning: Do not define the impact level of your incident too low or too high

Posted: October 19th, 2017 in Investigations, Root Cause Analysis Tips

 

When defining the Incident during a TapRooT® Root Cause Analysis and its impact to the business (the scope of your investigation), I often hear this statement…

“If we focus on the delay of correcting the problem, then less importance will be placed on what caused the problem.”

Take the scenario of a fire pump failing to turn on during a fire response test. The team originally wanted to focus on the pump failure only. Not a bad idea however, the pump could not be repaired for 2 weeks because of a spare part shortage. I pushed the team to raise the scope and impact of the investigation to Automatic Fire Suppression System out of service for 14 days.

Now this elevation of the incident does not lessen the focus on the pump failure, it does the opposite. A system down for 2 weeks elevates the focus on the pump failure because of impact and also allows the team to analyze why we did not have access to spare pump in a timely manner.

A caution also must be mentioned in that elevating the impact of an incident too high can cause a regulating agency to get involved or/and additional resources to be spent when not required.

Which problem is worse? Elevating a problem too high or not high enough? Your thoughts?

Root Cause Tip: Are you stopping short of exploring Human Engineering on the TapRooT® Root Cause Tree®?

Posted: September 14th, 2017 in Root Cause Analysis Tips

 

When analyzing a Causal Factor for Human Performance Difficulty during a root cause analysis investigation, a few questions under the Individual Performance section of the TapRooT® Root Cause Tree® will guide you to the basic cause category of Human Engineering. Hint: It would be great to have your Root Cause Tree® and Root Cause Tree® Dictionary handy for this discussion but it is not mandatory for learning to occur from this article.

Question 1: This question focuses on factors that can reduce human reliability and cause human errors. (Fitness of Worker performing a task)

Question 4: This question focuses on the human-machine interface that was needed to recognize conditions or problems and understand what was occurring. (Machine readouts and display feedback provided while performing a task)

Question 5: This question covers actual task performance. (Interaction while operating the equipment while performing a task)

Question 7: This question focuses on environmental factors that can degrade human performance. (Environment factors where the task is being performed)

Question 8: This question focuses on the ergonomics of the task performance. (Acute or repetitive issues and the physical impact on the person performing a task)

By now you should notice two key factors that must be identified before you can go any further in the root cause analysis of a particular Causal Factor for Human Engineering:

1. Who is the person that needed to perform the task successfully?

2. What is the task that needed to be performed successfully?

No shortcuts allowed in our TapRooT® process for these two factors. Doing so will prematurely cancel out your opportunity to explore Human Engineering in more investigative detail.

A third factor not listed yet is that you must Go Out And Look (GOAL) at where the task is being performed for questions 4, 5, 7 and 8. You cannot and should not answer the additional questions needed to evaluate the task from your desk. If you cannot get to the site and must ask the questions remotely, a person must be onsite to be your ears and eyes to GOAL.

A task can defined as an activity or piece of work which a person(s) must perform to accomplish with a successful end result. It can be a one action task or a sequence of actions to accomplish a system response. Examples….

• Press brake pedal with right foot to slow down car that you are driving
• Type words that create a sentence for others to read and comprehend
• Calculate launch equations that then get input into a computer that then guides a space capsule launch


br>

What would it take for a person to press a pedal with their right foot to slow down a vehicle?

• A pedal that can be reached and depressed
• A pedal that works as designed for the task
• Feedback from the car and environment to indicate that the car is slowing down at the right rate
• A person that can react in time with the right knowledge and ability to perform the slowing down task

How hard would it be to answer these questions from your desk with a reasonable amount of accuracy? Difficult at best, so don’t stop yourself from exploring Human Engineering because you did not identify the task, the equipment and the person.

Learn more about Human Engineering and TapRooT® tools like the TapRooT® Root Cause Tree in one of our upcoming 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Trainings:

October 2: Knoxville, Tennessee

October 16: Orlando, Florida

October 23: Bogota, Colombia (Spanish)

October 30: Reykjavik, Iceland

November 13: Brisbane, Australia

November 13: New Orleans

November 27: Johannesburg, South Africa

November 27: Monterrey, Mexico

November 27: Perth, Australia

Root Cause Tip: Equipment difficulty… did the equipment break or wear out?

Posted: August 28th, 2017 in Equipment/Equifactor®, Root Cause Analysis Tips

Teaching TapRooT® Root Cause Analysis and Equifactor® for the last 10 years, I often get this question…

“The tool/component broke while we were using it. Why can’t we just select Equipment Difficulty on the TapRooT® Root Cause Tree®?”

Simple, you have to pass the test below first

NOTE: If the failure was caused by:

  – improper operation;

  – improper maintenance;

  – installation errors;

  – failure to perform scheduled preventive maintenance;

  – programming errors;

  – use for a purpose far beyond the intention of the design; or

  – a design that causes a human performance difficulty

then the failure is NOT an Equipment Difficulty, but rather the failure is a Human Performance Difficulty

Trust me! If a tool, piece of equipment or product breaks, you know the manufacturer, vendor and supplier are going to push back to see if it was used properly and meets the warranty. Shouldn’t you ask first? We say yes!

During my 18 years in aviation in fuel systems troubleshooting and executive jet assembly, we used to have a phrase…

“Our mechanics or assemblers that grew up on the farm are our best and worst mechanics. They can get anything mechanical to work.”

Now there are signs that tools might not be the right ones for the job or that the job was not designed with good Human Engineering in mind. First test… look into the toolboxes in the field.

✔Are the tools modified
✔Are the tools old and worn
✔Are there tools from home

Okay, so tools are easier to see being misused, like a screw driver being used as a scraper or a pry bar, but what about equipment/components being used like a…

✔ Compressor
✔ Switch
✔ Valve
✔ Bottle

Now we must dig a little deeper in our TapRooT® Root Cause and Equifactor® Analysis. We start by mapping out our SnapCharT® (Sequence of Events with supporting Conditions) using system schematics to ensure we know what occurred with the equipment, people and system being operated. A knowledgeable system operator can elaborate on events and conditions such as:

✔ Energized open, mechanically closed
✔ Dynamic or static energy
✔ System work arounds and deficiencies

Why you may ask is this knowledge vital? If an operator knows how the light turns on when you flip a light switch on, then when system does fail, it is easier to start and understand the SnapCharT®.

To pass the first two tests while facilitating TapRooT® Root Cause Analysis, whether for a low to moderate level issue or a major incident, bring along that knowledgeable operator or engineer that can answer the following…

improper operation;
improper maintenance;
installation errors;
failure to perform scheduled preventive maintenance;
programming errors;
use for a purpose far beyond the intention of the design; or
a design that causes a human performance difficulty

Good luck and be safe! Please get rid of those unsafe tools and processes.

LEARN MORE in our 2-day TapRooT® Root Cause Analysis Training.

Company Culture Root Cause Tip: Trust Me the Foreman Said…

Posted: July 28th, 2017 in Root Cause Analysis Tips

No matter what industry that you work in, if you or your peers can say, “it’s common for management to argue or ‘explain away’ my concerns when you say this is unsafe…”

STOP!

If you do not stop, you will get to explore a root cause from the TapRooT® Root Cause Tree. The root cause will be Employee Feedback Needs Improvement. Unfortunately, it will also be associated with a causal factor that caused an incident, failed to stop an incident or made an incident worse when it occurred. Don’t forget, You are just one Causal Factor from your next major Incident. Can you prevent it?

During the root cause analysis, not only will you be exploring the culture of the company that allowed this failure not to stop, but you also will get the opportunity to understand what was broke.

Please be aware, that in this article and the included article links, I have only touched just the tip of each subject and introduced a very tiny part of our root cause analysis process. It is hoped that you leave with something you can use today and pay it forward. But also help you realize that there are numerous issues that must be addressed following an incident or before one occurs. We help you get there.

If you don’t want to have to read between three or four articles to do to an investigation, come to one of our public TapRooT® Courses or contact us for an onsite course. Why? Simple, each course provides Using the Essential TapRooT® Techniques to Investigate Low-to-Medium Risk Incidents, Course Workbook, the complete Root Cause Tree®, Root Cause Tree® Dictionary, and Corrective Action Helper®.

Root Cause Tip: Accountability NI

Posted: June 23rd, 2017 in Root Cause Analysis Tips

Growing up as a child, it was common to hear and sometimes say, “You’re not the boss of me!”

There always seemed to be some challenges to parents, teachers and friends, as we started to develop our independence. Somewhere through this journey of life however, we soon started to hear our peers and some cases out of our own mouths…

In other words, “I’m not in charge” and “I’m not the boss.”
Many people started wanting to give up responsibility as they get more responsibility.

  • I’m not the boss
  • I don’t get paid enough to make the decision
  • It’s their equipment, they should know how to operate it safely
  • That’s outside my job description

The issue of not really knowing who is in charge is commonplace in many of the incidents that I have reviewed. In TapRooT® Root Cause Analysis, we define accountability as ensuring that the person who is in charge of the working being done knows he/she is in charge and coworkers/management know that person is in charge. When many different companies with different functional roles work together, the more susceptible the work being performed is to the root cause of Accountability Needs Improvement.

Take the following work environments and think about what issues have or could arise…

Operation Room: Company A Surgeon, Company B Anesthesiologist, Local Hospital RN Nurses, Company C X-Ray Technician…

Deepwater Ocean Rig: Company A Operator, Company B Owner, Company C System Vendor Technician…

Construction Site: Company A Crane Operator, Company B Crane Rental Mechanic, Company C Labor, Property Owner, Company D Project Planner…

Here are a few best practices to help when performing the actual work:

1. At the beginning of each job, people introduce themselves and their role during the work to be performed that day. This gives each person a voice and role.

2. Client supervisors that must perform Tailboard and JSA meetings at the beginning of each job should familiarize themselves with the energy and line of fire danger areas for all equipment on site. Even if it is equipment used by contractors. The contractor also has a role to educate the client and other contractors in the area.

3. All people performing the task should discuss possible issues that may occur and what would require work stop and actions to follow when possible. Learn more about this concept of Crew Resource Management in our 5-Day Team Leader Course.

Remember, we all have a role to perform during a task. If roles are not defined and there is no clear sign of true accountability, that task may not get done, get done incorrectly and there will be no one with the right knowledge to stop the work when issues occur.

Root Cause Tip: Anyone Can Do The Job! Or Can They?

Posted: June 9th, 2017 in Root Cause Analysis Tips

Caution

Training Corrective Actions will not fix everything but when it does make sure you do it right.

When we analyze an action or inaction that caused a problem, failed to catch/stop the problem that was occurring or caused the problem to get worse after it occurred, the TapRooT® Root Cause Process has us ask questions focusing “on the knowledge, skills, and abilities of the person performing the task?” If we say “yes” to any of the questions, the process then asks, “Should the person have had better training to understand the task, develop the skill needed, or maintain the knowledge and skills needed to successfully complete the task?”

Warning

Please don’t cheat the TapRooT® Root Cause Process by answering the above questions without full understanding of the person or task.

The key to fully understanding the issue of training is to identify the task first. Next you must identify the knowledge, skills and abilities needed to perform the task. Easier said than done if you have never truly looked at a task in this manner.

Task – A task can be one action or a sequence of actions that a person must successfully complete in order to produce a required output.

Knowledge is the theoretical or practical understanding of a subject. You can read a book on how to drive a car, but that in itself doesn’t equate to having the skill or ability to drive a car. You need to have the knowledge, however, to build your skills on. Sometimes you have to perform a new task with no experience and just basic knowledge. You are taught to turn into a skid while driving but have you ever done it?

Skills are the proficiencies developed through training or experience. Skills must be learned, by experience or through formal training. You practice driving a car under supervision, get licensed and then continue improving your skills over time. When you hire someone to drive a car, how do you know he/she can? Do you test them or just depend on a license requirement? 

Abilities are the qualities of being able to do something. There is a fine line between skills and abilities. Skills require certain physical abilities or mental abilities. For example, depth perception is a must to drive safely in certain situations. You need the ability to add, divide and multiply to properly calculate how much gas is needed for a cross country trip. Do you assess for physical and mental task capabilities for particular positions for certain critical tasks?

Here is a challenge to our TapRooT® Root Cause Blog Readers….

  1. Identify one task that you perform daily and list the steps.
  1. Identify and write down the Knowledge, Skills and Abilities that you must have and use to perform the task.

For a great example of core tasks and skills needed, go to this CFETP link for my old aircraft job.

It takes a little more work to assess the true need for training than most people imagine. Remember this blog challenge when you do your next problem analysis.

This article gave the blog reader a little knowledge for the task of analyzing a task and a possible training issues tied to training. To get hands on training and application to build your skills, attend our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training Course to learn more about ADDIE, CHAP (Critical Human Action Profile) and errors made due to knowledge, skill or ability deficiencies. Plus learn how to correct and prevent these type of issues.

Abilities Required to attend the course: reading, writing and a passion to make the world around you better and safer.

Root Cause Tip: “Enforcement Needs Improvement” – You Can’t Train Obedience/Compliance/Positive Behavior

Posted: May 26th, 2017 in Human Performance, Performance Improvement, Root Cause Analysis Tips, Root Causes

This is a quick clarification to stop a definite no-no in poorly developed corrective actions.

You find evidence during your root cause analysis to support the root cause “Enforcement NI” based on the following statements from your Root Cause Tree® Dictionary for a particular causal factor:

  • Was enforcement of the SPAC (Standards, Policies, Administrative Controls) seen as inconsistent by the employees?
  • Has failure to follow SPAC in the past gone uncorrected or unpunished?
  • Did management fail to provide positive incentives for people to follow the SPAC?
  • Was there a reward for NOT following the SPAC (for example: saving time, avoiding discomfort).
  • When supervisors or management noticed problems with worker behavior, did they fail to coach workers and thereby leave problems similar to this causal factor uncorrected?

But then if you create a corrective action to retrain, remind, and reemphasize the rules, directed at the employee or in rare occasions the immediate supervisor, your investigation started on track and jumped tracks at the end.

Now, I am okay with an alert going out to the field for critical to safety or operation issues as a key care about reminder, but that does not fix the issues identified with the evidence above. If you use Train/Re-Train as a corrective action, then you imply that the person must not have known how to perform the job in the first place. If that were the case, root causes under the Basic Cause Category of “Training” should have been selected.

Training covers the person’s knowledge, skills and abilities to perform a specific task safely and successfully. Training does not ensure sustainment of proper actions to perform the task; supervision acknowledgement, reward and discipline from supervision, senior leadership and peers ensure acceptance and sustainment for correct task behaviors.

Don’t forget, it is just as easy for supervision to ignore unsafe behavior as it is for an employee to deviate from a task (assuming the task was doable in the first place). Reward and discipline applies to changing supervision’s behavior as well.

Something else to evaluate. If the root cause of Enforcement NI shows up frequently, make sure that you are not closing the door prematurely on the Root Cause Tree® Dictionary Near Root Causes of:

  • Oversight/Employee Relations (Audits should be catching this and the company culture should be evaluated).
  • Corrective Actions (If you tried to fix this issue before, why did it fail?).

Remember, you can’t train obedience/compliance/positive behavior. Finally, if you get stuck on developing a corrective active for Enforcement NI or any of our root causes, stop and read your Corrective Action Helper®.  

Learn more by attending one of our upcoming TapRooT® Courses or just call 865.539.2139 and ask a question if you get stuck after being trained.

Investigate Near Misses with TapRooT® Root Cause Analysis

Posted: April 2nd, 2017 in Root Cause Analysis Tips

Picture.1
 

I think that TapRooT® Root Cause Analysis might be one of best way to investigate near misses, right?

I received this question from one my students who has continued to stay engaged to keep his company running safe and efficient by applying his TapRooT® Root Cause Analysis Training every day.

As you know, we are able to prevent real incidents by investigating near misses.

 I think that TapRooT® RCA might be one of best ways to investigate near misses, right? Would you advise me how to use TapRooT RCA to investigate near misses and give me some examples of near miss investigations done with TapRooT® RCA?

 Any comments or advice would be highly appreciated.

Think about it, in most near misses, you are just One Causal Factor from your next major Incident. The Causal Factors found during the investigation are usually not a surprise or the first time that they have occurred at that site or in the company.

The only difference between an incident and a near miss incident root cause analysis is what goes in the circle on the SnapCharT® (sequence of events chart).  For example,

Picture.2

Vital to ensure success with a new near miss program implementation, is not to try to investigate all audit findings or catches. You do not have enough resources. Instead start with the high potentials for incidents only.

Wait, why did I just include audit findings? Simple, audits are more than looks for compliance. Processes are put in place to reduce or eliminate hazards (energy), isolate targets from hazards or to ensure responses to hazard and target contact do not make the incident worse. An audit is often the first documented point in time to identify a high potential near miss. Check out our new audit course with root cause analysis to improve your audit capability.

Just like I stated above concerning near misses, all audit findings may not need a root cause analysis, but audit findings with high potentials do.

If your company does not have a High Potential for Injury/Incident/Process Shutdown Program in place today, you will need to do some homework. Here are some simple steps to get started.

  1. Identify Tasks performed by your employees, contractors, vendors or suppliers, that if done incorrectly could cause Injury/Incident/Process Shutdown. For a jump start, review the following videos for Serious Injuries & Fatalities. For quality defects and process failures take a look at hierarchy of controls for defects.
  2. Once the potential tasks are identified, develop a triggering process that alerts the need for a root cause analysis.

Second homework item, if not trained in TapRooT® Root Cause Analysis, go to course close to you now.

If in Europe, check out our 5-Day TapRooT® Root Cause Analysis Course in Aberdeen, Scotland – May 22.

If in North America, checkout our 2-Day TapRooT® for Audits Charlotte, NC May 4, 2017 or our 5-Day TapRooT® Galveston, TX May 15, 2017.

Our complete course schedule can be found here.

Evidence Collection and Root Cause Analysis by Accident? On your mark, get set… STOP!!

Posted: March 8th, 2017 in Root Cause Analysis Tips

Now What
 

“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.

Vallee

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….

New TapRooT® Essentials Book is Perfect for Low-to-Medium Risk Incident Investigations

You are just one Causal Factor from your next major Incident. Can you prevent it?

How Fast Can You Do A Root Cause Analysis (1 hour, 1 day, 1 week, 1 month)?

Top 3 Reasons for Bad Root Cause Analysis and How You Can Overcome Them…

3 Reasons a SnapCharT® is Essential to Evidence Collection

Starting Your Investigations: The Power of the SnapCharT®

Identify where a defect occurred… or when it became apparent?

Posted: February 20th, 2017 in Root Cause Analysis Tips

Vallee Tip
 

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.”

Spin Master

Which stakeholder was impacted the most in the defective product issue above?

  1. The child?
  2. The gift purchaser?
  3. The distributor, like Amazon?
  4. 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?”

For example:

  • 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:

  1. Company reputation
  2. Safety to customer
  3. Less delay between defect occurrence and relative evidence
  4. The ability to stop the production process immediately

Cons to having the customer report the defect:

  1. Magnitude of impact to safety and customer business can be greater
  2. Product fixes are closer to triage and damage control repairs as opposed to identification of root causes
  3. Degraded company reputation
  4. Harder to collect how the customer used the product in the field
  5. Takes more company resources to investigate the problem
  6. 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:

  1. Identify defect opportunities critical to customer success.
  2. Mistake-Proof for the critical opportunities when possible.
  3. Develop visible triggers and indicators at time of occurrence for defects that cannot be prevented 100 percent.
  4. Track and Trend types of defects, defect occurrence locations, gap between time of occurrence, time of identification and time to complete the corrective action.
  5. 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.

Why would you reject a root cause analysis report?

Posted: February 2nd, 2017 in Root Cause Analysis Tips

Count of RCA Report Defects
 

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.

 

You followed your procedure as written, but still made a defect!

Posted: December 28th, 2016 in Root Cause Analysis Tips


Quality Contnrol

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.

Why Stop at Why in Effective Root Cause Analysis?

Posted: December 14th, 2016 in Root Cause Analysis Tips

Why
 

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:

A Look at 3 Popular Quick Idea Based Root Cause Analysis Techniques: 5-Whys, Fishbone Diagrams and Brainstorming or

What, Why and then Fix… There is No Other Sequence for Root Cause Analysis.

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!

why

/(h)wī/

Exclamation

Expressing surprise or indignation: Why, that’s absurd!

Used to add emphasis to a response: You think so?  Why, yes.

Interrogative adverb

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?

Relative Adverb

(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.

Noun

– A reason or explanation: The whys and wherefores of these procedures need to be explained to students.

Origin

– 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.

Using TapRooT® Safeguard Analysis to Investigate Biopharmaceutical Defects

Posted: November 29th, 2016 in Root Cause Analysis Tips

safeguards

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.

You are just one Causal Factor from your next major Incident. Can you prevent it?

Posted: July 5th, 2016 in Accidents, Root Cause Analysis Tips, Root Causes, Summit

comic

Words that I hate to hear when asked to help with an investigation: “I am surprised this incident did not happen earlier!” Rarely have I seen an incident where there is not a history of the same problems occurring.  Think of it like a math equation:

X + Y (A) = The Incident

A company’s issues are just waiting for the right math equation to occur at the right time. What are some of the common factors that populate the equation above?

  • Audit Findings (risk or compliance)
  • Near Misses (or some cases, Near Hits)
  • OSHA Non-Recordable(s)
  • Defects (caught before the defect reached the customer)
  • Project Delays
  • Procurement Issues
  • Behavior Based Safety Entries

This list of variables is infinite and dependent on the industry and service or product that your company provides. Should you be required to perform a full root cause analysis on each and every write-up or issue listed above to prevent an Incident? Not, necessarily.

Instead, I recommend that you start looking at what would be a risk to employees, customers, environment, product/service or future company success if you combined any of your issues in the same timeline or process of transactions (in TapRooT® our timeline is called a SnapCharT®). For example, take the 3 issues listed below that have a higher potential of incident occurrence when combined in the right equation.

Issue 1: Audit finding for outdated procedures found in a laboratory for testing blood samples.

Issue 2: Behavior Based Safety Write-up entered for cracked and faded face shields

Issue 3: Older Blood Analyzer has open equipment work orders for service issues.

Combining the 3 items above could cause a contaminated blood sample, exposure of contaminated blood to the lab worker or a failed test sample to the patient.

If the cautions about your future combination of known issues are not heeded then please do not acted surprised after the future Incident occurs.

Want to learn about causal factors? It’s not too late to sign up for our Advanced Causal Factor Development Course, August 1-2, 2016, San Antonio, Texas.

Root Cause Analysis is not about Root Causes

Posted: June 15th, 2016 in Root Cause Analysis Tips

Stressed

I must be crazy, I teach TapRooT® Root Cause Analysis and say it’s not about the root causes? Yes, it is true. Root Cause Analysis is really about fixing, prevention and improved ability to recover from a problem.

Yes, an objective root cause process is a must, for hints read the 7 Secrets of Root Cause Analysis. However the reason behind the need for and the end intent of the root cause analysis is just as important. Lets start with a new idea for many doing root cause analyses today, “improved ability to recover from a problem.”

ohno

Sometimes the first action to correct a problem on the spot was like pouring water on an oil fire. Didn’t cause the fire but sure did not help the situation, and in some cases it really made the problem. Many problem solvers just look for the root causes that caused a problem and not what also made it worse.

Here are just a few examples of actions or lack of actions that made the initial problem grow larger in extent if not worse at the end of the day:

  1. Flint River Lead Exposure Delayed Response
  2. Firestone Tire Delayed Recall
  3. 1947 Explosion Caused by Incorrect Response to Initial Fire
  4. A case closer to this article writer’s life when the wrong medicine was given for heart failure of loved one: Root Cause Analysis Tip: Patient’s heart stopped twice in the Emergency Room… what was missed?

So why do I say “improved ability to recover from a problem” is a new concept for many doing root cause analyses today? Simple, many start and stay with “why did the problem occur.” Read more on how to improve the use of the more simple “why” tools if you have to use them:  A Look at 3 Popular Quick Idea Based Root Cause Analysis Techniques: 5-Whys, Fishbone Diagrams and Brainstorming.

restofstory

The easiest way to improve the ability to respond to a problem is to map out a timeline for actions that occurred before the problem occurred, and the immediate responses to control or correct the problem. If the response made things worse, then perform a root cause analysis on that problem as well.

comic

The last topic is prevention. The intent of a root cause analysis is not just to find the one “rootiest cause” or even a multitude of root causes. The intent is to find the problems and root causes that caused the problem and the problems that failed to catch/stop the problem AND THEN Eliminate or Mitigate those root causes so that future problems can be prevented or at the minimum, have the probability of the problems occurrence reduced.

How Fast Can You Do A Root Cause Analysis (1 hour, 1 day, 1 week, 1 month)?

Posted: May 11th, 2016 in Root Cause Analysis Tips

Screen Shot 2016-05-11 at 5.03.46 PM
Many of us have heard the tale of “The Turtle and the Hare” and their renowned race. At the end, the turtle makes it to the finish line by pacing himself, and the rabbit expends all his energy and never finishes. When it comes to the speed of getting to the finish line of your Root Cause Analysis, this tale and many real world questions come to mind.

  1. Who is mandating the time of root cause analysis completion?
  2. What does finished really mean in relation to this set deadline?
  3. Are there stopping and rest points to reach while you race towards the finish line?
  4. Does racing to the finish line ensure a good root cause analysis with effective corrective actions or does it just mean you won’t be yelled out for missing the deadline mandate instead?

Who is mandating the time of root cause analysis completion?

Is the deadline an internal company or an external client/agency requirement? If it is an external requirement, you really need to evaluate questions 2 and 3 to ensure that you are utilizing your time and resources optimally during the root cause analysis process. If the deadline mandate is an internal company rule, stop and evaluate the timeline requirement for the following criteria:

A. Do you separate Triage Response to the Incident from the actual Root Cause Analysis Investigation of the Incident?

If you stabilize the incident environment first, this will allow you more time to effectively manage your investigation. The risk to further injury and damage is reduced.

B. Do you check that your prescribed corrective actions are not driving what information you collect and analyze during the Root Cause Analysis?

Often investigators drive what they think happened and how they want to fix the problems. This can reduce the time to complete the investigation but like the Hare in the race, you never made it to the true Root Cause Analysis Finish Line.

What does finished really mean in relation to this set deadline?

Are there stopping and rest points to reach while you race towards the finish line?

These two questions can help you define the timeline for investigation completion for your own company’s internal rule; however, it is also mandatory that you understand the client’s/agency’s definitions for the criteria listed above.

For example, a contract company was required to have an incident which occurred on a client’s property investigated analyzed and corrected within 30 days from the incident’s occurrence. There was also a review process where the client would review the incident and reject it for additional clarifications or changes.

The contract company sent the finished investigation with completed correction actions on day 30. The client was frustrated because there was no time per their set deadline to send back the incident for changes. Problem is that the contract company met the mandate as written, no rules were broken.

Investigated, analyzed and corrected are great stopping points to send in information for review. The other question to ask is whether the investigation is finished once the corrective actions are created, implemented or reviewed?

The client in the above example changed their process to have turn in points for review for each phase of the Root Cause Analysis Investigation to ensure that the full 30-day completion date was met with quality investigations and effective corrective actions being completed.

Does racing to the finish line ensure a good root cause analysis with effective corrective actions or does it just mean you won’t be yelled out for missing the deadline mandate?

Now we get to the race itself: 1 hour, 1 day, 1 week, 1 month. Can a good root cause analysis get completed with good corrective actions within each of the times above? Yes, but it depends.

  1. How complex is the incident?
  2. How recent was the incident?
  3. Does your company have a process to collect evidence and written statements immediately, no matter what the degree or level of incident? (Information is often lost because of a delay to define and incident had a major incident.)
  4. Are your trained TapRooT® Root Cause Investigators available when needed and onsite? (Note that anyone at any level of the company can be trained to perform a Root Cause Analysis)

If your company follows all the key points listed, you are on the way to reaching the finish line to ensure a good root cause analysis with effective corrective actions and not it just meeting the deadline mandate. As far as the Turtle and the Hare? I’ll assign the Hare to triage and stabilize the environment and then assign my Turtle to investigate in an effective pace.

Learn more about conducting quality investigations with effective corrective actions at the 2016 Global TapRooT® Summit, August 3-5 in San Antonio, Texas.

Error Proofing: Learn Best Practices and Industry Secrets

Posted: March 11th, 2016 in Career Development, Human Performance, Quality, Summit

easier

What is the error proofing here?

 

“Easier than making a mistake” … now that is good Human Engineering!

While listening to a radio commercial recently, I heard the announcer say, “Easier than making a mistake!” As a TapRooT® Root Cause Instructor with a quality and human engineering (Human Factors) background, all that I could think about is mistake-proofing, Poka-yoke.

The concept was formalized, and the term adopted, by Shigeo Shingo as part of the Toyota Production System. It was originally described as baka-yoke, but as this means “fool-proofing” (or “idiot-proofing”) the name was changed to the milder poka-yoke. (From Wikipdia)

Now, I did not learn about Dr. Shigeo Shingo during my Human Factors study, even though a large part of training dealt 100% with design and usability from products, to controls and to user graphic user interfaces. On the flip side, Human Factors and Usability was rarely discussed during my Lean Six Sigma certification either, even though Poka-yoke was covered.

Why are two major interactive topics such as Human Factors and Poka-yoke kept in isolation, very dependent on where and what you study? Simple, shared best practices and industry secrets are not always the norm.

Where can you learn about both topics? In San Antonio, Texas during our TapRooT® Summit Week August 1-5.

In the pre-summit 2-Day TapRooT® Quality Process Improvement Facilitator Course, we cover the error of making weak preventative or corrective action items that are not based on the actual root causes found and not optimizing and understanding mistake-proofing that will impact your success in continuous process improvements.

For those that need a deeper understanding of why mistake-proofing should be considered, you should look into signing up for the 2-Day Understanding and Stopping Human Error Course.

Does A Good Quality Management System equate to Compliance?

Posted: March 8th, 2016 in Courses, Current Events, Human Performance, Investigations, Medical/Healthcare, Performance Improvement, Quality, Root Cause Analysis Tips, Root Causes, Summit, TapRooT, Training

book_graphic_1511

If it is written down, it must be followed. This means it must be correct… right?

Lack of compliance discussion triggers that I see often are:

  • Defective products or services
  • Audit findings
  • Rework and scrap

So the next questions that I often ask when compliance is “apparent” are:

  • Do these defects happen when standard, policies and administrative controls are in place and followed?
  • What were the root causes for the audit findings?
  • What were the root causes for the rework and scrap?

In a purely compliance driven company, I often here these answers:

  • It was a complacency issue
  • The employees were transferred…. Sometimes right out the door
  • Employee was retrained and the other employees were reminded on why it is important to do the job as required.

So is compliance in itself a bad thing? No, but compliance to poor processes just means poor output always.

Should employees be able to question current standards, policies and administrative controls? Yes, at the proper time and in the right manner. Please note that in cases of emergencies and process work stop requests, that the time is mostly likely now.

What are some options to removing the blinders of pure compliance?

GOAL (Go Out And Look)

  • Evaluate your training and make sure it matches the workers’ and the task’s needs at hand. Many compliance issues start with forcing policies downward with out GOAL from the bottom up.
  • Don’t just check off the audit checklist fro compliance’s sake, GOAL
  • Immerse yourself with people that share your belief to Do the Right thing, not just the written thing.
  • Learn how to evaluate your own process without the pure Compliance Glasses on.

If you see yourself acting on the suggestions above, this would be a perfect Compliance Awareness Trigger to join us out our 2016 TapRooT® Summit week August 1-5 in San Antonio, Texas.

Go here to see the tracks and pre-summit sessions that combat the Compliance Barriers.

The “Force” was with HSE this time in Star Wars Accident

Posted: February 11th, 2016 in Accidents, Equipment/Equifactor®, Investigations, Root Causes, TapRooT, Training

“The actor, Harrison Ford, was struck by a hydraulic metal door on the Pinewood set of the Millennium Falcon in June 2014.”

“The Health And Safety Executive has brought four criminal charges against Foodles Production (UK) Ltd – a subsidiary of Disney.”

“Foodles Production said it was “disappointed” by the HSE’s decision.”

Read more here

 

3 Tips for Quality Root Cause Analysis

Posted: January 27th, 2016 in Root Cause Analysis Tips

“You get what you ask for,” ever hear that phrase? Well, it is a good lead into root cause tip #1.

#1 Know why you are doing the root cause analysis but DON’T let the reason drive the root cause process and findings itself.

The quality of a root cause analysis report, or in many cases the amount of information contained in the report, is driven by the requirement for the root cause analysis itself.

    1. Government Agency Requirement
    2. Regulatory Finding Requirement
    3. Internal Company CEO/CFO Requirement
    4. Internal Company Policy Requirement
    5. Supervision Request but no policy requirement

Which one of the requirements above most likely requires a more extensive root cause analysis report, written in a very specific way? Most of us, by experience, would focus on items A-C. Besides the extensive amount of time it takes to produce the regulatory report, how could the report requirement become a driver for poor root cause analysis?

  • Report writing drives the actual evidence collection.
  • Terminology required in the report forces people to prioritize one problem over another, and in some cases ignore important information because it does not have a place in the report.
  • Information is not included or addressed because the report is going to an outside organization.

If A-C root cause analysis requirements could lead to biased or incomplete root cause analyses because of the extensive regulatory requirements, then D-E should be better right? Well, not so fast.

  • Less oversight of the root cause analysis report (if there is one) could result in less validated evidence or a list of corrective actions with limited support to substantiate them.
  • There is often a higher variability of how the root cause analysis is performed depending on who is performing it and where they are performing it.

So how do you counter the problems of standardization verses non-standardization issues in root cause analysis? The easiest method is to use a guided investigation process and not drive the process itself. Once the root cause analysis is complete, then and only then focus on writing the report.

Below is a list of 7 points with a link to read more if needed that can help reduce bias and variability. 7 Secrets of Root Cause Analysis

  1. Your root cause analysis is only as good as the info you collect.
  2. Your knowledge (or lack of it) can get in the way of a good root cause analysis.
  3. You have to understand what happened before you can understand why it happened.
  4. Interviews are NOT about asking questions.
  5. You can’t solve all human performance problems with discipline, training, and procedures.
  6. Often, people can’t see effective corrective actions even if they can find the root causes.
  7. All investigations do NOT need to be created equal (but some investigation steps can’t be skipped).

stop
#2 Establish ownership of the root cause analysis being facilitated BEFORE you go forward.

This is just plain project management advice. If the team and process owner of the issue being analyzed believe that you as the root cause facilitator own the root cause analysis, guess what… You Do! It’s your evidence, your root causes, your corrective actions and your accountability of success or failure. It is easier to pass the buck so to be speak and can also hamper the support that the facilitator needs to ensure an effective investigation.

In most cases the root cause analysis facilitator is just that, the facilitator of information. Keep it that way and establish ownership up front.

#3 As a team, define what finished means for the root cause analysis and if there is a turnover of the root cause analysis, ensure that ownership is maintained by the appropriate people.

Often the root cause analysis facilitators in my courses tell me that once the analysis portion is done at their company, the report is handed off to their supervision to make the actual corrective actions. Not optimal in itself, and should include a validation step handled by the root cause facilitator to ensure that the corrective actions match up to the original findings. The point, however, is that whatever “finished “ is, and wherever a true handoff of information must occur, it needs to be established up front along with the ownership discussed in tip #2.

In TapRooT® Root Cause Analysis, the following would be great investigation steps to focus on with your team and peers when discussing what finished means, hear more about these steps here.

  1. After Creating Summer SnapCharT® – Is the SnapCharT® thorough enough or do we need more interviews & data?
  2. After Defining Causal Factors – Are they at the right end of the cause-and-effect chain? Was a Safeguards Analysis conducted? Were all the failed safeguards identified as causal factors?
  3. After RCA and Generic Cause Analysis – Did they use their tools (Root Cause Tree®, Root Cause Tree® Dictionary, etc.)? Did they find good root causes? Did they find generic causes? Did they have evidence for each root cause?
  4. After Developing Corrective Actions – Use corrective action helper to determine effectiveness of corrective actions.

These 3 root cause tips were designed to reduce the barriers to good quality root cause analysis. Comment below if you have additional tips that you would like to pay forward.

Can You Use One Root Cause Analysis Tool for Quality, Safety, Production, IT, Cost, and Maintenance Issues?

Posted: December 2nd, 2015 in Root Cause Analysis Tips

barricade-147623_1280

Break the barriers! Look for a root cause analysis process that can tie Quality, Safety, Production, IT, Cost, and Maintenance Department issues together to help solve problems as one.

What a silly question with such a simple answer, “Yes, of course you can use one root cause analysis tool for Quality, Safety, Production, IT, Cost, and Maintenance Issues!” Soooo, why don’t we? I can hear all the functional division leaders from each corner of your company yelling, “Nooo, you can’t!”

The disagreement of which root cause analysis tools are used by who actually starts with the creation of internal company functional silos. Companies that run smoothly almost transparently as one unit realize that Quality, Safety, Production, IT, Cost, and Maintenance Departments impact each other, either positively or negatively, and should use similar tools during root cause analysis to enhance root cause analysis communication between departments. Unfortunately, this unison is not often common. Let’s break it down a little.

IT (Information Technology) – often focuses on rapid root cause diagnosis and analysis.

Quality – tends to focus on the 8 Basic Quality Tools and Lean Activities with different variations in the sequence of root cause analysis.

Safety – focuses on root cause analysis tied to hazard and risk to reduce Health, Safety and Environment Issues.

Production – is probably the closest tied to quality and cost reduction issues, whereas safety is more often viewed as cost aversion. The problem solving tools utilized here are often tied to the Quality and Cost root cause analysis tools to ensure production is met and the company makes money.

Maintenance – is focused on operational efficiencies and cost to run and maintain the equipment. Often tied to Quality and Production root cause analysis tools but more tied to equipment specifics.

Cost – everybody needs to know where the money goes and if we have enough to keep the business alive. Financial knower’s in the company get tasked by many of the departments listed above, some departments more than others. Their root cause analysis tools are more tied to transactional processes.

Now that the different company functions listed above are established, what often happens next is that the department leaders search for root cause analysis tools created just for their types of problems and the silo walls between departments get even bigger. Why? Simple, the specific function tools often only look for issues and causes tied to their specific issues. So what’s wrong with that you ask?

Input – Process – Output across your Company’s Work Processes

What each functional department changes or produces impacts another department either upstream or downstream from that department. Root cause analysis tools that are too functionally specific tend to not explore or encourage multi-department discussions during root cause analysis. If the tools don’t talk your language, they do not apply to you or in some cases, the company does not think you need to be trained in the other tools.

Case in point, as a lean six sigma black belt in a previous company, I spent my last year in manufacturing mentoring our safety department in quality tools. No one from safety had ever attended our quality training that we taught internally, even though we taught classes every month. Operations and Maintenance employees attended the training because they were more tied to the return on investment company costs.

Break the silo department barriers, look for a root cause analysis process that can tie Quality, Safety, Production, IT, Cost, and Maintenance Department issues together to help solve problems as one.

For over 28 years, System Improvements has prided itself in having a standard root cause analysis process called TapRooT®. No matter what the problem being analyzed they all start with Defining the Worst Consequence that Occurred, Identifying What Happened and How It Happened and then Why. We also teach and include Corrective Actions that are global industry best practices.

Don’t fret, because we don’t recommend that you throw away your other data collection and analysis tools, instead we recommend that you use the TapRooT® Root Cause Analysis Method as the standard communication and investigation tool for the root cause process to enhance and consolidate current programs for one company vision. After all, everything has a timeline of events or a sequence of transactions, start your problem solving with a proven root cause analysis process that starts there first and then helps guide employees through multiple types of problems to help you understand Human Performance

Peer Feedback to Improve Root Cause Analysis

Posted: November 11th, 2015 in Root Cause Analysis Tips

mark-804935_640(1)

What value does the peer get from giving feedback about a root cause analysis?

All Root Cause Analyses started have an initial goal…

Reduce, Mitigate or Eliminate a Problem!

As TapRooT® trained root cause analysis investigators soon learn, there is usually more than one Causal Factor that caused the Incident being investigated, and each Causal Factor has more than one Root Cause. If this sounds foreign to you as an investigator, check out our TapRooT® Root Cause method here. So if problems do not occur in isolation, why should the investigator work in isolation? Thus, the topic of today, “Peer Feedback to Improve Root Cause Analysis.”

Previously we discussed real–time peer review during the investigation TapRooT® Process and reviewing a completed TapRooT® looking for the “Good, Bad and the Ugly” with a spreadsheet audit included.

Root Cause Analysis Video Tip: Conduct Real-Time Peer Reviews
http://www.taproot.com/archives/45875

The Good, The Bad & The Ugly
http://www.taproot.com/archives/11045

So what’s next? Are peers created equal? What value can a peer add? What value does the peer get from giving feedback about a root cause analysis? Let’s see….

Peers are not created equal! This is a good thing. Below is a short list of peers to get feedback on your root cause analysis progression and the value that they add.

1. Coach/Mentor: This is a person who is competent and formally trained in the root cause process that you are using. They are not teaching you the process but guiding you through your use of it after you were formally trained. They have been in the trenches and dealt with the big investigations, These process champions can easily get you back on the right track and show unique techniques.

Too many companies get large numbers of employees trained in a process and then let them run free without future guidance or root cause analysis feedback. This is why our TapRooT® Instructors are available for process questions after training is complete. This is also why we encourage key company employees to attend our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training to help mentor those that have taken our 2-Day TapRooT® Incident Investigation and Root Cause Analysis Course.

2. Equal: This is the person who has attended the same root cause analysis training that you have and has the same level of competence. They may also have the same industry technical experiences that you have.

The value of the feedback from this person is to keep each other grounded in the process you are using and to help validate that the evidence received is substantiated. It is very easy sometimes to start pushing any root cause process into one’s biased direction once the energy gets flowing. The trained TapRooT® investigator and peer will remind you to slow down and let the TapRooT® process guide you to the root causes.

3. Novice: There are two types of novices to get feedback from, one that is not trained in the TapRooT® process and one that is not familiar with the investigation or process being investigated.

There is a natural tendency that the more you know about the process you are investigating, the less that you put down on paper. After all, everyone knows how that thing works or what happened. Why do I need to write it down? Simple… “What does not get written down does not get investigated!” As the novice asks you more questions to understand the root cause analysis that you are performing, the more you explain and the more you write down.

4. Formal Auditor: The formal auditor usually audits the root cause analyses after they are completed and the corrective actions have been implemented. There is less communication and engagement between you and the auditor, which is very different than the first peers listed above.

The value of this feedback is that it is designed to look for consistency and standardization across multiple root cause analyses. The auditor may find investigations that need to be recalibrated but may also find new and better ways of doing an investigation based on other’s unique techniques. We also encourage auditors to have taken our 2-Day Advanced Trending Techniques Course, to help look for trends.

The final plus for this feedback activity…..

“Everyone learns something and recalibrates their Root Cause Analysis Techniques and we all help meet the goal of Reduce, Mitigate or Eliminate a Problem!”

A Look at 3 Popular Quick Idea Based Root Cause Analysis Techniques: 5-Whys, Fishbone Diagrams and Brainstorming

Posted: August 26th, 2015 in Root Cause Analysis Tips

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.

Brainstorming

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:

 noun

– a sudden impulse, idea, etc.

– a fit of mental confusion or excitement. 

Origin

-1890-95; brain + storm; originally a severe mental disturbance

Then I might suggest the following “whys”:

  1. The person was bored.
  2. A student was doing research.
  3. A training department was assigned to find and schedule quick low cost training techniques that can be taught online.
  4. 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:

  1. Focus on quantity…. The more the merrier.
  2. Withhold criticism…. No why is a bad why and you might shut down the quantity given by others that were made fun of.
  3. Welcome unusual ideas
  4. 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:

  1. The person was bored.
  2. A student was doing research.
  3. A training department was assigned to find schedule quick low cost training techniques that can be taught online.
  4. You were assigned to find good root cause training to solve problems.
  5. The current root cause techniques are not working very well.
  6. 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.

Fishbone1stgraphic
Now this tool also comes with some rules:

  1. Agree on a problem statement as a group. Ours is “why are people searching for root cause analysis on the internet?”
  2. The problem statement is placed at the head of the fish as seen in the diagram above.
  3. 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

Product/Service
Price
Place
Promotion
People/personnel
Process
Physical Evidence
 
The 5 S’s
Surroundings
Suppliers
Systems
Skills
Safety

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.

2ndimage

  1. 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.

5 Whys

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.

  1. 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.

  1. 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.

  1. Why do we not have new computers that can have databases installed?

 Answer the company is short money.

  1. Why is there no money left to purchase computers?

Answer: Because we have lost money on repeat incidents.

  1. 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.

  1. 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.

  1. 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.

  1. 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…..

  1. If it looks too easy and requires less work, you get what you put in it.
  2. If there is a large amount of guessing, you are also guessing at the corrective action.
  3. If the right expert is not in the room when using the tools explored, nobody will know what to ask or to verify.
  4. 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, Why and then Fix… There is No Other Sequence for Root Cause Analysis

Posted: August 12th, 2015 in Root Cause Analysis Tips

pablo(8)
Heard the quote above in a movie years ago when a group of scientists created a super computer to solve the “Ultimate Question of Life.” The super computer’s “ultimate answer” was “42”. This answer meant nothing to the community because they did not know the ultimate question for the ultimate answer.

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.

Connect with Us

Filter News

Search News

Authors

Angie ComerAngie Comer

Software

Barb CarrBarb Carr

Editorial Director

Chris ValleeChris Vallee

Human Factors

Dan VerlindeDan Verlinde

VP, Software

Dave JanneyDave Janney

Safety & Quality

Garrett BoydGarrett Boyd

Technical Support

Ken ReedKen Reed

VP, Equifactor®

Linda UngerLinda Unger

Co-Founder

Mark ParadiesMark Paradies

Creator of TapRooT®

Per OhstromPer Ohstrom

VP, Sales

Shaun BakerShaun Baker

Technical Support

Steve RaycraftSteve Raycraft

Technical Support

Wayne BrownWayne Brown

Technical Support

Success Stories

In March of 1994, two of our investigators were sent to the TapRooT 5-day Incident Investigator Team…

Fluor Fernald, Inc.

In 1995, BellSouth Telecommunications noticed an increase in the number of service interruptions or outages…

Bell South
Contact Us