Author Archives: Chris Vallee
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.
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.
Whether analyzing customer complaints, process defects or safety findings, the use of 5 Whys for problem-solving has been in place for many years; if you are still using it for low risk issues, below are links to additional articles to help you be more effective in its use:
This blog article, however, is to understand what many mean when asking why or how it is perceived when asked why during problem solving. I thought I would make it easy and define what why means using the Oxford Dictionary. I asked myself why after I did that!
– Expressing surprise or indignation: Why, that’s absurd!
– Used to add emphasis to a response: You think so? Why, yes.
– For what reason or purpose: Why did he do it?
– [with negative] Used to make or agree to a suggestion: Why don’t I give you a lift?
– (with reference to a reason) on account of which; for which: The reason why flu jabs need repeating every year is that the virus changes.
– The reason for which: Each has faced similar hardships, and perhaps that is why they are friends.
– A reason or explanation: The whys and wherefores of these procedures need to be explained to students.
– Old English hwī, hwȳ ‘by what cause’, instrumental case of hwæt ‘what’, of Germanic origin.
Interestingly enough, the origin appears to be more representative of problem solving than any of the new definitions that appeared in the online Oxford dictionary. The majority of the new definitions appear to miss the mark in problem-solving.
Take the Interrogative adverb, “Why did he do it?” This can easily be perceived as blame waiting for an excuse of why he did it. Once the problem solver gets the excuse, then the investigation is complete. Especially if you are interviewing the person involved in the problem.
Why as a noun, defined as a reason or explanation, is often inferred to mean this is why the person was supposed to follow the rules, but it does not allow or encourage the rule to be reevaluated if it does not work as intended or is just plain wrong.
The exclamation why is one we should all relate to, “I’ll keep asking why until you change your tune.”
As an effective problem solver, review the definitions of why listed above and ask yourself, “Am I using why in problem solving the way it was originated or not? Have I stopped at why when I should have gone further into true effective root causes?”
Finally ask yourself, “Have I made these mistakes asking why on moderate to high level problems?”
If the answer is “yes” to the questions above, stop asking why and join us in one of our upcoming TapRooT® root cause analysis courses.
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.
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.
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.”
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:
- Flint River Lead Exposure Delayed Response
- Firestone Tire Delayed Recall
- 1947 Explosion Caused by Incorrect Response to Initial Fire
- 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.
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.
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.
- Who is mandating the time of root cause analysis completion?
- 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?
- 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.
- How complex is the incident?
- How recent was the incident?
- 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.)
- 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.
“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.
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.
“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
“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.
- Government Agency Requirement
- Regulatory Finding Requirement
- Internal Company CEO/CFO Requirement
- Internal Company Policy Requirement
- 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
- Your root cause analysis is only as good as the info you collect.
- Your knowledge (or lack of it) can get in the way of a good root cause analysis.
- You have to understand what happened before you can understand why it happened.
- Interviews are NOT about asking questions.
- You can’t solve all human performance problems with discipline, training, and procedures.
- Often, people can’t see effective corrective actions even if they can find the root causes.
- All investigations do NOT need to be created equal (but some investigation steps can’t be skipped).
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.
- After Creating Summer SnapCharT® – Is the SnapCharT® thorough enough or do we need more interviews & data?
- 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?
- 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?
- 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
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
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
The Good, The Bad & The Ugly
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 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)