Taproot

As an ex-aircraft mechanic and a “sometimes gotta work on my own car” mechanic, I have in the past borrowed or made some of the tools pictured below. The questions remain:

Wrong Tool?

Bad Access by Design?

Mechanic’s Ingenuity?

Or a little bit of them all?

Finally, ever have one of your modified tools bite you back?  Share your stories in the comment section.

The picture above is from a airport jet bridge in Frankfurt, Germany.

If you look at the ground level you can just make out the wheels that carry a very heavy load.

You might also notice that they have a guard to keep people away.

Why did I notice this?

Because last year at the Knoxville airport a Delta employee was run over by these wheels. It totally crushed one leg.

There was no guard when the accident happened. Instead, Delta had a policy that all employees should be clear before the jet bridge was moved and stay clear while in motion.

Obviously, this administrative control (SPAC in TapRooT® lingo) failed (SPAC Not Used).

However, a physical guard might be a better safeguard than an administrative control.

Next time I get a chance I will have to see if the corrective action from the Knoxville accident was to add guards on the Knoxville jet bridges.

The picture above is from a airport jet bridge in Frankfurt, Germany.

If yopu look at the ground level you can just make out the wheels that cary a very heavy load.

You might also notice that they have a guard to keep people away.

Why did I notice this?

Because last year at the Knoxville airport a Delta employee was run over by these wheels. It totally crushed one leg.

There was no guard when the accident happened. Instead, Delta had a policy that all employees should be clear before the jet bridge was moved and stay clear while in motion.

Obviously, this administrative control (SPAC in TapRooT® lingo) failed (SPAC Not Used).

However, a physical guard might be a better safeguard than an administrative control.

Next time I get a chance I will have to see if the corrective action from the Knoxville accident was to add guards on the Knoxville jet bridges.

40 Years of Research Unlock the Value of Hands-On Training

Psychologists analyzed over 40 years of research across 16 countries to find the relationship between hands-on training and job performance. Burke et al. found that hands-on training was more effective than classroom style training for tasks that carried a high risk of death or injury. In lower-risk tasks, however, classroom style and hands-on training were equally effective.

The “Dread Factor” is the Key

They explain this phenomenon with a “dread factor,” the employee’s knowledge of the high risk of the task he or she is performing. The authors conclude that hands-on training should be considered for high-risk industries, even if it does cost more money. These realistic simulations heighten the “dread factor,” making a person more likely to remember training and adhere to safety standards.

To see the full 25-page report click here.

Improve Training and Increase Risk Perception

This study best applies to the Training category in the Root Cause Tree®. Look under Understanding Needs Improvement: Practice/Repetition Needs Improvement. A problem with the “dread factor” could be due to poor learning objectives or instructional style as well. However, the trainee really needs practice so he or she understands the full risk of the task, as well as the procedural steps. If the training is “not repeated enough so that information [can] be learned and skills sharpened”, or “more simulator time [is] needed for proficiency”, then your facility may want to address this issue.

Ninth Time is the Charm

Can you think of a few employees who don’t understand the full risk of their tasks? Re-train them and revise the training program for new employees. Practice and present the procedure—including the risk—nine times total, as “…presentation of material up to nine times in a variety of settings and instructional techniques is commonly needed” (Corrective Action Helper® Guide).

For more information on training tips, look at Training in Organizations: Needs Assessment, Development, and Evaluation, Third Edition (1993) by Irwin Goldstein, published by Brooks/Cole Publishing Company, Pacific Grove, CA.

Want to learn more about our 7-Step Process? Click Here and learn how to find and fix real root causes with TapRooT®.

Photo Courtesy of:

Here a quote from a report by WESH Orlando:

“The National Transportation Safety Board says the death of a monorail driver in July 2009 was the fault of a fellow Walt Disney World Resort employee.”

Here’s is what the NTSB report said the “Probable Cause” was:

