Archive for the ‘Root Causes’ Category
Monday, March 15th, 2010

The Sydney Morning Herald reported:
“Failure to test a cement casing at an oil well in the Timor Sea was a root cause of a blowout that caused Australia’s worst offshore oil spill, an inquiry has heard.“
See the article at:
http://news.smh.com.au/breaking-news-national/casing-test-failure-cause-of-oil-spill-20100315-q99q.html
It sure seems like there were many more “root causes” to me and that the analysis should have led to root causes that were much more in-depth. And it would be a big help if there was a SnapCharT® to help identify all of the Causal Factors.
What do you think?
Here’s the March 15 meeting transcript:
http://www.montarainquiry.gov.au/downloads/Transcripts/Transcript%20Montara%20COI_Day%20001_15-Mar-2010.pdf
And here’s the link to the Commission’s web site for more information:
http://www.montarainquiry.gov.au/index.html
Share on Facebook
Posted in Accidents, Current Events, Investigations, Pictures, Root Causes | No Comments »
Wednesday, March 3rd, 2010
While performing your PROACTIVE TapRooT® Root Cause Analysis, you observe a person loading a pallet with 10′ L x 6″ dia. 30 pound metal pipes by himself. He lifts 30 pipes an hour 3 times a day from a rack waist high to a pallet placed on timbers floor level. This task used to be performed by two loaders before recent lay offs, so you go to the Root Cause category of Excessive Lifting and see these two questions in the Root Cause Tree Dictionary:
* Was the issue related to excessive lifting or force to move an object?
* Did the task require repetitive motion (lifting, twisting, bending, etc.) that lead to a musculoskeletal problem?
Since this is a Proactive Assessment there are no issues yet, so your are asking what is the worse issue that could occur by the lifting movements above? Now what does excessive mean? What would excessive lifting, twisting and bending be? We could bring in an external Ergonomic Expert… or we can use a simple calculation ourselves first?
A simple calculator: http://www2.worksafebc.com/calculator/llc/liftlower/Default.htm

A little more technical: http://www.osha.gov/SLTC/etools/electricalcontractors/additionalreferences.html
NIOSH 1991 Lifting Calculator. Centers for Disease Control and Prevention (CDC), National Institute of Occupational Safety and Health (NIOSH), 208 KB ZIP*.

As you start doing these calculations, you should also see another Root Cause under Human Engineering start becoming very apparent: Arrangement / placement.
A question that comes to mind from the Root Cause Dictionary is:
* Did poor arrangement, placement, or situation of equipment, displays, or controls contribute to an issue?
So with these new found calculators and a better understanding of just a little bit of the Root Cause Tree Dictionary is this task a risk or not:
” You observe a person loading a pallet with 10′ L x 6″ dia. 30 pound metal pipes by himself. This task used to be performed by two loaders before recent lay offs.”
Post your response!
3 people like this post.
Share on Facebook
Posted in Human Performance, Performance Improvement, Pictures, Root Cause Analysis Tips, Root Causes, TapRooT, Website Info and Updates | No Comments »
Monday, March 1st, 2010
The Associated Press reported that Chief Electrician’s Mate John G. Conyers suffered a severe electrical shock and was later pronounced dead at Sharp Coronado Hospital.
The AP reported that the Chief was conducting “routine work” when he was killed.
Normally, Chiefs are supervising, not performing, work. And there is nothing “routine” about working with electricity aboard a ship. Complacency (routine) with electricity on a ship is a deadly combination.
One of my early shipboard jobs in the Navy was being the Electrical Division Officer aboard USS Arkansas (a nuclear powered cruiser). One of the first “performance improvement” programs I ever attempted was to re-instill respect for electricity and get 100% compliance with our lock-out/tag-out program to isolate and check dead all sources of voltage during electrical maintenance work.
People who work with any hazard (for example, electricity), tend to become complacent over time. I’m not sure if this happened on the USS Ronald Reagan, but it certainly is a problem that every manager/supervisor who supervises people who work with a hazard has to confront head-on.
Also, supervisors can frequently be tempted to do work and even take shortcuts to get a job done. This takes them out of their roll to supervise a job and make sure it is done safely and puts them into a dangerous situation where no one is looking over their shoulder to make sure the job is done safely. Once again, I have no evidence that this happened aboard the USS Ronald Reagan, but I’ll be interested in what the eventual accident report has to say.
What can we learn from this fatality BEFORE the investigation is even completed?
First, TapRooT® Users would be getting a complete picture of WHAT happened before they started analyzing WHY it happened. As you can see from my background, there are several problems that I would automatically look for. But, TapRooT® requires the investigator to look at the evidence first before starting the root cause analysis. They have to have a good, complete, accurate, detailed SnapCharT® before they identify the accident’s Causal Factors and find each Causal Factor’s root causes.
Second, TapRooT® Users have a systematic root cause analysis technique, called the Root Cause Tree®, that helps them be sure to check for the many different potential root causes of a problem (Causal Factor). The tree helps guide them to areas they may not have thought of to investigate before. It helps the investigator get beyond blame to find real, fixable root causes that, when fixed, can prevent future accidents.
Third, once the root causes are identified, TapRooT® has a module called the Corrective Action Helper® that helps the investigator develop effective corrective actions. This helps the investigator and management develop corrective actions that might be “outside the box” as far as their experience with corrective actions is concerned.
If you are a TapRooT® User, you have already learned these lessons (but it is good to have them reinforced).
If you are NOT a TapRooT® User, get to a TapRooT® Course NOW! Investigating smaller accidents, incidents, and near misses, as well as using the TapRooT® techniques proactively, can help you avoid major accidents and keep your employees safe.
For more TapRooT® information, including success stories from TapRooT® users, see:
http://www.taproot.com/about.php
And for more information about TapRooT® Courses, see:
http://www.taproot.com/courses.php
3 people like this post.
Share on Facebook
Posted in Accidents, Current Events, Equipment/Equifactor, Human Performance, Investigations, Root Cause Analysis Tips, Root Causes, TapRooT | 2 Comments »
Wednesday, February 10th, 2010
Posted in Courses, Pictures, Root Causes, TapRooT | No Comments »
Wednesday, February 10th, 2010
Here’s a medical example of 5-Whys. Tell me what you think…
A patient had the wrong leg amputated
1. Why Patient gave consent for amputation the night before the proposed
surgery to Registrar (who was not going to undertake procedure).
2. Why Amputation site marked with a biro (wrong leg).
3. Why Registrar unaware of hospital policy on amputation sites
being marked with a skin pencil and with bodily part being fully
visible to Doctor.
4. Why the department had no induction procedures for
new medical staff working in the department.
5. Why because “we’ve never been asked to”.
I’ll give my opinion after others have weighed in.
9 people like this post.
Share on Facebook
Posted in Investigations, Medical/Healthcare, Root Causes | 5 Comments »
Thursday, February 4th, 2010
Part 2, as promised, is a discussion on our TapRooT® Users and Friends LinkedIn Group. This begins with a question asked by Jason Laws, a plant manager and client. Join us if you want to get into this conversation or even just to contact Jason directly.
 
