The following is an excerpt from Appendix B in the upcoming TapRooT® – Changing the Way the World Solves Problems – book. The material is copyrighted and is used here with permission of System Improvements.
Comparing TapRooT® to
Other Root Cause Tools
Price is what you pay. Value is what you get.…
Risk comes from not knowing what you’re doing.
Choosing the tools you will use to improve performance is one of the most important choices that a business can make. The tools you choose and the systems you set-up, along with the people who use them, will determine your company’s performance in the future. By Warren Buffett’s theory, you need to know what you are doing or you will be taking unnecessary risk.
B.1 TapRooT® Background
TapRooT® System is a process and techniques to investigate, analyze and develop corrective actions to solve problems. The process and tools are completely described earlier in this book but a brief history of who uses TapRooT® and why it is used by so many industry leaders will help those trying to decide what root cause analysis system they should choose as their standard.
A forerunner of the SnapCharT® and Root Cause Tree® have been commercially used to investigate incidents since 1988. The TapRooT® System was first put into a comprehensive root cause analysis tool in 1991. By 2001, a limited, unpublished survey conducted by the Center for Chemical Process Safety (CCPS) showed that TapRooT® was the most used root cause analysis systems by CCPS members (mainly chemical plants, petrochemical plants, and refineries). Since it’s inception, the use of the TapRooT® System has grown to a broad variety of other industries, including:
– Healthcare– Pharmaceuticals– Utilities– Nuclear Plants – Oil exploration and production– Mining– Aviation/Aerospace– Shipping– Rail and rapid transit– Manufacturing– Telecommunications– Pulp and paper– Construction– Pipelines– US Department of Energy sites– Government regulatory agencies (OSHA, MSHA, FAA, …)
By our estimate of root cause analysis classes held around the world, TapRooT®, with over 10,000 people being trained per year in its use, is the leading worldwide root cause analysis system.
What do leading companies around the world use TapRooT® to accomplish? A sample of uses include:
– Improve process safety
– Improve industrial safety
– Improve patient safety and reduce sentinel events
– Improve customer safety
– Improve product and service quality
– Reduce operations and maintenance errors
– Increase service and equipment reliability
– Reduce unplanned environmental releases
Why have so many companies in so many industries chosen to use TapRooT® to analyze their business critical issues and improve company performance? Because it works. Success stories achieved using TapRooT® can be found at www.taproot.com in the “About TapRooT®/Success Stories” section of the web site.Why does TapRooT® work so well? Because of the insightful development of the tools and techniques into an investigation system. After reading the this book, you know that TapRooT®:
1. Has a sound scientific basis built upon proven best practices and a sustainable vision of improvement based on finding and fixing the system causes of errors and failures.
2. Has a history of rigorous development, testing, and continuous improvement that continues today.
3. Systematically looks at problems to analyze their root causes.
4. Helps investigators see beyond their current knowledge by using embedded intelligence.
5. Can be used to investigate human performance and equipment failure problems.
6. Promotes consistency of root cause analysis (different teams can achieve the same results).
7. Allows transparency by allowing others to see how conclusions were reached.
8. Is built with the purpose of helping investigators develop effective corrective actions by the use of advanced technology.
9. Has been proven effective by leading companies from around the world.
10. Can be used both reactively and proactively.
11. Prevents jumping to conclusions though the techniques and tools built into the system.
12. Can be used to improve existing performance improvement programs (Lean, Six Sigma, Behavior Based Safety, Process Safety Management, Sentinel Event Investigation, ISO, Equipment Reliability Improvement, Corrective Action Programs).
13. Can be used to create a stand-alone improvement program with all the best features of current performance improvement technology.
14. Helps management understand what happened and the corrective actions needed to improve performance.
15. Supports advanced trending that will help management avoid knee-jerk reactions to false trends.
16. Can be scaled to work on small or big problems.
17. Has guaranteed training.
18. Has patented software to improve investigation efficiency and effectiveness.
19. Is supported by a worldwide network of highly experienced instructors.
20. Is supported by an Advisory Board made up of over 50 talented users from leading companies that use TapRooT® to solve problems in countries around the world.
21. Sponsors an annual Summit to further the root cause analysis and performance improvement state-of-the-art, to bring the best new ideas to TapRooT® Users, and to bring continuous improvement to TapRooT® User’s knowledge.
22. Is as simple as possible without being too simple. Therefore, TapRooT® can be used by people in the field to investigate everyday problems and yet be robust enough for even the most complex major accident investigation.
That’s 22 factors that set TapRooT® apart from any other root cause analysis tools. These factors are some of the main reasons that TapRooT® is changing the way the world solve problems.
B.2 Comparing TapRooT® to Other Root Cause Tools
But how does TapRooT® compare to some of the common root cause techniques? One of our instructors, Kevin McManus:
• Has been a plant manager, quality manager, and plant engineer
• Is a quality expert (has been a Senior Malcomb Baldrige National Quality Award Examiner, as well as having served as Board President and Executive Director of the Association for Quality and Participation)
• Is an Industrial Engineer (monthly columnist to IE – Industrial Engineer magazine and Vice President of Continuing Education on the Institute of Industrial Engineers Board of Trustees)
He decided to write a comparison of techniques that he has personally used during his career. He posted this critique at www.greatsystems.com (his web site) and it is reprinted here by his permission.
How Do You Find Root Causes?
By Kevin McManus
Organizations use a variety of approaches to find the root causes of problems. The most popular, formal approach is probably the fishbone, or Ishikawa, diagram, which has been in use for at least 25 years. The recent growth in popularity of lean manufacturing methodologies has helped bring the ‘5 Why’ technique more into vogue, even though this tool also is at least 25 years old (it was part of the Toyota Production System model). Unfortunately, few organizations truly master the skills required to (1) find the root causes of their problems and (2) implement fundamental system changes to address those causes. In turn, they continue to face the same issues day in and day out – their problems keep coming back.This article summarizes the similarities and differences between five common techniques that are used for problem solving through root cause analysis:
• 5 Whys
• Kepner-Tregoe Problem Analysis
• Fault Tree Analysis
• Change Analysis
• Fishbone Diagram
• TapRooT® RCA
These techniques are discussed in the paragraphs that follow. A summary of the eight advantages provided by the TapRooT® root cause analysis process over these techniques is then presented. You get to decide which approach might work the best for you.
Technique Name: 5 Whys
Features: From my perspective, the Five Whys represent more of a conceptual, as opposed to a systematic, fact-based approach, to root cause analysis. It was adopted from the Japanese approach to management, most notably practiced by Mr. Shingo, who would use the five whys on the production floor when he would tour manufacturing sites. In essence, Mr. Shingo would continue to ask why five or more times to get to the true cause of a problem, with his questions being structured to help lead the employees he was talking to towards the problem’s source.
Advantages: If a person knows how to ask good, successive ‘why’ questions, and is able to ask them of the right people, he or she will find at least one root cause for a given problem. This approach takes little time to perform – as few as five minutes can be used to perform a five why analysis – and does not require the use of special software, flip chart paper, or reading materials. If it is performed repeatedly with the same group of people in a sound manner, its use can lead to a new way of thinking amongst those people that have been exposed to the tool’s use.
Disadvantages: The 5 Why approach normally leads to the identification of just one root cause for the problem in question. You will need to go through the ‘5 Why’ process several times for a given problem in order to ensure that all root causes are identified, and being able to do so effectively requires even more skill of the part of the question asker. It also does not necessarily point the problem solver towards the generic causes of similar problems.This approach requires significant skill in order to learn how to ask the right why questions – the five why technique is not as simple as asking ‘why?’ alone five times. While the use of this tool will lead to the definition of a root cause that is also a change that is needed (a corrective action), it does not often result in a corrective action that is well developed and defined. Most people fail to gain much success when using this tool simply because they cannot develop the ability to ask good ‘why’ questions in succession, even though Mr. Shingo was quite skilled at doing so.
Technique Name: Kepner-Tregoe Problem Analysis
Features: I attended a five-day KT training course in 1990. The training did cover root cause analysis in a sense, but more in the form of general problem analysis. The key components of the KT process include problem analysis, potential problem analysis, situation analysis, and decision analysis. Problem analysis contains a form of root cause analysis, but is based largely on the ‘is / is not’ tool that is similar to the TapRooT® Change Analysis process. The Decision Analysis tool is a great tool, and I still advocate its use today, but it focuses on teaching people to evaluate possible improvement options in a systematic, fact-based manner, as opposed to finding root causes. Situation Analysis is used to assess the risk associated with possible improvements, and Potential Problem Analysis looks at the possible repercussions of failing to make a change.
Advantages: Like TapRooT®, if the user has performed a good problem investigation and has collected a lot of information (especially data), they can find the causes of the specific problem being analyzed, even though they may not be specifically called root causes. To me, the Decision Analysis tool is one of the best out there for evaluating improvement options (possible corrective actions).
Disadvantages: Good information and a formal evaluation process helps keep the user of any of these tools from focusing too much on blaming people, but the tools can be time consuming to use and are not as functional as TapRooT® is in terms of getting to generic causes. I also question whether or not these tools can help you get to the true system problems that are causing given incidents to occur (which the TapRooT® process is designed to help you do). Well-rounded corrective action development is really not a focus of these tools as I remember them.
Technique Name: Fault Tree Analysis
Features: My perspective of fault trees is that they encourage the user to (1) ask the five whys multiple times for a given type of problem and (2) evaluate several possible problem causes on one diagram (similar to the manpower, methods, materials, and machines boxes on a fishbone diagram). Like the other common root cause analysis approaches, fault trees tend to be a predominantly opinion-based tool, in that there are no predetermined questions that are used to help you create the branches of a given tree.
Advantages: From my perspective, I prefer fault trees over fishbone diagrams because their design allows four to five levels of ‘why’ to be identified for a given problem, if the users are willing to exercise a high level of discipline as they draw their charts. I find them to really be useful for troubleshooting reoccurring problems, such as quality defects, because such problems tend to have a common set of causes and sub-causes. When used in this manner however, a fault tree essentially becomes analogous to the TapRooT® Equifactor® Troubleshooting Technique which is used for equipment troubleshooting.
Disadvantages: Fault trees typically fail because (1) people do not use them in a disciplined manner to develop multiple problem causes at each level, (2) multiple levels of potential causes exist to be sorted through for each problem type, and (3) they are opinion driven. They often tend to be a blend of a cause effect diagram and a flow chart, but in such cases, the user can easily get lost and not arrive at any particular root cause. Also, a well-developed fault tree often leads the user to discover that the same management systems (such as poor training, employee turnover, weak communications, and poor procedure design) are at the root of their problems (which is similar to the TapRooT® generic causes). In turn, a well-designed fault tree will lead you to the TapRooT® Basic Cause Categories, but rarely to the comprehensive mix of TapRooT® root causes.
Technique Name: Change Analysis
Features: I have not seen Change Analysis called out as a tool for finding root causes by itself. The KT ‘is/is not’ problem solving tool is the closest thing to change analysis that I have seen. As I stated above, this KT tool is in essence the same as the TapRooT® Change Analysis tool.
Advantages: It is always useful to compare what should have happened to what did happen when analyzing a problem, but this effort alone will not lead you the root causes of, and corrective actions for, preventing the problem in the future.
Disadvantages: The Change Analysis tool appears to be limited to comparing what should have happened to what did happen, and in turn does not lead you to the actual root causes of, and corrective actions for, preventing that problem in the future.
Technique Name: Fishbone or Ishikawa Diagram
Features: This tool is perhaps the oldest, and most well known, tool for conducting a root cause analysis. In its most common form of use, the user attempts to define multiple possible causes for a given problem in the four areas of manpower, methods, materials, and machines. The five why technique is often used with this tool to construct the bones of the chart, with the answer to each why resulting in a new branch being created off of the previous one that the question originated from.
Advantages: This tool is better than nothing, and serves as a useful tool for getting individual opinions onto a sheet of paper so that everyone involved can talk about them and suggest additional possible causes. In a lot ways, it is similar to identifying the conditions for a SnapCharT®, but that is where the comparison ends.
Disadvantages: This is an opinion-based tool, and its design limits the user’s ability to visually define multiple levels of ‘why’ answers unless the paper that is being used is really large. Worse yet, opinion (voting of some form) is normally used to select the most likely causes from those listed on the diagram. Teams are then encouraged to test different countermeasures for the selected causes to see if the problem goes away, which can be both time consuming and costly. The tool also does not focus on finding and eliminating generic causes.
Technique Name: TapRooT®
Advantages: Here are eight primary reasons why I feel the TapRooT® process is superior to any of the above listed tools:
1. It is a closed loop process in that it uses the SnapCharT® for problem definition (define), the Root Cause Tree® and trending for root cause identification (measure and analyze), and the corrective action process to define well-rounded problem solutions (improve).
2. The SnapCharT® is time-based, in that it shows the sequence of events leading up to and following a given problem. This tool helps the user identify a more complete set of events and conditions that led to a given problem’s occurrence.
3. The process is based on a set of well-developed operational definitions and questions, which are based on years of research and application, and which discourage the user from relying primarily on their opinions when selecting a root cause or causes.
4. The process encourages the identification of generic causes, which if corrected, will prevent similar problems from appearing in other parts of the organization or in other products or services in the product / service line.
5. The process software contains hundreds of possible corrective actions that have been used by hundreds of companies to correct and prevent the problems that result from both singular and generic causes.
6. The process is grounded in human factors theory, which supports the fact that people are the key to organizational success and most often the source of most problems due to the design of the systems and processes they use and the decisions they make as they do their jobs each day.
7. The TapRooT® Software’s design and content encourages and enables the individual problem solver, or a team of problem solvers, to keep their efforts focused and organized due to the existence of the dictionary, Corrective Action Helper® module, a highly visual problem definition (SnapCharT®) and root cause analysis process, and the linkages between the SnapCharT®, Causal Factors, the Root Causes selected, the identified corrective actions, and the assortment of incidents analyzed.
8. The results that you get from using this tool versus the time invested to use it will almost always far outweigh the results you will get from the time invested using any of the above tools. The time required per tool application is not much, if any, greater, and the quality of results is far superior. In most cases, a couple of hours of use with most of the above tools would only give you a list of possible causes – in the same amount of time, the TapRooT® process will give you a clearly defined problem, a focused set of root causes, and a sound mix of corrective actions.
That’s Kevin McManus’ evaluation.
B.3 factors for Evaluating Root cause Analysis Systems
After decades of researching root cause analysis theory and learning about root cause analysis tools, the authors are often asked to compare TapRooT® to other systems. Our response is always the same. Our opinion doesn’t make any difference to what root cause analysis tool you should pick. What should make a difference to you is how the tools you are choosing from work when applied by real people in the field. Therefore, the only way to be truly convinced that you have chosen the right root cause analysis tool for your site or company is to get trained in the tools that your are considering, and apply them. See how they work.
• Do they meet your needs?
• Do they help you find root causes that you previously would have overlooked?
• Can they be consistently used by different teams?
• Do they help you develop effective corrective actions that solve problems?
• Can you explain and defend your finding to management?
To help people evaluate root cause systems and decide for themselves which system best meets their needs, we developed the following evaluation criteria. We call these the 10 root cause analysis musts:
1. Must be easy-to-use without being “too easy”.
2. Must lead investigator to fixable causes of human performance and equipment problems.
3. Must have embedded expert knowledge.
4. Must be usable by regular people (not just PhDs/gurus).
5. Must be robust (repeatable/defendable).
6. Must be tested – proven successful in improving performance.
7. Must be well documented.
8. Must have excellent training.
9. Must have a database for organizing, sharing, saving, and trending info.
10. Must have unique categories for trending.
Where did these 10 musts come from? Our experience and the experience of others. They came from:
∗ Seeing thousands of incidents,
∗ Performing hundreds of investigations,
∗ Reviewing the results of thousands of investigations,
∗ Surveying over 300 people at four TapRooT® Summits
∗ Formally evaluating dozens of root cause tools and their effectiveness
∗ Developing dozens of performance improvement programs in a variety of industries
∗ Evaluating the effectiveness of a variety of performance improvement programs
∗ Collaborating with internationally recognized human performance and equipment reliability experts
The 10 “musts” are certainly not an exhaustive list. You may be able to add a few more “musts” for your choice of tools. But they do provide excellent guidance to someone considering what they need in a root cause analysis system.Let us briefly explain why each of these criteria made the list of “musts”.
B.3.1 Must Be Easy-to-Use Without Being “Too Easy”.
No matter how “good” you think your root cause analysis system is, users must be able to understand it, they must be able to use it, and management must be able to understand the results. However, being easy-to-use is not all that is required. That is why the first must includes the phrase “but not too easy.”For example, some say that the biggest advantage of the 5-Why concept is that it is easy to ask why 5 times. They seem to have fallen for Mr. Spock’s philosophy (from Star Trek):
“An easily understood falsehood is better than an incomprehensible truth.”
But as we have already heard from Kevin McManus, the key to effective 5-Why analysis is knowing the right questions to ask. And knowing the right questions isn’t easy. Therefore, this “simple” technique only works for expert problem solvers who have extensive training or experience in asking the right questions.
Figure B.3-1 Fastest Root Cause Tool: Spin-A-Cause™
If easiness (and not results) was the only criteria, we would choose Spin-A-Cause™ (Figure B.3-1) as our root cause tool of choice!
In root cause analysis, there are more choices than just an easily understood falsehood or an incomprehensible truth. There is a middle ground – a system that is easy enough to use without being too easy.
Finding this middle ground follows Einstein’s philosophy:
“Make solutions as simple as possible, but not too simple.”
Without a doubt, any systematic evaluation of the cause of a complex accident requires work. So how do we know what is easy enough when we evaluate a root cause analysis tool or system?This is the point that you must think about the purpose of the system. What do you want the system to do for you? Then you can choose a system that meets your needs.
In May of 2003, at the Royal College of Physicians, James Reason, creator of the Swiss Cheese Model and the models that were used to develop the Tripod-Beta System, said the following:
… There is no one good way (of) classifying (errors),
but try and find one that can show you how to take remedial action.
His quote points to the fundamental purpose of any root cause analysis system. It must be designed to be robust enough to provide a thorough analysis and to develop effective corrective actions while still being simple enough for regular people in the field (and management) to understand.If the system is easy but yields unacceptable results, then the system is too easy.
How do you judge a tool’s effectiveness and usability? Train a sample group of serious potential users to try it and see how effective their corrective actions are and, if they were effective, ask them if they think that others could use it.
One caution: One must be careful not to allow unreasonable constraints when evaluating “easiness.” For example, if a company assigns complex accidents to be investigated by supervisors in their spare time, NO system will yield acceptable results and be easy to use.
You can’t get something for nothing!
So when evaluating “easiness”, one must allow the user reasonable amounts of time and effort in performing an investigation and using the tool.
A second caution: The person evaluating the use of the tool must have been adequately trained.
Once again, it is preposterous to give an untrained supervisor a piece of software to perform root cause analysis and expect that the supervisor will perform a good investigation and find the software easy-to-use. No matter how good the software is, most supervisors do not have the investigatory experience needed to perform a good investigation without training in investigation practices and root cause techniques.
B.3.2 Must Lead Investigators to Fixable Causes of Human Performance and Equipment Problems.
This may be the most important, and most hotly debated, “must” on the list. Almost every word in “Must Lead Investigators to Fixable Causes of Human Performance and Equipment Problems” is important.
For example, “lead” is important. This word helps us discover the third “must” in the list.
“Fixable” is also very important. The fixable criteria came from our original definition of root cause and is the focus of our current definition:
A Root Cause is the absence of best practices or the failure
to apply knowledge that would have prevented the problem.
Some who claim to be root cause analysis experts say that fixable has no place in the definition of a root cause or in evaluating the goodness of a root cause analysis tool. But Larry Minnick, a senior utility executive and safety expert, convinced me that if a technique didn’t lead to things that management could “fix”, then the investigators were wasting their time.
Most of those who object to the “fixable by management” part of the old definition of root cause, do so because they misinterpret the goal of management being able to fix something. They think that it means that management is willing to fix the problem. They say that if management says they aren’t willing to fix something then it is still a root cause. But in the old definition the word fixable says nothing about management’s willingness to fix a problem.
Perhaps the BEST measure of effective root cause analysis is the change that good root cause analysis creates. As a result of good root cause analysis, people should develop and implement effective fixes that improve performance. These results come from finding, understanding, and fixing the root causes of problems.
IF a root cause analysis tool can lead a person or a team to the fixable causes of a problem and IF the person or team develops effective corrective actions and IF the company implements the effective corrective actions, THEN performance should improve. This should be measurable by effective trending.
One more item to notice in the second “must” is that it includes BOTH human performance and equipment problems. Many people miss the root causes of equipment problems because they don’t explore the human performance causes. These problems could involve installation, design, maintenance, or operation of the equipment.
B.3.3 Must Have Embedded Expert Knowledge.
This may be the least obvious must on the list, but it is also one of the most important.Why must the system have embedded expert knowledge? Because you can’t expect every investigator to be an expert in every cause of equipment and human performance. Also, you can’t expect every site to hire experts on every topic that an investigator can reasonably be expected to confront.
If the investigator does not have the knowledge, the investigative tool MUST guide the person to the knowledge or at least help them realize what they don’t know. The root cause tool needs to be an expert system with expert knowledge.
The more transparent (yes – invisible) this expert knowledge is, the better the system will work for most people. The user of a root cause analysis system should not feel like they are required to have a PhD in engineering, human factors, and management to conduct an investigation. The system should make the knowledge needed available in as close to layman’s terms as possible.
When an investigator uses this expert system knowledge, they should amaze their boss and peers with the insights they gain over and above what they discovered when investigating incidents before they had an expert system.
What happens if this expert system knowledge is not built into a system? People won’t be able to see beyond what they already know. And as Einstein said:
“We can’t solve problems by using the same kind of thinking
we used when we created them.”
Thus, the lessons of Chapter One teach us that the tool must include an expert system that is built upon the best and most usable human performance and equipment reliability technology.
B.3.4 Must Be Usable By Regular People (Not Just PhDs/Gurus).
This “must” comes from the KISS philosophy (Keep It Simple Stupid). KISS is a reminder for the designer – the person tempted to be stupid and make a design complex.
You don’t plan to staff your facility with PhDs and Guru problems solvers. And even if you did, they would want a system that was easy to use. So, the reason that anyone developing a root cause tool should keep it simple is NOT that the users are going to be stupid or geniuses. Rather, if the system is simple, people will use it.
Many root cause tools are developed by experts. All you need is the expert’s knowledge to use the tool well. These tools will never be correctly applied by people in the field. People performing root cause analysis are always under pressure. They have deadlines. They deal with conflicting or missing information. They must investigate complex accidents. They don’t need their root cause analysis tool to be needlessly complex.
Part of making a system simple is embedding expert knowledge in the system to help lead the investigator (the third must). This makes the system simple because the user doesn’t need to learn all the expert knowledge before he/she starts investigating his/her first incident.The other part of keeping a system simple is making it match the way human beings think. And people think in stories and categories. Therefore, your system should support the cognitive models that people build without letting them fall into the traps that preconceived notions and assumptions can cause.
B.3.5 Must Be Robust (Repeatable/Defendable).
What is a robust root cause analysis tool?
• A tool that helps the investigator keep on track and even helps steer them back to the track when they start to go astray.
• A tool with checks and balances to help the investigator assure that a wide variety of potential causes have been checked and that the root causes they uncover are accurate.
• A robust tool that does not require perfect use or perfect knowledge to get effective corrective actions.• A tool that can be used by two different people (or teams) and let them arrive at similar root causes and effective corrective actions.
• A tool that helps people explain what went wrong, the system causes of the failure, and what can be done to prevent simiar incidents in the future.
That is a robust root cause analysis tool.
B.3.6 Must Be Tested – Proven Successful in Improving Performance.
A good root cause analysis tool should have passed the test. It should have been tried by a variety of users in a variety of industries. It should be able to analyze equipment and human performance problems. Different people using the system on the same incident should get similar results. A good root cause analysis system should have a pedigree of success stories that prove its effectiveness.
Experimental root cause systems are OK for experiments. But if you are going to solve real problems in the real world that could:
∗ Save people’s lives
∗ Save people’s jobs
∗ Prevent environmental damage
∗ Improve your reputation with customers and regulators
You want to be confident in the root cause analysis technology that you are using.
Thorough testing and proof of effectiveness is where “homegrown” root cause systems usually fail to pass muster. They seldom have thorough testing by a variety of users in a variety of industries. They are usually just someone’s opinion or an amalgamation of other’s ideas. They don’t pass this test.
B.3.7 Must Be Well Documented.
Good documentation is a key to consistent use. Consistency is often one of the main faults with root cause analysis tools. If you give a root cause analysis tool to two different investigators (or two different investigative teams) and they arrive at completely different answers — you have a problem. The documentation should include how to use the system and definitions for any terminology used in the system. This helps the system be usable by average investigators (not just experts).
B.3.8 Must Have Excellent Training.
A system is only as good as the training for the users. Almost any system can be misused. Excellent training will get people started the right way (and excellent management will keep them using the system the right way).
What is excellent training? You can judge the training by the results. For example:
• How much improvement in root cause analysis and corrective actions are there after the training?
• Do those trained dig deeper and find root causes that they previously would have overlooked?
• Do the corrective actions seem like they will work?
• After the corrective actions are implemented, do they cause performance to improve?
• Do the measures of performance improve by a statistically significant amount?
The proof of good training is not JUST how the trainees feel about the training – although that is important. The proof of good training is in the results that the trainees get after the training.
B.3.9 Must Have a Database for Organizing, Sharing, Saving, and Trending Info.
Why should you have a database for root cause analysis, incident investigation, and performance improvement? Here are five basic reasons:
1. To keep track of information during the investigation. (Helps you find root causes.)
2. To provide computerized tools to make investigators more productive (including expert systems). (Helps make investigations more effective and efficient.)
3. To facilitate the searching of old incidents and sharing of lessons learned across a site or corporation. (Helps find old corrective actions that didn’t work and share information about your investigation – best practices that do cause improvement.)
4. To track corrective actions to completion and track verification and validation of selected (especially important) corrective actions. (Root cause analysis is useless if the corrective actions aren’t implemented – and we all know that what gets measured gets done.)
5. To provide the data for trending and management of the facility or company. (Making root cause data available makes the root cause information usable.)
If you have a database that meets the five items above, you will have more productive, efficient, effective investigators who are more likely to get their corrective actions implemented.
B.3.10 Must Have Unique Categories for Trending.Categorization was defended in Chapter 8, so we won’t repeat the arguments here of why categorization helps improve root cause analysis. This must is focused on why trending is important and why one should think about trending when choosing a root cause system.Why is trending important? Because trends are a key part of any improvement program. The importance of trending, and the troubles that ad-hoc trending can cause, were presented in detail in Chapter 5.Each investigation should be a part of a “Bigger Picture” that helps management effectively manage a company or facility. To make this happen and make it available to those who come along after the investigation, one must organize and categorize the data. Once you have a good categorization system you can:
∗ Spot areas begging for improvement (the biggest problems)
∗ Find significant trends∗ Prove that improvement has occurred
∗ Prove that random failure is NOT a trend
∗ Estimate the expected minimum and maximum time between incidents or accidents
These are basic components of an efficient and effective management system for improving performance. You will find them in Six Sigma, Lean, and Behavior Based Safety programs. And the root cause analysis tool you pick should be developed with trending in mind.
B.4 Evaluating TapRooT®We’ve listed and explained our 10 musts. Now let’s see how TapRooT® measures up to the “must” challenge.
B.4.1 TapRooT® Is Easy-to-Use Without Being “Too Easy”
First let’s tackle the “Too Easy” part of this must.
First, the TapRooT® System is built upon state-of-the-art human performance and equipment reliability research. This started with Mark Paradies’ human factors training at the University of Illinois and his Nuclear Navy equipment experience. It has expanded and continued in the 20 plus years since. Chapter 1 showed the breadth and depth of the human factors research that is embedded in the Root Cause Tree®. And those who know Heinz Bloch know that to lend his name and reputation to a product, it must have superior equipment analysis capabilities.
But even with all the excellent human performance models, the system would not be revolutionary if it did not maintain a focus on fixing problems. And as we’ve shown in Chapter 1, TapRooT® was specifically developed to analyze problems and show people how to fix them using proven human performance knowledge. That is probably TapRooT®’s biggest advantage when solving problems – that’s what it was designed to do!The technical aspects of the models are not all that makes the system superior. In addition to the foundation of expert research and the specific design for the purpose of problem solving, the model was carefully crafted – not for PhD research – but to be used by people in the field. This aspect of TapRooT®’s development addresses the “Easy-to-Use” part of the must.From line workers at an assembly plant to engineers for NASA, from nurses at hospitals to operators at a refinery, from supervisors at a nuclear plant to senior managers at an airline – TapRooT® can and has been put to use effectively. And not only was it designed to be used by people in the field, it has been tested and proven to work. That testing started with practical applications and focus groups back in 1991. The testing and feedback continues today with users on every continent around the world. Our TapRooT® Advisory Board includes over 50 individuals from all types of industries, a variety of sizes of companies, and the full gamut of organizational levels (from operators to a major corporation Vice President). They provided ideas for – and reviewed the changes that – resulted in this revision to the TapRooT® System. Thus, this book is the result of over 20 years of developmental feedback and testing from a user base that grows by 10,000 or more new TapRooT® Users each year. Another factor that makes TapRooT® “Easy-to-Use” is that it can be scaled to the size of the problem being investigated. The TapRooT® System can be scaled for use on: • Simple proactive audits/observations or relatively minor near-misses• Major accidents (refinery explosions, massive fires, structural failures, or tragic accidents)
The system is easy enough to apply to small problems (just draw a SnapCharT®, identify Causal Factors, and take them through the Root Cause Tree®) or robust enough for use by major investigative teams investigating refinery explosions.
Of course, any investigation requires effort to be successful. So if you expect supervisors to investigate problems in their spare time with no training, you probably won’t think that TapRooT® is easy enough. But perhaps you have forgotten that:
You can’t get something for nothing.
You get what you pay for.
What we have done is make the easiest root cause analysis system without making it “too easy”.
B.4.2 TapRooT® Leads Investigators to Fixable Causes of Human Performance and Equipment Problems
This is what TapRooT® was made to do! Chapter 1 explains it in great detail. Chapter 3 explains it in even more detail. If you read these chapters and tried TapRooT®, you know that TapRooT® meets and exceeds this expectation.
B.4.3 TapRooT® Has Imbedded Expert Knowledge
The 15 Questions, the Root Cause Tree Basic Cause categories, and the Root Cause Tree® Dictionary take a wealth of knowledge, best practices, human performance, and equipment reliability technologies and embed them in a very user-friendly system for finding root causes. Again, for those who want details, see Chapter 1.
B.4.4 Must Be Usable By Regular People (Not Just PhDs/Gurus)
Again, this was part of the design basis of TapRooT®. Mark Paradies, a human factors expert, used his knowledge of cognitive processes and investigation problems to develop a system that was designed to be user-friendly (easy-to-use) for everyone. And this usability has been tested formally and informally by hundreds of thousands of users. This is explained more extensively in section B.4.1.
B.4.5 TapRooT® Is Robust (Repeatable/Defendable)
I can’t count the number of people who have come up to me after being trained in TapRooT® and using the system to analyze an example in a course and exclaim:
“I was really surprised that we all had very similar answers.”
Often, these people are familiar with the wide variations that people experience when using fault trees, cause-and-effect, or fishbone diagrams. They are used to “voting” on causes. They didn’t realize that root cause analysis should be based on evidence (instead of deductive assumptions).
This isn’t to say that really smart people can’t be creative when developing corrective actions. They can. But it is a comment on how TapRooT® levels the playing field so that a vast majority of users come up with solid root cause analysis and effective corrective actions because … that’s what TapRooT® was designed to do.The other comments I commonly hear are on management’s surprise when the root causes are defendable. When management asks questions, the replies aren’t just the opinions of the investigator. When the investigator can show what best practice was missing and their evidence. Even better is management’s reaction to a thorough explanation using a SnapCharT® to explain what happened before the root causes and corrective actions are discussed. The best defense is not having to defend your corrective actions because it is obvious why they are needed. That’s what TapRooT® can do for an investigation.B.4.6 TapRooT® Is Tested – Proven Successful in Improving Performance.I won’t repeat the list of testing provided under the evaluation of the first must. I will point out the list of success stories from leading companies at the TapRooT® web site (www.taproot.com).B.4.7 TapRooT® Is Well Documented.You are reading the documentation. From:
• The foundation of TapRooT® (Chapter 1), to
• The ways that TapRooT can be used (Chapter 2), to
• How to use TapRooT® for reactive investigations (Chapter 3), to
• How to use TapRooT® for proactive improvement (Chapter 4), to
• Details about measurement and advanced trending techniques (Chapter 5), to
• An explanation of a variety of whats to implement the TapRooT® System in existing improvement programs or a stand-alone improvement system (Chapter 6), to
• Detailed explanations of how to use each major TapRooT® Tool (SnapCharT® – Chapter 7, the Root Cause Tree® – Chapter 8, Equifactor® – Chapter 9, Safeguards Analysis – Chapter 10, Change Analysis – Chapter 11, and CHAP – Chapter 12), to
• Appendix A that describes the standard policy, forms, and tools you need to prepare for investigations, to
• The Root Cause Tree® and Root Cause Tree® Dictionary documentation,
You have a very complete set of readable, useful guidance.
B.4.8 Must Have Excellent Training.
Why did over 10,000 people attend TapRooT® Training in 2007? At least part of the answer is the excellence of the training and the excellence of our instructors from around the world. Without excellent training and instructors, even a superior system would have trouble being distributed to a large user base.
But everyone offering root cause training says that their training is good … right? Do they guarantee it? Will they give you your money back? Or do they say that you can attend another of their courses if you weren’t happy with the first one?
Here is the TapRooT® Training Guarantee that has been in place since 1992:
Attend the TapRooT® Training. Learn the TapRooT® System and take the information you gain back to your facility. We guarantee that when you apply TapRooT® you will find root causes that you previously would have overlooked and that you and your management will agree that you developed corrective actions that are much more effective. If TapRooT® lets you down on either of these promises, just let us know and return your course materials and we will refund the entire course fee.
The guarantee shows that we stand behind our system and our training.
B.4.9 TapRooT® Has a Database for Organizing, Sharing, Saving, and Trending Info.
The patented (two US and international patents) TapRooT® Software supports single user, network, and internet software that includes a database for organizing, sharing, and trending information. It is used by major corporations around the world. And we continually reinvest in development to keep the software up-to-date.
B.4.10 Must Have Unique Categories for Trending.
The Root Cause Tree® provides the unique categorization needed for trending. The advanced human performance and equipment reliability technologies behind the categorization are described in Chapter 1. The use of categorization itself is defended in Chapter 8. What more can be said?
B.5 Use TapRooT®
We believe that we have worked so hard to research the needs of investigators, the cognitive limitations and abilities of human investigators, the best practices for investigation and improving performance, and have done such a good job at building these into a usable, systematic, repeatable, defendable investigation system that there is nothing else to compare to TapRooT®. You can take advantage of the millions of dollars of investment and enjoy a process that helps you continuously improve performance.
One more note. At System Improvements, we aren’t resting on our laurels. We will continue to invest in TapRooT® – to improve the tools, training, and software – to keep TapRooT® at the leading edge of root cause analysis technology. We hope that you agree and use TapRooT® … Become a part of changing the way the world solves problems.