“The National Transportation Safety Board determines that the probable cause of the July 5, 2009, collision between two monorails at Walt Disney World Resort in Lake Buena Vista, Florida, was the shop panel operator’s failure to properly position switch-beam 9 and the failure of the monorail manager acting as the central coordinator to verify the position of switch- beam 9 before authorizing the reverse movement of the Pink monorail. Contributing to the accident was Walt Disney World Resort’s lack of standard operating procedures leading to an unsafe practice when reversing trains on its monorail system.”

Here’s a link to a video on the Orlando Sentinel site that shows the new way that Disney controls the monorail:

http://www.orlandosentinel.com/the-daily-disney/os-disney-monorail-crash-report-20111031,0,4139169.story

Here’s what the Orlando Sentinel had to say about the cause of the accident:

“A lack of adequate safety protocols at Walt Disney World contributed to a 2009 collision between two monorail trains that killed a 21-year-old resort employee, federal investigators said Monday, concluding an investigation that took nearly two-and-a-half years.”

Here’s a You Tube video recreation of the accident:

What do you think?

Did the NTSB find the root causes of the accident?

What can you learn from the report and the accident that would impact operations at your company?

I attended the Milken Conference held in LA. Gary Becker, Nobel Prize and Presidential Medal of Freedom winner, explained the theory of human behavior and rewards.

Once again, the material we teach in TapRooT® Courses was confirmed through a different science – economics.

His economic theory is that people act because of the rewards built into the system.

So, if your boss with an MBA starts blaming folks after an incident – especially if rules were broken and the “enforcement” system isn’t working as intended, tell him/her to look into the research of renowned economist Gary Becker.

People are rational … The rewards system is broken.

TapRooT®’s Corrective Action Helper® can help you fix it.

For more information about TapRooT® Training, see:

www.taproot.com/courses.

After an intensive but fun two days of work invested already in the 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training (as seen in the photos above), the students needed a duck break at the Peabody Hotel in Orlando.

Here’s the story about the solar blast that could cause grid, communications, and GPS problems:

http://online.wsj.com/article/SB10001424053111903454504576490641577134256.html?mod=rss_US_News

From the articles:

“Cleanup crews in Idaho have finished clearing honey and an estimated 14 million bees that got loose after a delivery truck overturned on a highway.

Fremont County Sheriff deputies say several workers were stung during the first few hours of the cleanup Sunday.

And some observers told The Post-Register about seeing a strange black cloud and roaring noise above the spill area before realizing it was a massive swarm of bees.”

To make matters worse… more bees not contained may mean an increase of more bears.

http://news.yahoo.com/truck-spills-14-million-bees-idaho-highway-142147287.html

http://www.dailymail.co.uk/news/article-2013995/Truck-spills-14-MILLION-bees-honey-Idaho-road-crash.html

Day One of our 2-Day TapRooT® Incident Investigation and Root Cause Analysis in Calgary, Canada.

Kevin Palardy, one of our Canadian based instructors, introducing the SnapCharT® Process. As you can see below, the course is not just a sit down and lecture course… you have to apply what you learn on each of the 7 Steps learned.

158 lives were lost on May 22nd, 2011, when Air India Express Flight 812 crashed after not aborting a landing. According to an article by Indian Aviation News,

“The court of Inquiry determines that the cause of the accident was Captain’s failure to discontinue an “Un-stabilised approach” and his persistence to continue with the landing, despite three calls from the First Officer to “go-around” and a number of warnings from the EGPWS”

According to the article being reviewed, the Government of India had inserted vide GSR No. 168(E) a very important rule to ‘The Aircraft Rules 1937′, which govern everything aviation in this country On 2009 March 13.

The rule:

75A. Reopening of Investigation – Where it appears to the Central Government that any new and material evidence has become available after completion of the investigation under rule 71, 74 or 75, as the case may be, it may, by order, direct the reopening of the same.

The article then references the findings that should reopen the case:

Here is a list of new and material evidence:

1. The fact that a huge portion of the wreckage was taken away from the crash site by locals and was sold as scrap metal. What the Court of Inquiry was inspected and studied (if at all they had done any study) was the remaining wreckage.