“Common Sense, the Root Cause Tree and a perceived recent lack in the up and coming work force that I have noticed”
My Production Supervisor asked me the other day if there was a place in the root cause tree for Common Sense. I actually said, I didn’t think so. That when we come across “a common sense” causal factor the root causes are usually identified in a Management Systems, Training, and Procedures…. I may really be wrong there….I hate to think it would be in work direction and I am running into more and more unqualified candidates.
Where I have struggled recently is with this very idea. Some things, it would never have occurred to me that we would need to drill training down to that level.
(It was common to police up your work site at the end of a job. When cutting you always cut away, use the right tool for the right job, there is very little in the world that is fit to bang on other than nails, use a chalk line and plumb bob to put up a line of pipe supports, place the labels on the totes level and neatly, check the breaker when the pump won’t start, ….These are just the ones that have come to mind but the list continues.) [ I don't put in don't dead head or run a pump dry. I've been doing this too long to expect that.]
That does bring me to one point I have tried. That is the Poke Yoke or “Error Proof” things. All pumps go in with a Power Monitor shut off now. You can’t run it dry or dead head it.
Still, I am with my Production Supervisor…and have had the same conversation with my Maintenance Director. Is there a place for Common Sense in the root cause tree? Am I the only one? Is the work force changing? Has Nintendo killed the opportunity to get the basic knowledge I and others did with chores, play, hobbies and jobs when were young? If so, what can be done? If the answer is drill spac, training and procedures deeper down into the core knowledge, how do you know how far and how to you identify knowledge that you take for granted that really isn’t.
Sorry, if that was a bit of a ramble, but the Production Supervisor really got me curious.
Thanks All,
Jason
Now the rest of the discussion from the TapRooT® Users and Friends LinkedIn Group
Response from: Christopher Vallee, Senior Associate and TapRooT® Instructor
ah…back to the when I was young, I walked up hill to and from work and pushed double the product you youngin’s push out and with no mistakes!
First off Jason you are right, many of the new employees of today have different skills sets than us old folks…. of course they would tell us it was “common sense” not to upgrade your software with out….etc… AFTER we locked up our computer. After all, didn’t we know this was not compatible for this computer.. duh!
At the same time the craftsman-apprentice relationship from years back no longer exists in many industries. Often it is the junior employee training the junior employee. The senior experienced employee is too busy fixing things to train anyone and often retires without documenting what s/he knows from experience.
The thought that any worker selection process, training process, and mistake-proofing remain stable and does not need to be flexible is a myth. Look at job descriptions, many are outdated, impacting the hiring process and training process.
First attack at the problem:
1. Identify the core skills needed by the employee to perform the core critical tasks for her/his job. Look up AMOD/ DACUM
2. Identify where the employees actually get the needed training. Often training programs get stuck looking at just missed appointments and regulatory required training, thus losing contact with the how the training impacts operations. (Where did the senior workers get their knowledge?)
3. Review the employee’s supervisor’s skill’s and training as well. Often new managers are hired based on needing to have a degree but never get the technical training listed above. The employee then asks the supervisor is this good enough…. how would s/he know?
4. If the training program is outdated (or just broke), then temporarily bring in a knowledgeable mechanic that has a retired and let them help revamp the new program with hands on training.
So if the employee needs a mechanical aptitude to perform certain jobs, then why was s/he not tested prior to hiring? After all, what happened to the unskilled in years past if s/he could not meet the aptitude need? S/he was either trained or kicked out the door.
After all, if common sense where the answer, you would not need the root cause tree either. So GOAL (go out and look) to find what the core skills and tasks are and then ensure that these requirements are met. Also see what you can learn from the new employees as well.
Posted 1 month ago | Delete comment
Response from: Kenneth Reed, Senior Associate and TapRooT® Instructor
You’re right, Jason. There is no Root Cause labeled “common sense NI” anywhere on the Root Cause Tree®. Just like there is no “attention to detail NI” or “operator error.” Although they initially seem like root causes, in reality they are just a convenient way to shift blame.
For example, if I told you the Root Cause was “common sense NI,” what would be your Corrective Action? How do you fix “common sense?” You can’t! Just like you can’t fix “inattention to detail” or ” operator error.” Therefore, we would default to poor Corrective Actions like, “Counsel the employee on using common sense when using a knife.” Completely useless Corrective Action, with almost no hope for better performance.
Instead, we need to look a little deeper at the problem. This is what Chris was alluding to above. Why did the operator slice his hand open? Was it really just a common sense problem? Or is there something we as management can do to prevent this issue?
That’s where the 15 questions, the Dictionary®, and the Root Cause Tree® come in. We need to ask ourselves the questions on the tree to dig deep enough into the problem. Instead of asking, “why didn’t this guy use common sense when cutting that wire, and cut away from himself?”, maybe we should ask:
- Was the worker fatigued, impaired, upset, bored, distracted, or overwhelmed?
- Was he using the right tool? Did we provide him with the right tool?
- Was the right person performing this job?
- Was this job really required in the first place?
- Do supervisors ever watch their people do this particular job? Why not?
- Would a supervisor have stopped this evolution before an injury occurred? If so, why didn’t he? If not, why not?
- Was the worker properly trained for this task?
- since I’m sure the worker did not intend to cut himself, what lead him to think doing the job in this manner was OK?
I could go on, but you get the point. When you find yourself saying, “This was just a dumb person, not using common sense, just a simple human error that I have no control over,” it’s time to step back and let the system work for you. Let the Root Cause Tree® and Dictionary® help you ask the right questions.
I also know that sometimes we think that people should already know these things. There are 2 possibilities:
1. The person really didn’t know (to cut away from himself)
- Therefore, this is a training issue
2. The person DID know, but chose to do it anyway.
- This is when my discussion above comes into play.
Hope this helps a little.
Posted 1 month ago | Reply Privately | Delete comment
Response from Jason:
Thanks Chris and Ken. One thing I have been trying to do, and encouraging my people to do (though finding the resources is always the challenge) is to use TapRooT® in audit mode.
I have worked the tree through these issues and developed corrective actions to account….mainly training, human engineering and Management systems.
My frustration can come from I just haven’t seen or anticipated the lack of knowledge in the first place to head it off at the pass. I am not even sure some of these issues would have occurred to me if I was putting together an audit SnapChart®.
Thinking on this thread, maybe the broader use of CHAPs might catch some of this. In a resource starved environment, I am trying to bring the tools I have to the best and most efficient use.
So, with GOAL. Maybe an Audit SnapChart®, the 15 questions, a CHAP and the Dictionary® I prevent some of these.
The struggle that remains is to overcome the blind spot of assumptive experience and figure out what needs to be trained for in the first place. What are the things we take for granted that really aren’t.
Once again. Thanks guys. I appreciate the feedback.
Posted 1 month ago | Reply Privately | Delete comment
Response from: Christopher Vallee, Senior Associate and TapRooT® Instructor
Music to my ears Jason…. “proactive CHAP”. When people are first introduced to Critical Human Action Profile, they look for critical steps in a task that if skipped, done wrong, or in the wrong sequence, could have caused the incident or made it worse. A proactive audit can look for steps that are critical to safety and process.
As far as the “blind spot for assumptive experience”, this is a generic issue as you have described it. So what system should be controlling the hazard of having unskilled employees on the shop floor (or in the field)?
Steps of the process:
1. Company or Contractor Human Resources hire employees that have the skills and capabilities to perform their assigned core tasks.
Problem: Metrics that HR are usually measured by for the hiring process are retention and number of new employees. No tie made to direct labor and rework.
2. Training department has a structured training program that uses classroom and hand’s on training for the cores tasks (process and regulatory).
Problem: Training is often measured by Number of missed appointments and upkeep of regulatory training. No tie made to direct labor and rework costs.
3. Shops have floating experts identified for employees who need a little help.
Problem: The new are training the new. The senior employees are too busy to.
So ask your HR department and your training department, how do they know that they have been successful when hiring and training a person? Most likely it will not be tied to operations ROI. .
Have senior employees attend training with new employees to help all do right.
Look at your critical job’s and tasks to determine what skills and capabilities should be covered for each person and then use GOAL to identify what is missing.
Posted 1 month ago | Delete comment
2 people like this post.
Share on Facebook
Posted in Human Performance, Performance Improvement, Pictures, Root Cause Analysis Tips, Root Causes, TapRooT | 1 Comment »
Thursday, February 4th, 2010
Here’s a 5-Why example from a recent posting on Business Week “Modern Analyst” saying how wonderful 5-Why’s is.
Issue: Employees did not receive their pay stubs on pay day.
· Why? Because the printing system failed the day before pay day.
· Why? Because the system could not recover from a hardware fault.
· Why? Because the system uses outdated hardware that has no automatic redundant backup.
· Why? Because the system hasn’t been replaced as it hasn’t been identified as a high enough priority to allocate budget to its replacement in the current economic climate.
· Why? Because the organization does not have an enterprise planning methodology that weighs the risks of current operational systems failing versus the criticality of these systems and the impact of such a failure.
Well, what do you think? Good or bad example?
What do you think of their “root cause”?
I’ll wait for others to post to share my ideas…
21 people like this post.
Share on Facebook
Posted in Root Causes, Topic of the Week | 12 Comments »
Monday, January 11th, 2010
In 2010, I would like to share lessons learned from TapRooT® User’s investigations.
Do you have an investigation of an accident, incident, near-miss, equipment problem, or quality issue that you investigated using TapRooT® and you would be willing to share lessons learned that you think apply outside your company, please send me the incident and your description of the lessons learned.
Sharing your generic lessons learned is a great way to help save lives across industries and around-the-world.
If you are concerned about legal issues, these investigations can be de-identified (no company information) so that there is nothing to worry about.
Generic lessons learned can be about techniques to perform investigations, new ideas for safeguards, new potential corrective actions, root causes that are common in different industries, or any solutions/lessons that you think might help others.
Use this link to contact me initially and I’ll forward my personal e-mail to you.
Each person that gets their lesson learned published will get a great looking TapRooT® Polo Shirt.
Thanks
Mark
Mark Paradies
President
System Improvements, Inc.
Share on Facebook
Posted in Accidents, Investigations, Root Causes, TapRooT | No Comments »
Wednesday, January 6th, 2010

Yesterday, I posted an article that discussed the advantages of using checklists in the medical profession (see this link). I thought I’d talk a little more about checklists, and how the use of checklists shows up on the Root Cause Tree®.
Let’s look at a reactive incident, where someone made a mistake while performing a common yet labor-intensive evolution. For example, a mechanic was starting up an expensive compressor, and he forgot one step, causing serious damage to the machine. He has done this evolution several times and is familiar with the equipment, but this time, one step out of 16 was missed. This is a very typical example, and your analysis must take into account many different possibilities. Happily, TapRooT® walks you through the analysis to make sure you don’t forget to check everything. The Root Cause Tree® and Dictionary® will have you check many potential problems (fatigue, equipment design, work environment, supervision, etc). However, I’d like to concentrate on:
“When should we expect to have a checklist in place?”
Looking at the Corrective Action Helper® under no procedure, we get some ideas concerning when a step-by-step checklist makes sense.
- First of all, if a new checklist had been in place, would performance have improved? Would this mistake have been prevented? Sometimes, the task is so obvious that having a checklist would not fix anything. If this is the case, don’t write a silly checklist just for the sake of having a checklist. For example, if someone forgets to wear his seatbelt, I highly doubt that putting a checklist in the cab of the truck telling the driver when and how to put on a seatbelt is going to make any difference. This is an obvious evolution, and other corrective actions (audits of seatbelt compliance, proper rewards for wearing seatbelts, consistent enforcement of the rule) will be much more effective.
Additionally, situations where other factors have made it easy for the operator to make the mistake (poorly designed equipment, excessively fatigued workers, etc) probably need these other issues addressed first, and then evaluate whether a procedure would also help.
- The Corrective Action Helper® also states that a checklist makes sense for high risk, high consequence tasks that must be performed correctly every time and require considerable short-term memory. Starting this expensive compressor is an example where checklist use should be considered. Other examples include: a. documentation of the work is required b. extremely infrequent evolutions c. tasks that must be performed under stress, like emergencies (both aircraft engines shut down due to a bird strike?)
What do you do when you have checklists, but people aren’t using them? You are now under the enforcement root cause, and the Corrective Action Helper® has a load of great information on how tackle this problem.
What are your thoughts on checklists? Do you have examples of checklists that helped? What about a checklist that was completely useless at your facility? Let me know what you think!
Share on Facebook
Posted in Investigations, Root Cause Analysis Tips, Root Causes | No Comments »
Monday, January 4th, 2010

When can an accident teach us something about investigating accidents? When the accident helps us understand the human brain and it’s limitations.
A story in Wired Magazine titled: “Accept Defeat: The Neuroscience of Screwing Up” explains how scientists often disregard information that conflicts with their “hypothesis” and how this is caused by the way the human brain is wired. I recommend reading the article to better understand this phenomenon.
But how does this relate to accident investigation? Here’s the answer…
Root cause analysis systems based on the theory of cause-and-effect require the investigator to develop a hypothesis and then look for evidence to prove or disprove the hypothesis. The theory of cause-and-effect requires the investigator to already understand the cause-and-effect relationships they are looking for. Thus, they can only find cause-and-effect relationships that they already understand.
However their brain, according to the research in the article, automatically keeps them from seeing evidence counter to their hypothesis or outside their experience.
That is why cause-and-effect root cause analysis techniques frequently have widely different results when used by different individuals looking at similar evidence. Each individual sees the “evidence” the way they want to see it to support their theory of the accident’s cause.
TapRooT® is not built on this cause-and-effect theory. Instead, it is based on unfiltered review of the evidence leading the investigator to develop a detailed explanation of what happened before they start to analyze why it happened. The evidence isn’t collected to verify a hypothesis. Rather, it is collected to expand the investigator’s knowledge and understanding.
Also, instead of depending on the investigator’s knowledge of cause-and-effect, TapRooT® has built-in expert systems to help the investigator see causes that may be beyond their current knowledge of the cause-and-effect relationships of the incident being investigated. These built-in expert systems help the investigator side-step their brain’s built-in simplifying mechanisms and find causes that they might not have originally suspected (or even understood).
Of course, any investigator can stubbornly hold to preconceived notions, but TapRooT® doesn’t fall into the “scientist’s trap” that this article talks about. It naturally helps investigators go beyond their preconceived ideas and previous experience.
That’s an important lesson learned!
If you don’t care about the brain-science behind why TapRooT® works and other root cause analysis techniques fail, that’s OK! Don’t worry … You don’t have to be a neuroscientist to use TapRooT®. We’ll teach you how to use TapRooT® in a 2-Day, 3-Day, or 5-Day Course and then you can take advantage of the advanced science that is invisible to the user but is built into the TapRooT® System.
What?!? You haven’t learned TapRooT®? Then now is the right time to get to a course and experience how TapRooT® can help you find root causes that you previously would have overlooked and develop corrective actions that you and your management will agree are much more effective. Don’t wait! Sign up for a course at:
http://www.taproot.com/courses.php
Share on Facebook
Posted in Accidents, Current Events, Human Performance, Investigations, Root Cause Analysis Tips, Root Causes | No Comments »
Friday, December 18th, 2009
A very interesting mistake that we have written about before (1) (2). Here’s more from CNN:
http://www.cnn.com/2009/TRAVEL/12/16/wayward.pilots/index.html
Another example of the trouble finding root causes when you don’t have the facts.
Share on Facebook
Posted in Current Events, Human Performance, Investigations, Root Causes | No Comments »
Tuesday, December 15th, 2009

Here’s a story from CNN:
http://www.cnn.com/2009/US/12/14/buffalo.crash.colgan.air/index.html
I can’t help but think that the company comments sound a lot like the comments from BP’s management after the Texas City refinery explosion.
Of course, management is right … Crew errors did lead to the crash. Planes seldom fall from the sky without crew errors. (Although there are notable exceptions.)
The real questions is WHY (what are the root causes) of the crew errors and bad behaviors.
Often, management doesn’t want to talk about these problems because fixing them requires changes in things that management controls:
- Training
- Procedures
- Human Engineering
- Work Direction
- Management Systems
- Communications
- Quality Control
Now for comparing the Colgan Air Crash and the BP Texas City explosion … When you start looking into the details, there are lots of similarities:
- Crew fatigue
- Not following procedures and shortcutting checklists
- Operators/pilots making basic mistakes
- Inexperienced crews responding to the unexpected
Let’s wait for the NTSB report before we jump to conclusions, but I’d recommend that management dig deeper when they look at blame as the cause of an accident.
Share on Facebook
Posted in Accidents, Current Events, Investigations, Root Causes | No Comments »
Saturday, November 28th, 2009
Toyota has been a the center of several recalls including rusty truck frames and uncontrollable acceleration. One blog even said they had “…fallen from grace…”.
Perhaps it’s time for Toyota to go beyond the simple root cause analysis of 5-Whys and start using advanced root cause analysis for these more difficult issues (or for all issues).
If you need to learn why 5-Whys should NOT be your preferred root cause analysis tool, see this article:
http://www.taproot.com/wordpress/2009/08/26/more-bad-root-cause-analysis-advice/
It has links to several articles that explain the drawbacks of 5-Whys and then you can see why Toyota might be having problems.
And if you become interested in advanced root cause analysis, see the course schedule here:
http://www.taproot.com/courses.php
Share on Facebook
Posted in Accidents, Current Events, Investigations, Performance Improvement, Root Causes | No Comments »
Friday, November 27th, 2009
All high performance systems need root cause analysis. They can use it reactively when things go wrong and proactively to keep things from going wrong.
Long ago we had our first “network reliability” people start using TapRooT® to improve network reliability. Our first customer was a company that supplied high reliability computer system for financial transactions. The next one ran a high reliability telecommunications network that included 911 call systems.
It seems they may be needing some advanced root cause analysis training in London.
Why?
They had to shut down trading on the London Stock Exchange because of a “technical glitch.”
Here what a story from The Star had to say:
“LONDON: The London Stock Exchange PLC halted trading for three-and-a-half hours on Thursday after a technical glitch prevented some customers from connecting to its systems.
The LSE, Europe’s oldest independent exchange, said taking trade offline was the only way to ensure a fair and orderly market after customers reported the connectivity problems in early trading.
The exchange is still looking into the root cause of the embarrassing outage - the second significant technical problem in just over a year - and said it was too early to judge the extent of the effect on trade or lost business.“
And this isn’t the first time this has happened. The story also said:
“Just over a year ago, the LSE experienced its worst outage in almost a decade when a software glitch was blamed for a 7-hour shutdown that angered customers on one of the busiest days of the year on world equity markets.
On that day in September 2008, the shutdown left many clients unable to cash in on a worldwide stock market boom that followed the U.S. government bailout of mortgage giants Fannie Mae and Freddie Mac.”
Think that’s a big problem? You betcha!
Share on Facebook
Posted in Current Events, Performance Improvement, Root Causes | No Comments »
Thursday, November 26th, 2009
Here is my Thanksgiving posting. I post it every year, lest we forget.

In America, today is a day to get together with family and friends and reflect on our blessings - which are many!
One of my ancestors, Peregrine White, was the first child born to the Pilgrims in the New World.
During November of 1620, Peregrine’s mother Susanna, gave birth to him aboard the ship Mayflower anchored in Provincetown Harbor. His father, William, died that winter - a fate shared by about half of the Pilgrim settlers.
The Pilgrims faced death and the uncertainty of a new, little explored land. Why? To establish a place where they could worship freely.
With the help of Native Americans that allied with and befriended them, they learned how to survive in this “New World.” Today, we can be thankful for our freedom because of the sacrifices that these pioneers made to worship god in a way that they chose without government control and persecution.
Another interesting history lesson about the Pilgrims was that they initially decided that all food and land should be shared communally. But after the first year, and almost starving to death, they changed their minds. They decided that each family should be given a plot of land and be able to keep the fruits of their labors. Thus those that worked hardest could, in theory, reap the benefits of their extra labor. There would be no forced redistribution of the bounty.
The result? A much more bountiful harvest that everyone was thankful for. Thus, private property and keeping the fruits of one’s labor lead to increased productivity, a more bountiful harvest, and prosperity.
Is this the root cause of Thanksgiving?
This story of the cause of Thanksgiving bounty is passed down generation to generation in my family. But if you would like more proof, read the words of the first governor of the Plymouth Colony, William Bradford:
“And so assigned to every family a parcel of land, according to the proportion of their number, or that end, only for present use (but made no division for inheritance) and ranged all boys and youth under some family. This had very good success, for it made all hands very industrious, so as much more corn was planted than otherwise would have been by any means the Governor or any other could use, and saved him a great deal of trouble, and gave far better content. The women now went willingly into the field, and took their little ones with them to set corn; which before would allege weakness and inability; whom to have compelled wold have been thought great tyranny and oppression.”
William Bradford, Of Plymouth Plantation 1620-1647, ed. Samuel Eliot Morison (New York : Knopf, 1991), p. 120.
Share on Facebook
Posted in Current Events, Performance Improvement, Root Causes | 2 Comments »
Wednesday, November 25th, 2009
I saw two articles by Ronda Levine recommending “5-Whys” as a preferred root cause analysis technique and giving a 5-Why example. Here’s the example from the article:
After determining that the quality management project would focus on the cause of the image bleed on the t-shirts (because almost 2/3 of the t-shirts produced by her company show this defect), Brenda begins to ask “why” to determine the cause of the problem. At the top of a sheet of paper, she writes “2/3s of t-shirts produced bleed through the material from a severity range of barely noticeable to highly noticeable.”
Underneath this, she writes, “Why?”
“The t-shirt fabric is too thin.” This first response can’t be possible, because the company carefully researched the fabric and the ink for the project to ensure the materials would work. So, she looks for an alternate cause and comes up with:
“The ink isn’t drying fast enough.”
“Why not?” She asks the question, again, to get closer to the root cause of the problem.
“Because the presses are using too much ink.” If this is the answer, it would also solve another problem the company has been experiencing, the blurring of images printed on 1/3 of all shirts produced.
Another potential problem at this stage could be that the ink ordered wasn’t correct for the project. However, Brenda checks the inventory logs and finds that this isn’t the case.
“But why are the presses using too much ink?”
“Because the presses haven’t been properly calibrated.”
It seems as though this last answer is a contender. Brenda sits down with her project team and constructs a plan for changing the calibration on the machines.
Seems like this 5-Why example only has three whys. And is “the presses haven’t been properly calibrated” really a root cause? Seems like a Causal Factor (and just a single Causal Factor at that) in TapRooT®.
It seems like a better approach would have been to draw a generic SnapCharT® for the printing, quality control, and delivery process and then analyze all the Causal Factors rather than just one. But you would have to be TapRooT® Trained to understand how this process would work.
I left a comment at the posting referring people back to some of the previous articles I’ve written. Like this one:
http://www.taproot.com/wordpress/2009/08/26/more-bad-root-cause-analysis-advice/
I hate to be so negative, but if somebody doesn’t point out bad advice, many will start using 5-Whys thinking that it is a good idea. Therefore, I’m going to keep pointing out this “BAD ADVICE” until everyone knows the problems with 5-Whys and Cause-and-Effect.
Share on Facebook
Posted in Investigations, Performance Improvement, Root Cause Analysis Tips, Root Causes | No Comments »
Wednesday, November 25th, 2009
I was reading a Reuters story about a crack in the containment at Crystal River nuclear plant, and there were several references to “root cause” and “root cause analysis.”
Then I started thinking back…
When we started System Improvements back in 1988, there were almost no references to “root causes” in the news. But in the past 20 years, the phrase has gained popularity.
So root cause analysis is now more frequently referenced. But my question is … DO PEOPLE UNDERSTAND THE TERM “ROOT CAUSE”?
I know folks that attend TapRooT® Training leave with a whole new understanding of root cause analysis, but what about those folks that think that asking why 5 times gets them to a root cause? Do they really understand what a root cause is? Very, very doubtful…
If you want to really understand root cause analysis then attend a course that comes with a guarantee. Here’s the guarantee that comes with every TapRooT® Root Cause Analysis Course:
Attend a TapRooT® Course.
Go back to work and apply what you have learned.
If you don’t find root causes
that you previously would have overlooked
and if you and your management don’t agree that the
corrective actions you develop are much more effective,
just return the course materials and
any software that was provided and
we will refund the entire course/software fee.
It’s that simple. We are that confident
that you will love the results obtained
when using TapRooT® to find root causes.
So register for a TapRooT® Course today with no worries about the quality of the system that you are learning.
Share on Facebook
Posted in Courses, Current Events, Root Causes, TapRooT | No Comments »
Thursday, November 19th, 2009
Here’s a link to the previous blog post on this topic:
http://www.taproot.com/wordpress/2009/11/02/monday-accident-lessons-learned-us-navy-ships-collide-corrective-action-fire-the-co/
This isn’t the first time I’ve written about submarine accidents. Here are 6 other links to review:
http://www.taproot.com/wordpress/2008/03/24/monday-accident-lessons-learned-nuclear-navy-leadership-failure/
http://www.taproot.com/wordpress/2007/10/28/another-note-on-the-uss-hampton-incident/
http://www.taproot.com/wordpress/2007/10/26/sub-co-fired-after-falsified-chemistry-records-discovered/
http://www.taproot.com/wordpress/2007/10/23/spac-not-used-enforcement-ni-6-sailors-aboard-uss-hampton-punished-for-falsifying-nuclear-reactor-chemistry-records/
http://www.taproot.com/wordpress/2005/10/31/uss-greeneville-accident-ntsb-report/
http://www.taproot.com/wordpress/2007/05/04/rickovers-legacy-safety-equipment-reliability-secrets-of-the-nuclear-navys-success/
And there are more. Why all this background?
Because instead of looking at each collision as an isolated failure of the Commanding Officer (or members of the crew), perhaps these accidents/incidents in the Submarine fleet that include - running into a sea mountain, colliding with and sinking a Japanese fishing vessel, gun-decking chemistry logs, and hitting another Navy ship - are part of a pattern of problems that indicate deeper issues.

After all, does the CO, Commander Ryan Brookhart - pictured above, look like a bad person?
Look at his public LinkedIn profile:
http://www.linkedin.com/pub/ryan-brookhart/13/471/508
Or read this press release about him taking Command of the USS Hartford:
http://www.nathanreichert.com/release/MuscatineNative.htm
If he was a “bad person”, shouldn’t the Navy have known that after 17+ years of service?
If he was NOT a bad person, then shouldn’t we be looking for the SYSTEM causes that resulted in this accident?
For example, the Navy Times had this quote in an article about the accident:
“Over several months” prior to the incident, hundreds of watchstanders were tested in their ability to understand how to analyze the movement of surface contacts. The exams yielded results of 10 percent to 15 percent passing grades among enlisted watchstanders and 60 percent of officers.
“Given the attention I have personally placed on submerged contact management in briefing the waterfronts, this is unacceptable,” McAneny wrote in the message obtained by Navy Times.
Doesn’t this seem to indicate a problem far beyond a bad CO?
I haven’t finished reading the Navy JAG Manual Investigation Report, but the articles that refer to it are in full “blame” mode. They protect those higher in the chain of command by making this a story about one bad CO with some bad watch standers who broke well established rules. They were bad people. They listened to iPods! Fire the CO, discipline some sailors, and warn everyone else not to be bad like they were, and the problem goes away.
When I’m finished reading the 100+ page report (see attachment here):
HartfordJAGManualInvestigation.pdf
I’ll let you know what I think…
Until then, history tells me that we haven’t found the real root causes of this accident. And without REAL, advanced root cause analysis, they never will.
Share on Facebook
Posted in Accidents, Current Events, Human Performance, Investigations, Performance Improvement, Root Causes | No Comments »
Thursday, November 12th, 2009
Posted in Courses, Pictures, Root Causes, TapRooT | No Comments »
Tuesday, November 10th, 2009
Did fatigue cause this derailment?

See this report:
http://www.raib.gov.uk/cms_resources.cfm?file=/091110_R282009_East%20Somerset%20Junction.pdf
to find out what the UK Rail Accident Investigation Branch has to say and to see their recommended corrective actions.
Share on Facebook
Posted in Accidents, Current Events, Human Performance, Investigations, Pictures, Root Causes | No Comments »
Friday, November 6th, 2009
OK - I’ll point out another bad piece of advice.
This time a non-profit agency recommended that public health departments use 5-Whys to analyze problems fighting the H1N1 pandemic.
Do they really need to be told to ask why?
Wouldn’t a systematic, proven, successful, advanced root cause analysis system - TapRooT® - better serve the needs of our country?
For more about why I hate 5 Whys, see:
http://www.taproot.com/wordpress/2009/10/23/more-bad-root-cause-analysis-advice-another-bad-article/
Share on Facebook
Posted in Current Events, Investigations, Root Causes | No Comments »
Thursday, November 5th, 2009
People in the Copenhagen TapRooT® Class asked me to post a link to the software that Circadian Technologies has developed (and offers for free) to help evaluate if fatigue was the cause of an error.
Here’s the link:
http://facts.circadian.com/facts/
Here’s the article where I wrote about it:
http://www.taproot.com/wordpress/2009/05/20/root-cause-analysis-tip-how-to-evaluate-fatigue/
Share on Facebook
Posted in Accidents, Investigations, Root Causes | No Comments »
Friday, October 30th, 2009
A BBC news items seems to imply that cost cuts and cost cutting were the reason for a recent crash of XV230 - Nimrod aircraft fl;own by the RAF.
For the complete story see:
http://news.bbc.co.uk/2/hi/uk_news/8329117.stm
Share on Facebook
Posted in Accidents, Current Events, Investigations, Root Causes | 1 Comment »
Friday, October 23rd, 2009
Aza Badureen has posted bad root cause analysis advice on a blog about Lean.
What is the bad root cause analysis advice?
That 5 Whys is a “simple but effective lean tool“.
The good part of the article is that he does cover some of the drawback of 5 Whys.
But he does so by saying things like …
“root cause critics … claim “
“purported to be one of the downfalls“
And he never really addresses how the “claimed” problems can be overcome besides being “used correctly.”
Once again, another consultant leaves the impression that 5 Whys is an adequate tool.
Once again, the evidence of the 5 Why tool’s usefulness is that Toyota uses it. Could it be that Toyota is successful IN SPITE OF using 5 Whys? Could it be that the lack of advanced root cause analysis by other automakers allows Toyota to get by with a poor technique?
Once again, if you doubt the embedded drawbacks of 5 Whys, read some of our previous posts and the Q&A that follows. See:
http://www.taproot.com/wordpress/2009/08/07/root-cause-analysis-tips-are-simple-techniques-sometimes-the-best/
http://www.taproot.com/blog/2007/03/teruyuki_minoura_toyota_exec_t.html
http://www.taproot.com/wordpress/2005/10/30/whats-wrong-with-5-whys-complete-article/
http://www.taproot.com/wordpress/2006/11/15/another-example-of-why-5-whys-fishbone-diagrams-are-bad-root-cause-analysis-systems/
http://www.taproot.com/wordpress/2008/11/07/defending-categorization-why-the-taproot-root-cause-tree-works-better-than-unguided-root-cause-analysis/
http://www.taproot.com/wordpress/2007/12/04/comparing-taproot-to-other-root-cause-tools/
http://www.taproot.com/wordpress/2009/08/26/more-bad-root-cause-analysis-advice/
I know that my criticism of 5 Whys is getting repetitious. I’m sorry.
I hope that I can someday stop writing about the drawbacks of 5 Whys because people start to see the inherent problems with the technique. Then they will stop writing that 5 Whys is an effective tool.
Share on Facebook
Posted in Investigations, Root Causes | No Comments »
|
|