Author Archives: Chris Vallee
A Look at 3 Popular Quick Idea Based Root Cause Analysis Techniques: 5-Whys, Fishbone Diagrams and BrainstormingPosted: 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.
Why would a person search for root cause analysis training on the Internet? If I were to brainstorm the whys as defined in dictionary.reference.com:
- a sudden impulse, idea, etc.
- a fit of mental confusion or excitement.
-1890-95; brain + storm; originally a severe mental disturbance
Then I might suggest the following “whys”:
- The person was bored.
- A student was doing research.
- A training department was assigned to find and schedule quick low cost training techniques that can be taught online.
- You were assigned to find good root cause training to solve problems.
Now those weren’t too many suggestions on my part. But there is hope, because brainstorming is best served in groups. As defined in wikeipedia.org:
Brainstorming is a group creativity technique by which efforts are made to find a conclusion for a specific problem by gathering a list of ideas spontaneously contributed by its members.
But we have to establish a few rules per wikipedia.org:
- Focus on quantity…. The more the merrier.
- Withhold criticism…. No why is a bad why and you might shut down the quantity given by others that were made fun of.
- Welcome unusual ideas
- Combine and improve ideas… we can build off other peoples’ whys for a really good why to solve a problem.
Okay with our new rules and group in place, we came up with more whys to why someone was searching for root cause analysis on the internet:
- The person was bored.
- A student was doing research.
- A training department was assigned to find schedule quick low cost training techniques that can be taught online.
- You were assigned to find good root cause training to solve problems.
- The current root cause techniques are not working very well.
- You are planning a party and this would be a great team game. (This one was my favorite suggestion)
Fishbone (Ishikawa) Diagrams
Brainstorming not quite good enough in our quest to solve why people are searching for root cause analysis on the internet you think? Let’s do a guided search for whys with our group using a Fishbone (Ishikawa) Diagram.
- Agree on a problem statement as a group. Ours is “why are people searching for root cause analysis on the internet?”
- The problem statement is placed at the head of the fish as seen in the diagram above.
- Now Brainstorm the major categories of the cause of the problem and list them underneath each category. For our fishbone from wikipedia.org, we are going use Methods, Machines, Material and Measurements.
a. Methods: How the process is performed and the specific requirements for doing it, such as policies, procedures, rules, regulations and laws
b. Machines: Any equipment, computers, tools, etc. required to accomplish the job
c. Materials: Raw materials, parts, pens, paper, etc. used to produce the final product
d. Measurements: Data generated from the process that are used to evaluate its quality
Caution, there are many categories to chose from which may lead the group into different directions each time they use one. We could have also used the categories as listed in wikipedia.org:
The 7 P’s
The 5 S’s
Here is our refined fishbone. I have to admit, it does look a little better than the brainstorming list above. Did not take that much time at all.
- As each idea is given, the facilitator writes it as a branch from the appropriate category.
- Again ask “why does this happen?” about each cause.
- Write sub-causes branching off the causes. Continue to ask “Why?” and generate deeper levels of causes. Layers of branches indicate causal relationships.
Item number 4 gets into looking for causal relationships within our suggested causes which leads into our 5 whys discussion next.
Let’s take one of the “causes” listed above and get to a good root cause with our group to understand why people are searching for root cause analysis on the internet?
Here are the simple instructions for performing a 5 Whys as listed in wikipedia.org:
5 Whys is an iterative question-asking technique used to explore the cause-and-effect relationships underlying a particular problem. The primary goal of the technique is to determine the root cause of a defect or problem by repeating the question “Why?” Each question forms the basis of the next question.
- Why are people searching for root cause analysis on the internet?
Answer: Because there is no database to search in on their computer and the boss wants training answers now.
- Why is there no database on the computer to search from?
Answer: Because these are computers produced in 1995 and a knowledge database cannot be installed.
- Why do we not have new computers that can have databases installed?
Answer the company is short money.
- Why is there no money left to purchase computers?
Answer: Because we have lost money on repeat incidents.
- Why do we have repeat incidents?
Answer: Because we do not have a good, effective, cost reducing Root Cause Analysis Process. I have a great solution for this problem….. look here for future courses in TapRooT® Root Cause Analysis.
Okay, I agree this was a very high level and superficial exploration of the 3 Popular Quick Idea Based Root Cause Analysis Techniques: 5-Whys, Fishbone Diagrams and Brainstorming.
However, the steps that we explored are valid steps and flow of the actual processes. The ending results from superficial creation of whys are very true and have been the cause for repeat problem occurrences.
If you are going to use these process, as they are often still required for everyday issue resolution for some and for others are actually considered their only root cause tools, then head off some of the issues with a couple of these best practice suggestions.
- Never start with Brainstorming. This is a great tool for suggesting corrective actions tied to actual root causes, but should not be used for evidence collection and figuring out why something happened.
What to do instead? Go Out And Look (GOAL). Never armchair troubleshoot from a conference table surrounded by people.
- Only use a Fishbone (Ishikawa) Diagram if:
a. You have collected evidence
b. You standardized and defined your fishbone cause categories
c. You have the right experts in the room
d. Cause or Corrective action ideas do not drive the actual what and why questions.
- Only use 5 Whys for trying to identify the actions or inactions that allowed an issue to occur and not the actual root causes. Why?
a. There is a tendency to look for only one cause when using the process; even if you ask 5 Whys for each action or inaction found on the Fishbone (Ishikawa) Diagram, there is still a tendency to look for only one cause in each section. I have never just had one cause for any problem that I have investigated.
b. It is not how many questions one asks but what one asks.
c. When used to collect evidence or understand evidence, there is a tendency for “group think” to occur that drives which direction the evidence and causation linkage goes. Look up the Space Shuttle issue tied to the o-ring failure for a group think example that was detrimental to life.
d. There is nothing to push the investigations outside what they know as a whole and what may be missing from the investigation. In that case, always bring in different knowledgeable and people new to the problem for constant checks and rechecks. Also look for outside industry best practices and knowledge to help get better investigations completed.
So in closing…..
- If it looks too easy and requires less work, you get what you put in it.
- If there is a large amount of guessing, you are also guessing at the corrective action.
- If the right expert is not in the room when using the tools explored, nobody will know what to ask or to verify.
- If the people using the process are the only thing driving the evidence collection, bias has a stronger natural tendency to take over.
I look forward to your examples of using these processes and also comments on some of the traps you did or did not avoid while using these 3 tools.
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.
The 22-year-old man died in hospital after the accident at a plant in Baunatal, 100km north of Frankfurt. He was working as part of a team of contractors installing the robot when it grabbed him, according to the German car manufacturer. Volkswagen’s Heiko Hillwig said it seemed that human error was to blame.
A worker grabs the wrong thing and often gets asked, “what were you thinking?” A robot picks up the wrong thing and we start looking for root causes.
Read the article below to learn more about the fatality and ask why would we not always look for root causes once we identify the actions that occurred?
“Doctor… how do you know that the medicine you prescribed him fixed the problem,” the peer asked. “The patient did not come back,” said the doctor.
No matter what the industry and or if the root causes found for an issue was accurate, the medicine can be worse than the bite. Some companies have a formal Management of Change Process or a Design of Experiment Method that they use when adding new actions. On the other extreme, some use the Trial and Error Method… with a little bit of… this is good enough and they will tell us if it doesn’t work.
You can use the formal methods listed above or it can be as simple for some risks to just review with the right people present before implementation of an action occurs. We teach to review for unintended consequences during the creation of and after the implementation of corrective or preventative actions in our 7 Step TapRooT® Root Cause Analysis Process. This task comes with four basic rules first:
1. Remove the risk/hazard or persons from the risk/hazard first if possible. After all, one does not need to train somebody to work safer or provide better tools for the task, if the task and hazard is removed completely. (We teach Safeguard Analysis to help with this step)
2. Have the right people involved throughout the creation of, implementation of and during the review of the corrective or preventative action. Identify any person who has impact on the action, owns the action or will be impacted by the change, to include process experts. (Hint, it is okay to use outside sources too.)
3. Never forget or lose sight of why you are implementing a corrective or preventative action. In our analysis process you must identify the action or inaction (behavior of a person, equipment or process) and each behaviors’ root causes. It is these root causes that must be fixed or mitigated for, in order for the behaviors to go away or me changed. Focus is key here!
4. Plan an immediate observation to the change once it is implemented and a long term audit to ensure the change sustained.
Simple… yes? Maybe? Feel free to post your examples and thoughts.
We can all remember some type of major product recall that affected us in the past (tires, brakes, medicine….) or recalls that may be impacting us today (air bags). These recalls all have a major theme, a company made something and somebody got hurt or worse. This is a theme of “them verses those” perception.
Now stop and ask, when is the last time quality and safety was discussed as one topic in your current company’s operations?
You received a defective tool or product….
- You issued a defective tool or product….
- A customer complained….
- A customer was hurt….
Each of the occurrences above often triggers an owner for each type of problem:
- The supplier…
- The vendor…
- The contractor…
- The manufacturer….
- The end user….
Now stop and ask, who would investigate each type of problem? What tools would each group use to investigate? What are their expertise and experiences in investigation, evidence collection, root cause analysis, corrective action development or corrective action implementation?
This is where we create our own internal silo’s for problem solving; each problem often has it’s own department as listed in the company’s organizational chart:
- Customer Service (Quality)
- Manufacturing (Quality or Engineering)
- Supplier Management (Supply or Quality)
- EHS (Safety)
- Risk (Quality)
- Compliance (?)
The investigations then take the shape of the tools and experiences of those departments training and experiences.
Does anyone besides me see a problem or an opportunity here?
Caution: Watching this Video can and will make you laugh…… then you realize you might be laughing at…
… your own actions.
… your understanding of other peoples actions.
… your past corrective or preventative actions.
Whether your role or passion is in safety, operations, quality, or finance…. “quality is about people and not product.” Interestingly enough, many people have not heard Dr. Deming’s concepts or listened to Dr. Deming talk. Yet his thoughts may help you understand the difference between people not doing their best and the best the process and management will all to be produced.
To learn more about quality process thoughts and how TapRooT® can integrate with your frontline activities to sustain company performance excellence, join a panel of Best Practice Presenters in our TapRooT® Summit Track 2015 this June in Las Vegas. A Summit Week that reminds you that learning and people are your most vital variables to success and safety.
To learn more about our Summit Track please go to this link. https://www.taproot.com/taproot-summit
If you have trouble getting access to the video, you can also use this link http://youtu.be/mCkTy-RUNbw
Airplane loses power during take off at a Kansas Airport and plane strikes building. Pilot of the King Air Aircraft that crashed and 3 people working in a flight simulator inside that building are dead. Read more here at KAKE News in Wichita, KS.
I post this because of the debates and blame that are going to ensue. Was it just one thing, the plane crashing, that caused this issue to occur? Was it the location of all the flight buildings in the vicinity of an airport. Was this just a “freak accident”. So much more to learn… I hope they get it right so it does not happen again.
OSHA General Duty Clause Citations: 2009-2012: Food Industry Related Activities
Doing a quick search of the OSHA Database for Food Industry related citations, it appears that Dust & Fumes along with Burns are the top driving hazard potentials.
Each citation fell under OSH Act of 1970 Section 5(a)(1): The employer did not furnish employment and a place of employment which were free from recognized hazards that were causing or likely to cause death or serious physical harm to employees in that employees were exposed……
Each company had to correct the potential hazard and respond using an Abatement Letter that includes words such as:
The hazard referenced in Inspection Number [insert 9-digit #]
for violation identified as:
Citation [insert #] and item [insert #] was corrected on [insert
Okay so you have a regulatory finding and listed above is one of the OSHA processes to correct it, sounds easy right? Not so fast…..
….are the findings correct?
….if a correct finding, are you correcting the finding or fixing the problems that allowed the issue?
….is the finding a generic/systemic issue?
As many of our TapRooT® Client’s have learned, if you want a finding to go away, you must perform a proper root cause analysis first. They use tools such as:
o SnapCharT®: a simple, visual technique for collecting and organizing information quickly and efficiently.
o Root Cause Tree®: an easy-to-use resource to determine root causes of problems.
o Corrective Action Helper®: helps people develop corrective actions by seeing outside the box.
First you must define the Incident or Scope of the analysis. Critical in analysis of a finding is that the scope of your investigation is not that you received a finding. The scope of the investigation should be that you have a potential uncontrolled hazard or access to a potential hazard.
In thinking this way, this should also trigger the need to perform a Safeguard Analysis during the evidence collection and during the corrective action development. Here are a few blog articles that discuss this tool we teach in our TapRooT® Courses.
Monday Accident & Lesson NOT Learned: Why Do We Use the Weakest Corrective Actions From the Hierarchy of Safeguards?http://www.taproot.com/archives/28919#comments
Root Cause Analysis Tip: Analyze Things That Go Right … The After-Action Review
If you have not been taking OSHA Finding to the right level of action, you may want to benchmark your current action plan and root cause analysis process, see below:
BENCHMARKING ROOT CAUSE ANALYSIS
Watch two children explain their morning routine using a process flow chart and a control chart.
If you do not have a knowledgeable kindergartner hanging around to help you, I would recommend attending the following this April during our TapRooT® Summit Week:
Advanced Trending Techniques
TapRooT® Quality/Six Sigma/Lean Advanced Root Cause Analysis Training http://www.taproot.com/taproot-summit/pre-summit-courses#TapRooTSixSigma
Process Quality and Corrective Action Programs
We just saw a loss of life in the local Tennessee area following a flat tire while still on the roadway. The driver with the flat tire stopped in or near a high traffic lane, got out of the vehicle and was killed when cars hit the stopped car. Unfortunately, this type of fatality or near miss to a fatality happens too frequently in all parts of the world.
If you drive, know someone that drives or knows someone that will soon be getting a license to drive, please heed the following…..
Do not stop in the travel lanes for any reason (lost or confused about directions, vehicle breakdown, or letting out a passenger). Keep moving until you can safely pull your vehicle off the roadway. (reference the Tennessee Driver’s Manual)
Material found in a doughnut, see the initial indications from the KAKE media article below. A child is in a hospital bed at an Army Hospital after he took a bite of a glazed cake doughnut from a large retailer bakery. His mother says that the child said the doughnut tasted crunchy and then he chipped a tooth. “There were pieces of black metal, some of them looked like rings, like washers off of a little screw, some of them were black metal fragments, like real sharp pieces,” says the mother. The mother says that the child complained he had abdominal pains after swallowing the objects from the doughnut. Read the article here. The retailer spokesperson said the company’s food safety team is looking into the incident, reaching out to the doughnut supplier and trying to figure out what happened. Now what? Is this a safety or quality issue or both? If you were the retailer what would you do? Would you quarantine the doughnutt and ask for access to the material found in the stomach? Would you be allowed? If you were the doughnut supplier what would you do? Would you look for similar batches and quarantine them? Would you inspect the batches or turn them over to the supply? Would you be allowed? If you were the doughnut manufacturer what would you do? Would you inspect the equipment used for this batch? Would you look for facility work order reports already completed or reported? For all 3 parties, would you work together as one team to resolve the issue? What if you could not find any evidence on your side of missing parts? Everything just discussed would be part of the analysis/investigation planning stage. The first step of our TapRooT® 7 step investigation process. To learn more about what you would do following a problem, here are a few articles to learn more about are process and courses available. What is Root Cause Analysis? Root Cause Analysis Tip: Why Did The Robot Stop? (Comparing 5-Why Results with TapRooT® Root Cause Analysis Results) Our public course schedule
By Chris Vallee
I was an aircraft mechanic in USAF when this incident occurred. The aftermath of the F-15 Crash and Pilot Fatality continued with an Airman’s suicide was loss to many.
While, I knew the basics, I just recently found a follow up report and wanted to share it. The information is taken directly from the article as is without my paraphrase. Here is the website.
An Air Force review board has partly cleared the name of an F-15 mechanic who committed suicide in 1996 rather than face a court-martial for a fatal repair error.
Evidence showed that TSgt. XXXXXX did not perform the botched control rod maintenance at issue, although he did check the work and found nothing wrong.
In addition, several previous incidents in which other mechanics made the same mistakes should have alerted the Air Force to a potential problem, according to the board.
“We did not think XXXX was totally free of all responsibility,” said Lee Baseman, chairman of the correction board. “But it was our view that he was unduly carrying the burden for a series of missteps that went back at least 10 years.”
In May 1995, XXXX and TSgt. YYYYYY were carrying out maintenance on an F-15C based at Spangdahlem AB, Germany, when YYYYY accidentally crossed flight control rods while reinstalling them. XXXX did not catch the miscue, which made the airplane impossible to control in the air. It subsequently crashed, killing Maj. Donald G. Lowry Jr. (Great GUY!!)
Air Force authorities charged XXXX and YYYYY with dereliction of duty and negligent homicide. XXXXX shot himself in October 1996 during a break in court proceedings. Commanding officers then accepted YYYYY request for administrative separation, on grounds that the interests of the service would be best served by bringing the tragic case to a swift conclusion.
Similar crossed-rod cases occurred at least twice before the Spangdahlem crash, noted the review board-once in 1986 and again in 1991. But in both instances the problem was caught before takeoff.
In its conclusions, the board stated, “After the Black Hawk shootdown [in 1994], the demand for accountability for this accident may have been pursued with such zeal as to leave fairness and equity behind. The fatal crash was a tragedy waiting to happen, yet the decedent was singled out to pay for an accident that could have been prevented anywhere along the ‘chain of events’ had any of the numerous individuals involved made different decisions.
“Most disturbing was the way the Air Force leadership allowed this case to be handled. The Air Force’s representatives resisted the inclusion of potentially exculpatory evidence from the review and report and managed to have a good deal of it excluded from consideration in the pending trial.”
Following the death of Lowry, the Air Force took steps to prevent such a mix-up from happening again. The control rods are now color-coded to ensure proper installation, and the maintenance technical manual warns against the mistake. All flight control systems must now be checked any time the control rods undergo maintenance. ” “
Ref: Journal of the Air Force Association, June 1998 Vol. 81, No.5, Peter Grier
I know, it is too early for Friday’s Joke of the Day, but I could not help it. I saw this posted recently and had to share.
As you are laughing, look into your tool cabinet and tell me that you do not have these 2 items in it.
Now if you want to know how to troubleshoot equipment the right way to find the right what’s and why’s and want an Individual TapRooT® Software License (comes with the course), then join us at one of our Equifactor® courses.
Here is the current schedule: http://www.taproot.com/store/3-Day-Courses/
I’ll bring my WD-40 and Duct Tape for the classroom equipment.
What are the risks of setting a circuit breaker without knowing why it opened?
I just saw this local news article about a father teaching his daughter about the circuit breaker panel in their house after a ceiling fan stopped working. End result….. House on fire. Read more here.
With eighteen years in aviation and having worked on the C-141 Aircraft, this incident brought to mind the wrong pump replaced and reseting the circuit breaker during testing explosion. Read more here.
There are additional ways to gain equipment troubleshooting experience without starting a fire. The easiest way is to attend one of our upcoming Equifactor® Course coming up in your local area. See the schedule here: http://www.taproot.com/store/3-Day-Courses/
With community protests after losing school aged loved ones, the Indian Government is closing in on suspected causes to include suspects. But is this a sign of Systemic Food Quality Control or as TapRooT® calls them “Generic Causes”? Will the nature of the investigations detour looking for Generic Causes by looking for blame instead?
Read below and ask, how would this be investigated or analyzed if it were in your hometown? What would be the response of the lunch cafeterias and Food on Wheels programs for the elderly and sick?
In a months time…..
23 students in the southwestern coastal state of Goa were treated at a hospital after they got sick at lunch
23 students died and 25 people were hospitalized from food poisoning after a school lunch in northern India’s Bihar state
Schoolchildren falling sick after drinking contaminated water from hand pumps continued for the third consecutive day on Saturday with at least 35 more students taken ill in different parts of Bihar.
Arrests made in two of incidents with possible cause being insecticide poisoning; the water pump incident possibly criminal intent and the Bahir lunch room incident due to possible negligence. The Goa incident not so clear in details yet.
Due to fear, large lunch producers temporarily shut down their lunch kitchens resulting in children not getting their mandated free lunches during school.
See more at this link:
Whether in the medical device, pharmaceutical or the food manufacturing industry, a company usually has had many violation corrective action chances before they get a consent decree of permanent injunction. At this point a third party reviews current deviations and often identifies a weak or non-existent root cause analysis program.
Now don’t get me wrong, this is often when our TapRooT® Root Cause Process gets recommended as a possible option and we gain a new client. However, I would prefer working with an FDA regulated company to develop effective corrective actions before they get in trouble. Or at least when they get their first FDA Finding.
Often FDA findings are found by an external audit. To remain independent, the auditor turns over the findings through proper protocol and the company involved must provide proof that the causes were found and that the corrective action is effective. So if this protocol is followed, how did we get to a permanent injunction? Can the repeat findings be purely an Enforcement Needs Improvement Root Cause for policies not followed?
I suggest Enforcement needs improvement is not the only problem. To find out what your company might be missing in your RCA process. Find a course close to you and send one of your key quality or safety problem facilitators. Here is our upcoming courses link: http://www.taproot.com/store/Courses/
To get you thinking about possible gaps in your root cause analysis program, view this presentation given at our 2012 TapRooT® Summit. http://www.taproot.com/content/wp-content/uploads/2012/02/RileyandGorman.pdf
Then check out the quality track in the upcoming 2014 Summit in April. http://www.taproot.com/products-services/summit
Based on client’s request, we have scheduled our ONLY Public India 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training for April 22 – April 26.
For those not familiar with the course, it includes the TapRooT® single user software (unless attendee’s company has a network software license), TapRoot® book, Corrective Action Helper®, Root Cause Dictionary & Laminated Root Cause Tree, Course Workbook.
Course Fee which includes a software individual license for each student is only $2,395 USD. Here is the registration link: Register
Please register 30 days prior to the course if you need a quote first to send to your billing department. Anything within 30 days or less must be paid for during registration. All course seats must be paid for prior to the course to hold the seat and attend the course.
We look forward to seeing our repeat clients and new clients in our only 5-Day public India course for 2013.
With many industries and natural resources located in Trinidad, System Improvements, Inc. teaches many onsite TapRooT® Root Cause Analysis Courses. In fact, I will be teaching a 3-Day TapRooT®/Equifactor® Equipment Troubleshooting & Root Cause Failure Analysis this November with contract instructor, Mark Olson. I will be scheduling another 5 Day Course in Trinidad this the summer of 2013.
We get so busy sometimes in performing root cause analysis facilitations, courses and just plain business, that it is nice to see a reminder about why we want to make all industries safer. Pictured above is Safraz Ali, a student from the Trinidad Course, whom I had the opportunity to meet with his family.
Family, friends and the community are why we love what we do when we get it right!
Valerie Johnson is now certifed to teach the TapRooT® 2-Day Course to the ConocoPhillips Aviation Division. Valerie flew in from Alaska to Houston to get trained and upon return will be co-teaching with long time certified instructor Michael Rodriguez.
As a Senior Associate with System Improvements, Inc. with 18 years in aviation, it was a pleasure to teach the course in the Aviation Hangar offices. David Camille, also pictured above, was instrumental in coordinating this course and giving me the tour of one of their Gulfstreams.
By this time, many of you see Causal Factors everywhere you look; can’t help yourself, your brain just works that way after taking a TapRooT® Root Cause Analysis Course. Every once in a while, your brain also needs a quick jumpstart. Thus, today’s topic covers “What’s a Causal Factor” and “What is not a Causal Factor.”
In our TapRoot® Courses we define a Causal Factor as either an action or lack of action that caused an Incident or made the incident worse. Basically it boils down to following:
An action someone performed.
An action, a piece of equipment, component or process transaction performed.
An action not performed by someone.
An action not performed by piece of equipment, component or process transaction.
REMINDER 1: This is not saying we are blaming the person, piece of equipment, component or process transaction. We are just identifying the actions or lack of actions that had to be present for the incident to occur or get worse.
For example, a person may have followed a procedure perfectly and still created the ignition that ignited the fuel vapor. We are just stating the facts.
REMINDER 2: We do not fix Causal Factors, we fix Root Causes that allowed or failed to prevent the Causal Factor from happening.
For example, “Lights NI” is one of our Root Causes on the Root Cause Tree®. This could be one of the roots causes as to why an operator grabbed the wrong valve. We would fix the lighting issue and not the operator. Fixing the lighting will help the operator more successful in his/her task.
REMINDER 3: Use the Four Step Method and the Safeguard Error Questions to help define the Causal Factor. You have to go to a TapRooT® Course to learn these techniques.
Often when using the methods above you realize that you had not even identified a Causal Factor. In fact, it might not even be on your SnapCharT® yet.
Let me if these tips help.
If you like root cause analysis tips, you may be interested in viewing a short video in our free series:
What Makes a World-Class Root Cause Analysis System (Click here to view ten minute video.)
Doing Better Investigations (Click here to view six minute video.)
Just a few quick best practice points today to use when analyzing a Causal Factor using the Root Cause Tree®, Root Cause Tree® Dictionary and your created SnapCharT® …
1. You are looking for Root Causes that contributed to the person’s, equipment’s or process’ inability to successfully perform a specific task (Causal Factor). The Causal Factors led to an Incident or made the Incident worse.
For example, the investigator needs to find Root Causes for why the mechanic pushed the lift control up instead of down which then caused the load to become unbalanced with the Incident being a Damaged Product.
2. You must use the Root Cause Tree®, Root Cause Tree® Dictionary and SnapCharT® together. NO EXCEPTIONS. NO ASSUMPTIONS.
3. Treat the bullets in the Root Cause Tree® Dictionary as black and white. No reading between the lines. If there is failure to agree during the analysis, you must get further clarification of your Condition and Events on your SnapCharT®. Clarify the facts, identify the bullets in the dictionary, and then verbally repeat the Causal Factor that you are analyzing. If the logic still does not match, then it is not a Root Cause.
4. Select the Root Cause if it is a fact. DO NOT ignore a valid Root Cause and fail to select it because you think it can not or will not be changed. You can prioritize what does get fix or what does not get fixed during steps 5 and 6 of our 7-Step Process.
Help this helps settle some previous investigation discussions.
There is a discussion and a poll about when an action would change the scope of work that required work stoppage.
Join our group on LinkedIn to vote or discuss your perspective: TapRooT® Root Cause Analysis Users and Friends
The article is titled Causal Factor: Crew did not stop the task when there was a Change of Work Scope. I see this Causal Factor way too much in many reports. When do you consider the job no longer within the work scope?
Once the workers have determined that the work scope has changed, many would implement their Management of Change (MOC). What if there is no formal MOC developed yet? If you have taken the 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training or if you read Chapter 12 in TapRooT®, Changing the Way the World solves Problems, one option is to use CHAP, which stands for Critical Human Action Profile.
In CHAP you are taught to list out the steps of the task or work set up where something went wrong. We then teach you to identify the critical step where the injury or problem occurred. Once identified, there is a list of key step profile questions that must be evaluated. The key difference in what I am proposing is that you do not have to wait for an incident to use CHAP. Use it proactively at the the work stop moment by identifying all critical steps for safety and operation.
Now what? Where does Change Analysis come into play here? There is another tool taught in our 5-Day and Equifactor® or if you read Chapter 11 in TapRooT®, Changing the Way the World solves Problems. After identifying the critical steps in key tasks using CHAP, you establish key Performance Factors that cannot or should not be changed without a review. You have created a formal or informal Management of Change (MOC).
Please feel free to contact the author of this article, Chris, or any of our TapRooT® Instructors for help. The easiest way is to email firstname.lastname@example.org and reference this article. I also read the comments that are posted and will follow up.
Thought it would be fitting to post this on Thursday instead of Wednesday (when we typically post Root Cause Tips) considering the best practice being discussed. Today’s topic covers lessons learned during TapRooT® implementation and resource management as it applies to analyzing and correcting Generic Causes. The following is a recent discussion that I had with one of our proactive clients.
Generic Causes, also known as business and operation level process issues, are often a new concept to companies when they are introduced to the 7 Step TapRooT® Process. A recent client took this concept and ran with it with full force. An unintended consequence of identifying and analyzing for Generic Causes is the added time needed to complete a full analysis if required. This in turn delays the implementation of Corrective Actions for the Incident’s Specific Root Causes. In other words, the Causes that are closest to the initial Incident that need to be fixed immediately.
There is great value for the facilitators/investigators and the Incident’s process or department owners to be involved in the identification of Generic Level Issues. Once identified, the Generic Issues should/could be turned over to key employees who can run the higher process analyses.
Benefit: Less time to complete initial investigation, faster implementation of initial corrective actions, reduced backlog of Incidents waiting to be analyzed.