2. The reconstruction of the wreckage was never actually done by the CoI. The image of the reconstructed wreckage included in the report was a computer generated one.

3. While testifying before the court of Inquiry at Mangalore airport, Six survivors of the crash were made to answer a totally biased and misleading question by the CoI. The question was, “Do you think the accident occurred because of the fault of the pilot?” This was in plain violation of Rule 7.2.1 of the Manual of Accident/ incident investigation: ‘ The investigation of aircraft accidents and incidents has to be strictly objective and totally impartial and must also be perceived to be so’.

4. The “Hard Landing” circular issued by Air India is a major contributor to the accident. The CoI had chosen to ignore this vital fact.

Of course some of the issues from the article’s author stem from the investigation itself and are items that we teach our clients to avoid:

1. Spoliation of Evidence

2. Interviewing in a less effective manner which could have induced bias…. (leading the interviewee)

3. Focusing on what TapRooT® would define as a Causal Factor only and not the root causes for the Causal Factors

So the question for today’s Monday Lessons Learned is when would you, or when have you reopened an Investigation?

For More Reading:

Indian Aviation News 6/14/11

Indian Aviation News 6/08/11

If you have ever sat in a TapRooT® Root Cause Analysis Course or Summit, you know that the transfer of knowledge and support from our instructors does not stop when the session ends. To help guide the next steps of continuous improvement, Mark Paradies and Linda Unger added Appendix C in our TapRooT® book, TapRooT®, Changing the Way the World Solves Problems. The tip today comes from “Topic 3: Knowledge” on page 461.

To ensure that TapRooT® Training is not just a one time event, we provide and suggest different knowledge opportunities:

• Technical tips and root cause analysis newsletters.

• Specifically designed on-site training for gaps identified as additional needs in your trending and proactive assessments.

• Feedback for our investigators through our Advisory Board and one-on-one.

• Advanced courses during our Pre-Summit (from Human Behavior, Culture Change to Equipment Troubleshooting, just to mention a few courses).

• A Summit for system experts, which include our clients, to share best practices from multiple industries.

• The TapRooT® Users and Friends LinkedIn Group where you can ask us or your peers questions.

The key concept to using and understanding knowledge is to identify the who, what, how and when as it relates to training. In our 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training, key investigation facilitators are introduced to the ADDIE process (Analyze, Define, Develop, Implement, Evaluate). The only way do Analyze and Define is to go out and look at the tasks that people need to perform in order to be efficient. With that in mind let’s start with the following people:

1. Investigators
2. Certified Instructors
3. Managers
4. Improvement Program Leader (Owner/Champion)
5. Coaches/Mentors/Facilitators
6. Hands on Employees/Operators
7. Top Manager (Sponsor)

Start by identifying their core task and skills required to perform the tasks. You may find cross-over of tasks which is not a problem. Actually it gives you more resources to share in times of need.

Once you identify the tasks and possible skills, assess the level of knowledge needed. Here is a template from my U.S. Air Force training Matrix in our CFETP:

Task Performance Levels

1. Can do simple parts of the task. Needs to be told or shown how to do most of
the task. (Extremely Limited)
2. Can do most parts of the task. Needs only help on hardest parts. (Partially
Proficient)
3. Can do all parts of the task. Needs only a spot check of completed work.
(Competent)
4. Can do the complete task quickly and accurately. Can tell or show others how
to do the task. (Highly Proficient)

Task Knowledge Levels

a. Can name parts, tools, and simple facts about the task. (Nomenclature)
b. Can determine step-by-step procedures for doing the task. (Procedures)
c. Can identify why and when the task must be done and why each step is needed.
(Operating Principles)
d. Can predict, isolate, and resolve problems about the task. (Advanced Theory)

Subject Knowledge Levels

A. Can identify basic facts and terms about the subject. (Facts)
B. Can identify relationship of basic facts and state general principles about the
subject. (Principles)
C. Can analyze facts and principles and draw conclusions about the subject.
(Analysis)
D. Can evaluate conditions and make proper decisions about the subject.
(Evaluation)

