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.
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 why 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.
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.
This root cause report was prepared for Fermilab Research Alliance (FRA) on September 14, 2007 following the “Large Hadron Collider Magnet System Failure”.
1) On November 25, 2006 a heat exchanger internal to one of the Fermilab supplied magnets collapsed in a pressure test
2) On March 27, 2007 structural supports internal to one of the Fermilab supplied magnets failed in a pressure test.
Here is the link to the Incident PDF: http://www.fnal.gov/directorate/OQBP/index/oqbp_misc/Final_LHC_Root_Cause_Analysis_Report_Rev2_19Sep07.pdf
Here at System improvements, Inc. and in our TapRooT® Root Cause Analysis Courses that we teach, we encourage our process be used for multiple business processes. In this Root Cause Report, the areas below were investigated using our root cause process as one of the investigation tools:
• Project Management
• Procurement & Construction
• Acceptance & Testing
• Commissioning & Startup
Read the report and see what they determined and also how they integrated TapRooT® into the actual report. Let me know what you think.
Apparent Cause Evaluation, (known as ACE to many), is often used to quickly figure out a fix for a problem that does not need a true root cause analysis because it is not a critical issue. Usually a risk matrix helps a company determine whether a problem is critical. Criteria in the matrix can include likelihood of it occurring, cost and extent of injury or a fatality. Even while teaching TapRooT®, we do not suggest that everything get a root cause analysis, so why the question mark next to “using an ACE … ?”
Simple, there is not one issue that I have been asked to review that had Causal Factors (behavior of people, equipment or process) that were “brand spanking new”. The only difference in the past with these known Casual Factors was the extent of damage or injury that occurred this time. So why were the previous Causal Factors not effectively analyzed or corrected?
Often I see the issue as not having a solid list of company specific issues known High Potential Issues (HPIs), which would then require a TapRooT® level root cause analysis regardless of the extent of cost or if there is no injury. A friend once told, “a near miss is a gift for what should have happened!”
Here are some HPI examples dependent on industry:
1. Uncontrolled Vehicle Movement
2. Fall of Equipment, Material or People
3. Near Miss with Controlled Vehicle
4. Loss of Control of Moving Loads
5. Out of Specification Product (upstream or downstream)
6. Loss of Control of Sterile Environment
By the way, every one of the examples above ended up being a Causal Factor for a serious problem. So take a little time and Go Out And Look (GOAL) and observe the daily activities that require control of energy, product or environment and build your list of HPIs. Then investigate them with TapRooT® when they occur.
After all, do you really want to wait until a major accident happens to refresh your knowledge of our process? Heck, if you catch it early enough with HPIs, you will never have to get to that major incident.
If I had a dime for every time I’ve heard the statement, “TapRooT® is a Root Cause Analysis Software … ”.
So I thought I would let some our customers speak on the topic when they were asked the same question on LinkedIn.
Dan Hughes” “I am trained and I use TapRooT®. Compared to my colleagues I can reach the root cause or causes more quickly and more accurately. They use Keppner Trego (KT) and Apollo. I find TapRooT® very effective, very user friendly, easy to review and correct if you wander … I have used 5 Why’s, KT, Fault Tree and a few others but I am sold on TapRooT® and I don’t see myself using anything but TapRooT® in the future. Not long ago I was sent info from over 4K miles away. My colleague shared info by phone and email and I did the TapRooT® timeline for him and reached a root cause(s). My colleague reported to corporate using the timeline we developed and he presented our conclusions. It is the first report at the corporate level that was accepted without question. I had great support from my TapRooT® instructor who reviewed the materials we put together. TapRooT® instructional staff are outstanding and if they say ‘call me’ they mean it and they respond.”
Randy Bennett: “TapRooT® is a process that happens to have a software program to assist in capturing information and investigation data / status of progress … I have used the process since 1996 with excellent success for a Major E&P Company. I have never conducted a serious investigation with the software first; I use the hard copy (sticky notes) for the initial SnapCharT®s and then transfer … it works much better due to the changes that can occur initially. The really crucial advantage of the TapRooT® system is the repeatability of the findings from team to team; other methods such as 5 whys and similar methods are not repeatable and results are based on the team’s experience and make up. When we believe behaviors are an issue we will add A-B-C analysis (BST Method). The other aspect of TapRooT® is it’s based on identifying process issues and problems and not fault finding which is why it has a good reputation with management and field personnel.”
Now the question is: Where did the software comment/idea get created?
1. People wanting software to perform an investigation do an internet search, which shows that we do have investigative software to support the process itself.
2. Competitors sell software that is not based on a true process and compare us to them as software.
3. People see someone investigating an incident with them using our software.
4. People receive an incident report created in our software.
This however is like saying mathematics is a calculator because someone was using it to solve a problem.
So why elaborate on this topic? Simple:
1. Make sure people unfamiliar with TapRooT®, understand how it actually helps you investigate a problem with or without the software program.
2. Describe where our software actually helps you in the TapRooT® Process.
Here is an excellent article explaining what makes our process unique and not just software: 7 Secrets of Root Cause Analysis (7 Secrets of Root Cause Analysis)
When should you use the software to compliment or support the TapRooT® Process?
1. Improved Time Management of Your Investigators
A timeline called a SnapCharT® must be developed during the investigation. Key data such as Causal Factors, once identified, are sent directly to the Root Cause Tree® Analysis section and a tree is created for each one.
The TapRooT® Software walks a trained investigator through the 7 Step Process for investigations including: Logging your investigation data; mapping your sequence of events, finding root causes, developing corrective actions, and generating reports. Upon completion of each technique, the software takes the investigator back to the 7 Step Process to make it easier for investigators to see what they have completed and what they need to do next.
To perform a TapRooT® Investigation both our Root Cause Tree® Dictionary and Root Cause Tree® must be used. This requires flipping through sections of the dictionary manually to find what you need. When going through the Root Cause Tree® in software, a right click at any root cause pulls up the dictionary definition for that root cause and pulls up the Corrective Action Helper® to assist you in developing corrective actions for that root cause.
2. Investigation Due Diligence
Knowing that our memory is not very accurate, investigator root cause selections must be tied directly to the evidence found and must be documented. Without software, your company must develop spreadsheets or place facts in other programs that can be tedious and may allow for loss of data.
Built into the software Root Cause Tree® is the Analysis Comments section. With just a right click at your chosen root cause, you have a place to document your evidence. This is also vital because with proper documentation, this also gives the ability to audit and verify evidence findings.
3. Report Standardization
Our software produces Standard Investigation Reports that means key data is always listed in the same place on the report. This also means less time deciphering incidents reports.
With Individual Software Licenses, there are a few fields that are customizable. With the Enterprise Version of the software, our team can work with you when you implement our software to easily develop your companies custom reports.
4. Improved Implementation of Corrective Actions
Many of our clients choose one of two options here: 1) Save the Corrective Action Report as a .pdf and attach it to their existing program; or 2) Use our program to track the progress of their corrective actions through to completion. The Multi-User Enterprise version allows emails to be sent for assigning and tracking corrective actions.
5. Single User versus Multi-User Software
When you have many trained employees, we recommend you get the Multi-User Enterprise version to centralize all reports and reduce duplicate data. Also, this allows your employees and managers to do searches in the database to see how investigations are progressing as well as to look for trends in root causes. It also allows you to set up periodic reports for managers and to set up custom incident reports.
As a TapRooT® Instructor and Incident Facilitator, I hear these phrases occasionally:
We did our investigation and could not find any root causes.
Nothing was done wrong, so we have no corrective actions to implement.
I hear these phrases often from people not familiar with the TapRooT® Root Cause process. But sometimes … even us experienced users need a little nudge. So if you get stuck …
1. After identifying the worst thing that happened or the specific problem that you need to focus on, ask a few key questions up front based on your industry:
Manufacturing: What were the quality escapes?
EHS or Process Safety: What were the uncontrolled energies and exposures?
Project Planners: What were the bottlenecks or gaps in the project?
Medical: What were the patients’ hazards or exposures?
Note: We are not brainstorming here nor are we troubleshooting yet, we are just defining the problem.
What error allowed the bacteria to be there or grow too large?
What error allowed a safeguard to control the bacteria to fail or be missing?
I will not go through all the questions that you learned to ask, but just asking these first two questions tells us that we need to track the bacteria in our timeline, look for evidence and take samples of bacteria growth.
This technique works, because it forces the facilitator to break down the problem. This incident (in the example above) could have easily been a ventilator-associated pneumonia issue. Bacteria, Bundling and Secretions are just some of the hazards and exposures that had to be present for this incident to occur, and they need to be in our timeline, (we call a timeline a “SnapCharT®”).
3. Once we map out the events in our SnapCharT®, define our Causal Factors, and perform our Root Cause Analysis, we may find that no one broke a rule or policy and still allowed the bacteria to grow. The simple answer is that processes were not adequate.
Yes I know that some hazards are very difficult to control, (like fleshing eating bacteria from a lake that enters through a cut on a human body), but once identified, we still use the safeguard analysis process to increase hazard risk reduction for the future.
Also, during the root cause analysis, please ensure that you do not lightly review the human engineering basic cause category. Some of your root causes for seemingly mysterious issues are identified here.
I hope this helps get your investigation jump-started.
Your TapRooT® Root Cause Analysis Training occurred a while ago … what can you do?
Depending on when you took your TapRooT® training here are a few Public Course Options to get back into your TapRooT® mind:
1. Take another 2-Day TapRooT® Incident Investigation and Root Cause Analysis Course. You will benefit from a refresher and get to see additional investigation skills that we have introduced.
2. If you have never been introduced to our equipment and system troubleshooting course, you should register for our 1-Day TapRooT®/Equifactor® Equipment Troubleshooting & Root Cause Failure Analysis Course.
Important: You can only attend this 1-day course if you have previously attended a 2-day or 5-Day course taught by us.
3. If you took a 2-day course previously, take the 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training. You get a refresher plus learn about all the optional tools that we teach. You also become a mentor or lead facilitator for your company. Did I mention that you also get a discount?
If you have at least 10 peers in the same boat as you, we can set up an onsite course for any of the options above!
Here are a few tips that you can read right now to get you back on track:
Of course, if you need assistance and a jump start now, call our office at 865.539.2139 and ask for one of our instructors. We love to help!
Often when teaching Onsite TapRooT® Root Cause Analysis Courses, we get to teach two different companies in back to back courses. Doing this actually saves our clients on instructor airplane travel costs. Last week in Trinidad, I had the opportunity to work with IPSL (pictured above) and Tucker Energy (pictured below).
Just some of the Testimonials after the final exercise:
“Very engaging, eye opening! Be neutral!” (bias kills an investigation every time the students learn)
“Today’s session was detailed and gave a clear idea on how to investigate an incident totally and fair.”
“The course highlighted that we used the wrong approach for incident investigations in the past.” (They found conflicting evidence that had not been verified yet)
“Very good hands on approach; assistance from the facilitators (instructors) was very helpful throughout the course.”
I am a sucker for a 1948 Indian Chief motorcycle. So I thought … what a great opportunity to talk about Human Factors Design and show off a little nostalgia. The topic of today is the Suicide Shifter.
The Suicide Shifter is located on the left side of the fuel tank and was used to shift gears while riding. Called a Suicide Shifter because you had to take your left hand off the handle bar grip to shift it.
So the question for you today is how many equipment control designs used today at your work area are not placed in the safest area to use while operating?
In the human factors world there is an acronym, HCI. This stands for Human Computer Interaction. A subset of the human factors field, HCI is where computer software programers meet the computer user’s needs by design BEFORE they sell it. So…… have you seen the marketing and pre-beta download for Windows 8?
- Will the new version frustrate new or experienced window users? or both?
- Will Microsoft help experienced users transition?
- How will Microsoft help experience users transition (if they do) to the new version?
- Will software developers who have software used on Microsoft help transition their existing customers?
Windows 8 Developer Preview is available for you to try now: http://msdn.microsoft.com/en-us/windows/apps/br229516
In our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training Course and in our TapRooT® book, TapRooT® Changing the Way the World Solves Problems, we introduce the Critical Human Action Profile (CHAP) tool to help collect more information to analyze any type of problem at the process task level. I like to call this looking at a problem at the 1 foot level as opposed to many investigations that analyze their problems at the 100,000 mile view only.
The tip here, however, is “why wait for a problem to use CHAP?”
Identify, Evaluate and Improve before it is too late!
Using a very over simplified list of procedure steps on How to Remove a Fuel Pump, found on the internet, I would like to show you how to use CHAP proactively to improve Safety and Quality during a task.
WARNING: The steps listed in the demonstration example below on removing a fuel pump shall not be used. They are incomplete and not necessarily accurate.
Where to start? First off you already perform JHA, AHA, JSA, Observations…. So Going Out and Looking (GOAL) should not be new or require a lot more additional resources. The difference is that you will be utilizing your resources more efficiently.
1. Start by identifying a task performed by employees that are critical to:
a. Customer/client satisfaction
b. Product Quality
c. Project Timeliness
d. Employee Safety
e. Customer Safety
f. Environmental Exposure
2. Once the task is identified, list the steps to be performed like listed in the image below.
Note: Do not forget to use the Basic Cause Category Procedure in our TapRooT® Root Cause Tree to look for missing best practices as well when listing the steps.
3. Identify each step of the task that is critical to the items listed in step 1 criteria of this article.
Which steps listed above for the fuel pump removal do you think would be listed as critical?
4. For each critical step in the task perform a CHAP Profile.
Note: For each of the items listed below, do not forget to include the Best Practices listed under the Human Engineering Basic Cause Category in our TapRooT® Root Cause Tree.
Watch the chimpanzee vs. human child in a learning experiment.
Here is the video link: http://youtu.be/nHuagL7x5Wc
We are all trained, or learn, by trial and error on how to use equipment or how to use it “properly”. What happens when you get a better “understanding” of how the equipment works? Here are some of the choices that we could make:
1. Ignore the previous training and just get the prize (work done faster, like the chimpanzee)
2. Continue the rules that you learned or were trained to do (at least in front of the bosses like the children).
3. Stop and ask what’s up?
4. Stop using the tool all together and do not tell anyone.
Often the previous training and experience overrides the new operation steps needed … ever been totally frustrated every time someone changes your computer’s Microsoft Windows version? And no, training by itself does not override experience, practice and repetition does!
I had a discussion not too long ago that OSHA forklift training requirements were met when people were retrained after changing forklifts. Unfortunately, the controls worked exactly opposite on the new forklift and the quick review did nothing to override the past knowledge and muscle motor memory.
Just something to think about when you think “Great Human Factors.”
Is the Human Factors Design at it’s best or worst?
However often would you need to change the windshield?
What if you wanted someone else to drive the car?
Should passengers be able to see out the windshield too?