By identifying the who, what and how, then we need to figure out where your TapRooT® Root Cause students will get to the performance levels needed to reduce or prevent problems (Incidents).

Biggest key here is that you will need to assess the skills of each team member listed above; where it starts:

1. Good Root Cause Analysis starts with a robust and usable method taught by knowledgeable facilitators; do this by sending them to the appropriate course. We teach and then give hands-on exercises; we follow up by working one on one with students as needed.

2-Day TapRooT® Incident Investigation and Root Cause Analysis
5-Day TapRooT® Advanced Root Cause Analysis Team Leader Training
3-Day TapRooT®/Equifactor® Equipment Troubleshooting & Root Cause Failure Analysis

2. Develop in-house mentors/facilatators and assign those mentors as needed to help newly trained individuals. Some even get certified to teach in-house.

3. Look for systemic issues and identify additional knowledge and performance gaps. Decide who in the list above may need to attend one of the pre-Summit or Summit Activities.

4. Develop in-house group sessions to discuss lessons learned.

5. Schedule refresher training to give competency levels high.

Good luck on your quest for knowledge!

Government Technology published an interesting summary of two serious computer outages that occurred in the State of Michigan.

Whenever I read about such outages, I think of the work of TapRooT® User Gerald Starling back in the 1990′s while he was at Bell South. He was one of the first people to apply advanced root cause analysis (TapRooT®) to network reliability problems after he heard about TapRooT® from a consultant at AT&T (sorry – don’t know his/her name).

Soon after, another company focused on high reliability computer operations, Tandem Computers, adopted TapRooT® for analysis of reliability issues.

Also, several government agencies adopted TapRooT® to analyze computer security issues (hackers and such).

But multiple mergers, the tech crash, and secrecy about technology issues has made it difficult to spread the word about the application of root cause analysis to computer network reliability issues.

Maybe the time is right for the spread of advanced root cause analysis across the computer industry to help improve network reliability?

If you are in the network reliability and security business, I’d suggest attending a 5-Day TapRooT® Advanced Root Cause Analysis Team Leader Course to learn the TapRooT® Techniques. Plus the course includes the patented TapRooT® Software (individual user edition) for each participant.

You’ll have to do a little translation (the examples in the class are not network reliability examples – the rest of the attendees wouldn’t understand them if they were) but others have told us that the learning is directly applicable to security and reliability issues of computer networks. See for yourself. Attend one of the courses listed at:

http://www.taproot.com/courses.php?d=2

Just checking to see if TapRooT® Users got their Root Cause Network™ Newsletter today. I think you will find the Six Common Culture Problems story on page one both interesting and helpful when assessing culture issues.

Here’s a copy for download if you didn’t get yours by e-mail:

Just click on the document above to download it.

Really bad weather yesterday in Knoxville. Here’s what the hail did to my Q7:

The roof at the office (picture of the edge where you can see where the hail went through the shingles):

Ed put 2-inch chunks of hail in his freezer. His car was damaged too.

And Dave’s house had an entire outside wall “shredded” by hail.

TapRooT® Users: Does this qualify as a “Natural Disaster”?

A great group of students for Kevin Palardy and I to work with and teach. With 32 being the maximum for a course, we had 7 on the waiting list. Make sure you are not on the next waiting list.

See our upcoming courses here:

http://www.taproot.com/courses.php

The mine is in Mullan, Idaho, a historic mountain mining town of 840 people in Idaho’s Panhandle. Baker said additional equipment was being flown in so crews could use a front-end loader remotely to dig away material clogging the tunnel.
(more…)

“The world’s largest passenger aircraft clipped a much smaller commuter plane on a dark, wet tarmac at New York City’s Kennedy Airport, spinning it like a toy as hundreds of passengers sat in both planes. No one was injured.”

See the video here: http://news.yahoo.com/video/us-15749625/amateur-video-shows-air-france-collision-at-jfk-24877570

Alcohol or Juice?

Interesting article today titled: “Restaurant to retrain staff after mixed-drink mixup”

On Friday, Taylor Dill-Reese went to an Applebee’s in Madison Heights, Michigan, where — among other things — she ordered her 15-month-old son Dominick an apple juice.

What the little boy apparently got instead was a margarita. His mom told WDIV-TV that she only realized something was wrong when Dominick “kind of laid his head on the table and dozed off a little bit and woke up and got real happy.”

The little boy reportedly began hailing strangers, too.

According to the article the restaurant stated, that it would begin to serve apple juice to children only from single-serve containers at the table and would “retrain all severs on our beverage pouring policy, emphasizing that non-alcoholic and alcoholic beverages must be stored in completely separate and identified containers.”

…. for our TapRooT® trained investigators, can you think of any other root causes than training?
(more…)

This was a simple mistake that led to a serious injury.

See the report by the UK RAIB at:

http://www.raib.gov.uk/cms_resources.cfm?file=/Bulletin%20(Foxfield)%2001-2011.pdf

The Chief Counsel has released a more detailed report about the Deepwater Horizon blowout. See it at:

http://www.oilspillcommission.gov/chief-counsels-report

So far I can’t get the whole report to download, but I can download the separate chapters. Once again, a massive report … This time over 350 pages with animation of certain key technical issues.

There are four best practice entries published on this weblog in the success story contest (view all entries here).  Click the “Like” button for the entry you think should win an Apple iPad. All votes cast before Friday, March 4 at 6:00 p.m. EST will be tallied for the winner.  In the event of a tie, the in-house instructors at System Improvements will cast the tie-breaking votes.

Entry #2:  Stopping Future Accidents by Correcting Problems That Did Not Cause The Accidents Being Investigated

Submitted by: James Watson, Regional Specialist, System Safety Branch
FAA, Alaska

Challenge

TapRooT® investigation often identify actions and conditions that didn’t cause the actual accident being evaluated but that could be significant and, if not corrected, could combine with other factors to cause a future accident.

Action

These factors that the thorough analysis of TapRooT® helped identify are included in the presentation to management at the end of the talk (after the root cause analysis and corrective actions have been reviewed). This review includes explaining and discussing each of these potentially adverse factors with management. At a minimum, management is aware of these potentially adverse factors and the review often leads to discussion of additional corrective actions to address these issues.

Result

Accidents that might have happened are avoided by implementing corrective actions for problems identified during a root cause analysis that didn’t cause that accident but could have cause additional accident and were corrected by proactive corrective actions.

I few from Milan to Amsterdam yesterday.

It was a direct flight.

I got to the airport and checked in with 4 hours to spare.

The plane was lightly loaded.

Then, we had a 1 hour 30 minute gate hold due to weather because it was windy in Amsterdam (such is modern air travel).

We arrive 90 minutes late.

Now the bad part.

When I arrived in Amsterdam my bag didn’t come out.

I waited for a while to make sure it wasn’t the last one. 20 minutes slipped by.

I always stand near where the bags come out to make sure that nobody mistakenly takes mine. (I’ve stopped this from happening twice in my flying career.) I know my bag never came out.

Then I went to get in line to report the problem. There were about 50 people ahead of me. Another hour slips away.

I finally saw a person. They thought … it can’t be lost. It must have gone to the transfer station or perhaps one of the places where bags fall off the line. Or maybe you didn’t wait long enough. I’ll have some people check. I started filling out the paperwork while they searched. 30 more minutes slipped away from my life.

They also checked the computer. No note that any bag failed to make the plane. (Isn’t it part of modern airline security to make sure that your bag flies with you?) No note on the computer. It must be in Amsterdam – let’s check all the usual suspects again. 15 more minutes slip by.

Finally, they decide it is lost. They accept the form and tell me it will probably be on the next flight. They’ll bring it right over to my hotel when they get it and leave it at the front desk and tell them not to wake me if it comes in tonight late.

I think, “It is already late.”

“When is the next flight?”, I asked? They replied, “I’ll have to check.” … “Sorry – not until tomorrow, 9 AM. But we will update the bag status on-line (the internet!) as soon as we know anything and that will automatically text your cell phone.”

I check the baggage loop one more time on my way to customs. No bag.

The next morning I went to breakfast and checked with the front desk. No bag yet. And no text message.

After breakfast I decided to check the bag status on-line. Bag status was “unknown.” But there is a reassuring note that if your bag status is still unknown after four days, there is a special phone number to call. I begin to wonder … “If they have a special number, how many bags are never found?” I remember the 60 minutes story about the cavernous warehouse in Alabama for lost bags.

I decide it’s a good time to call the regular phone number and see what they say.

They check their system. Good news. The bag is scheduled for the 4 PM flight. I wonder, what happened to the 9 AM flight? What if I really needed my cloths? What if I was departing on a cruise or on to another international location?

I wait and hope.

By 7 PM, the bellman finally brings my bag to my room. That’s almost exactly 24 hours after we were suppose to land.

I was going over this in my head and thought …

This is a root cause analysis opportunity!

Why?

1. First … Think of the time wasted.

a. Over two hours of my time was spent just reporting the lost bag.

b. Some unknown amount of airline employee time was spent  dealing with me, looking where bags could get lost (is says something that they know places to look), filling out paperwork, updating computer records, dealing with my call, and getting the bag delivered.

2. Second, I went a day without a bag. This could have been a minor disaster. Even though it wasn’t a disaster, it did leave me an unhappy customer. How many other unhappy customers like me are they creating every day?

Luckily, I travel prepared. This preparation is because I EXPECT them to lose my bag. This is a normal part of the frustration of flying. One more reason people drive if the trip is short. (I actually was thinking about a train trip from Milan to Amsterdam. I could have made it faster than my bag did flying.)

3. Third, is this a security violation? If making sure that the passengers bag travel with the passenger is a part of modern security, certainly this is a security failure.

Imagine how many future problems could be avoided if they started treating every lost bag as a customer service incident that needed to be investigated and reported to the CEO? I bet in a mater of weeks, or perhaps months, the number of  “lost” bags for no good reason (like mine) would be ZERO.

The few remaining lost bags due to really tight gate connections (yes, people can run faster than bags can be delivered) would be be a very managible number and even those might be reduced.

What problem could they work on next?

What about delayed flights? Alaska Airlines did this and showed major improvements!

Bagage damage?

Plane damage?

Worker injuries?

Weather related delays?

Air traffic delays?

Security errors?

Long lines at the baggage counter?

Long lines at the ticket counter?

Slow baggage delivery?

All of these are fixable problems. They need advanced root cause analysis (not just stupid 5-Whys.)  I’d bet many could be eliminated or at least dramatically improved at a low cost. And some might require some dollars to fix – but at what potential cost savings in the future?

Some could become a competitive advantage for a particular airline.

Others might improve the whole air travel experience.

Wow! Imagine the progress that could be made.

Root cause analysis is NOT just reserved for when planes fall out of the sky.

If only the airlines were interested in customer service!

Because no one is investigating this incident, flight delays, weather delays, air traffic delays … All these problems are just part of the fatiguing process of modern aviation. Which continues to get worse (a little more inconvenient all the time).

It will be no better when I fly out on Friday than when I flew in on Sunday.

ZERO quality improvement.

Please correct me if I’m wrong about this …

Question: What do the wonderful group of people above and the four words below have in common?

Product, Equipment, Vendor, Employee………..

Answer: Ways to improve quality of product internally and externally and make work tasks safer were discussed and evaluated during an on site 2-Day TapRooT® Incident Investigation and Root Cause Analysis Course held last week in New Jersey.

Kevin McManus (standing in back in Red with the group) and I had the pleasure to share manufacturing quality and safety best practices with a very passionate group of Rust-Oleum leaders in problem solving.