September 17, 2005 | Mark Paradies

Faster Investigations / “Mini” TapRooT(R) Ideas

One of our clients sent the following question:

We are looking into options of what tool to use for our low level incident investigations. One option at the moment is to look at using a modified TapRooT(R). I am wanting to identify other organizations that use TapRooT(R) for low level incident investigations with a contact name so that I can discuss the issue with them.

Are you able to help?

One of our clients sent the following question:

We are looking into options of what tool to use for our low level incident investigations. One option at the moment is to look at using a modified TapRooT(R). I am wanting to identify other organizations that use TapRooT(R) for low level incident investigations with a contact name so that I can discuss the issue with them.

Are you able to help?

– – –

Here are the answers I received in the order they were received…

– – –

First I would suggest talking to Jim Thatcher who has been a TapRooT(R) User for many years at three different sites and has also been a TapRooT(R) Instructor.

I will also put a note in the e-Newsletter in August and see what kind of response we get.

Finally, we are having a session at the Summit next April on this very subject. Just one of many things you can learn-about-discuss-benchmark at the Summit. Jim Thatcher will be one of the speakers in the Best Practices for Fast Analysis of Small Problems. The session description is:

TapRooT(R) works for investigations of all sizes – from major accidents to minor incidents, equipment failures, and near-misses. Of course, investigators want to be as efficient as possible when investigating an incident. This is especially true of small problems (for example, near-misses). Sanjay Gandhi and Jim Thatcher will lead this best practices session by sharing their ideas about performing fast analyses of small problems and practices that can help investigators save time and effort. Next the will lead the sharing by attendees of their best practices for saving time and effort without sacrificing investigation quality.

Also I’ll forward this to Ken and Jim, two of our instructors that you know, for their ideas.



– – –

Then I received this reply from Jim Whiting (our Australia TapRooT(R) Representative).

This has been a regular topic of conversation in the Expert e-Newsletter and at TapRooT(R) Summit.

My first reaction is that TapRooT(R)’s scaleability is achieved by varying the time spent on each step – not leaving steps out. Organizations using TapRooT(R) for different levels of investigations don’t cut steps out of the TapRooT(R) process – rather they change the time on each step – less or more as appropriate.

Hence SnapCharT(R)s are often smaller but still as complete as wanted and needed.

Less information leads to less (but usually the “key”) CFs – Causal Factors which means less RCA runs through the Tree giving often less but “key” RCs and less RCs then means less Corrective Actions (CAs).

Other time savings are achieved by careful consideration of who does each step in the process. I know some organizations who allocate RCA only to a small number of specialists but everyone does SnapCharT(R)ing – from small to big charts.

The net effect is less time spent (and sometimes depth) but usually with a high level of confidence of having found the “major” or “key” RCs and hence the “major” or “key” CAs.

Besides a response from Mark, you may also want to talk to the following Australian TapRooT(R) Users:

John Sargaison


Chris Jackson

Apache Energy

Brett Nicholson


Peter Canny

KCGM – Kal Gold

Hope this helps



Jim Whiting

Managing Director & Principal Risk Engineer


– – –

Next, Jim Thatcher wrote the following about the Summit Session:

– – –

Thank you, Mark.

I will certainly be able to share some experiences on using the TapRooT(R) System for investigating “small incidents”. I??used the system to investigate??any instance that was “not planned for” in operations, such as procedures,??MOC’s, practices not being followed, etc.??The incident was investigated by a small team, reviewed by local management and forwarded to me for inclusion into the manager’s review of weekly activities every Monday morning. The system really works well.


Jim Thatcher

– – –

Jim Thatcher wrote to the TapRooT(R) User:

Good evening.

My name is Jim Thatcher. I have used the System Improvements TapRooT(R) methodology since 1997. The last several years one of my clients was a small oil and gas service company. They have limited resources and very limited safety personnel in the field. I helped them design a “short form” way of using the tap root method and reduce it to a manageable format, while not losing the intent or structure of the methodology. They still identify causal factors, still find root causes for each causal factor and assign corrective action(s) to each root cause.

I will be glad to share this format with you if you would like to see it.


Jim Thatcher

(Note – Jim will be sharing this information at the TapRooT(R) Summit – April 5-8, 2006 – in Gatlinburg, TN.)

– – –

From another TapRooT(R) User:


I have been using the system for years, I have never taken the time to develop a simplified version of the??TapRooT(R) process. However, I do find that it would be very useful to have such a technique, since in most organization, the full blown process does not get utilized since it takes so much time and personnel will only spend that kind of time on the major events, which happen infrequently. This also, creates a situation where people lose their ability to perform TapRooT(R)s since they do not get to do them very often.

I have a attached a WORD document that outlines a work-flow of how I do things. Basically I skip / add steps based on the situation. You are welcome to??share it, just remove my name and company.


(Note from Mark Paradies – this document is based on the old TapRooT(R) Software and the old TapRooT(R) Manual. I have made notes to let people know about new features in the software that make the process easier. Also, EVERY TapRooT(R) User should have the TapRooT(R) Book (first published in 2000) because of the wealth of information that it offers and the updates it provides to the Root Cause Tree(R) and Dictionary.)

1. Explain the TapRooT(R) process and the goal of the investigation. Focus on Fact Finding.

2. Discuss the definitions of EVENTS & CONDITIONS. Distribute copies of the documents. Give the team time to read them and tell them to look for events and try to associate an order with each event.

3. Start to develop the SnapCharT(R). Get events first then go back and list the CONDITIONS. Be sure to include positive conditions. Add detailed notes to the conditions as needed. Develop the EVENTS portion first. Add notes as needed. Use a dotted line to distinguish the ASSUMPTIONS. Add dates and times as known.

4. Add conditions under each EVENT. Review the definition of CONDITIONS and provide some examples.

??? What do we know about the EVENT?

??? Have someone who was involved validate the SnapCharT(R).

??? Add SAFEGUARDS that worked and failed.

??? Finalize the conditions before moving on

5. Choose ???CAUSAL FACTORS??? ??? CF Tag

??? CAUSAL FACTOR ??? Condition that if removed would keep the incident from happening or make it less severe in its consequences.

??? These are the items that we will analyze in more detail.

??? If in doubt, choose it and root-cause it to see if it is a real CF

??? Add a note to each CF on ???Why the team chose it???.

(Note by Mark Paradies – people who have attended more recent courses have seen even more information on defining Causal Factors including grouping, the “So What” method, and organizing Causal Factor information into a hierarchy. Use these ideas too.)

6. Add notes to the conditions that were NOT chosen as to why the team did not choose it as a CF.

??? The team did not choose this condition as a CF due to???

7. Import the SnapCharT(R) into the TapRooT(R) Software.

(Note by Mark – this step is no longer needed in new Software)

8. Choose the first Causal Factor and work it through the Root Cause Tree(R).

??? Use the ???*??? to add notes to why each ROOT-CAUSE is chosen.

??? Click on the CA?

??? Click on the RC?

??? Remember ??? Management must be able to control root-causes or fix them.

(Note by Mark Paradies – new software includes “right click” menus. Also, everything on the Root Cause Tree(R) is fixable by management.)

9. Develop ???recommended??? Corrective Actions for each root-cause that was chosen.

??? Remember you can click on the CA? to give the team an idea of what type of CA can be suggested.


??? S = Specific

??? M = Measurable

??? A = Accountable

??? R = Reasonable

??? T = Timely

??? E = Effective

??? R = Reviewed

(Note by Mark Paradies – Corrective Action Helper(R) is now available by right clicking and in the Corrective Action Development portion of the new software.)

10. Develop the DRAFT Report and allow the team to review it for accuracy.

??? Don???t forget to DE-TAP-ROOT the report.

??? Do not leave the Root Cause Tree(R) in the report.

??? If you leave the Root Cause Tree(R) in the report, it will only confuse the people who read it

11. Add attachments:

??? Pictures

??? Diagrams

??? Copies of documents as required

??? Do not include items that are explained in detail in the report

??? NO NAMES, use titles

12. Finalize the report with the investigation team

13. Review the report with key management personnel and make changes based on their input.

??? Do not alter the facts of the report, but be sensitive to the recommendations made by key management.

??? If they want to change something that would alter a fact, discuss it with them to resolve any issues.

14. Have a peer review of the report.

15. Add the Corrective Actions to Action Track and add the Action Track numbers to the report.

(Note from Mark Paradies – Corrective Action Tracking is part of the new software.)

16. Create a PDF file.

17. Print the final report and have key management personnel sign it.

18. Scan the signed version and forward a copy of the PDF file to permanently archive.

– – –

Here are my ideas about saving time when investigating “minor” incidents, near-misses, and other small problems…

1. First, the best way to save time investigating minor incidents is to STOP investigating things that aren’t worth investigating. So ask yourself the question:



In answering this question you should ask yourself:

a. Are the consequences serious enough to be worth the effort of the investigation investment?

b. What will be the return be on my investment in investigation time and effort?

c. Is this an failure that could lead to more serious failures or are the consequence of this failure minor at best?

d. Is this a repeat failure that happens so frequently that stopping multiple repeat failures is worth the investigative effort?

e. Is this some management, regulatory, or public relations “hot button” that may be worth investigating for political reasons?

If the incident is not worth investigating, you should at least record the event in a database so that you can trend the failure type and location. Future data may show an increasing trend of failures or an unacceptable rate of repeat failures.

If you are concerned that you may miss something that really was worth investigating remember: Most investigations done halfheartedly are done so poorly that the real causes are not discovered and the corrective actions are a waste of time and effort. Therefore, investing real effort in fewer investigations will probably lead to faster, better improvements than the same amount of effort spent on more, but poorer investigations.

If you think you should do more to improve performance, invest your effort in proactive observations/assessments/audits that can be targeted to high risk areas and produce even faster, more effective improvements.

So the bottom line is: If it is worth investigating, it is worth finding and fixing the root causes. If it is not worth investigating, DON’T INVESTIGATE IT. Just categorize and trend.

2. Next, if an investigation is worth investigating then it is worth finding root causes and implementing corrective actions to prevent the incident’s recurrence. But not all investigations are created equal. You need to decide the level of effort that you will invest in the investigation. Here are some sample “levels” of investigation:

a. Serious Accident: The level of damage or loss caused by the accident means that this investigation will probably get regulatory, senior management, shareholder, and potentially public attending. The extreme consequences means that this will also be the most difficult type of investigation. This type of investigation will take a dedicated team of highly trained company investigators and consultants to conduct a thorough review of all evidence. The complete suite of TapRooT(R) Techniques will be employed. A considerable investment in time and resources will be required as well as senior management review or the investigation results and potentially an independent review by a highly experienced outside reviewer. This is obviously NOT they type of investigation imagined by this question.

b. Serious Incident: The level of damage or loss caused by this incident is worthy of investigation and root cause analysis. This incident is serious because it cause damage just below that required to trigger a “Serious Accident” investigation or because it could have easily caused a Serious Accident with slightly different circumstances or without the intervention of luck. This investigation will be similar to the investigation above with the exception that some of the team members may be slightly less experienced, less consultants will be used, and the review of the investigation will be by local management and an investigation peer review committee made up of local investigation experts. Once again, this investigation is above the “minor” investigation posed by the users question.

c. Incident: This incident caused minor damage or loss and there was at least one significant safeguard (which was NOT luck) to keep the incident from becoming a Serious Incident. In this case, a single investigator or a small investigative team may be used to perform the investigation and only two tools will be used to perform the investigation: SnapCharT(R) and the Root Cause Tree(R). These types of incident investigations will receive a brief review by the peer review committee but will not receive management review unless a trend is detected. Ideas presented below will be used to save time and effort in these investigations

d. Recordable Event: These events are judged to NOT be worthy of investigations. The type of event, organization, and the location are recorded in a database to allow trending. Since no investigation is performed, no corrective actions are recommended and future recurrence of the event is possible. Trends will be used to detect significantly increasing frequency of these events.

A tip for the nuclear industry. All “significant conditions adverse to quality” should be rated as an incident or above and therefore deserve root cause analysis. If it is not a significant condition adverse to quality and it is not in another category that makes it significant (cost, delayed startup, personnel injury, non-nuclear environmental release, …), then you should categorize it and NOT waste time doing some sort of halfhearted “Apparent Cause” evaluation that will waste time and corrective action effort implementing fixes that aren’t effective.

3. There are several ways investigators can save time in performing minor investigations of incidents that just barely make the cut for the “incident” category above. Here is a short list of the more beneficial ideas I’ve heard:

a. Training and Practice: The best way to waste time and effort on investigations is by using untrained, inexperienced investigators. The more investigations an investigator performs, the better and FASTER they become. The best way to gain experience at the least cost is by performing proactive investigations and by participating as junior members of investigation teams investigating more serious incidents. Also, the more training you can afford, the better investigator you will be. People who take the 5-Day TapRooT(R) Course get more experience in the course and are better and faster investigators than those who attend the 2-Day TapRooT(R) Course. And of course the 2-day trained investigators are better than untrained investigators. Those who attend the TapRooT(R) Summit get even more training in the Advanced Investigation Skills Track, the Human Performance and Behavior Change Best Practices Track, or the Equipment Reliability and Maintenance Best Practices Track. All your investigators should be continually improving their skills and thereby become better, faster investigators.

b. Spring SnapCharT(R): The most time consuming part of an investigation is the collecting information needed to draw a good SnapCharT(R). A little pre-planning can go a long ways to save time in an investigation. First, draw a preliminary SnapCharT(R) to get started. This will help you decide where you have missing and conflicting information. You can plan where you need to look to find more information. You can avoid wasting time looking for information that isn’t applicable to your investigation.

c. Lunch Meetings: Hold three 30 minute “lunch meetings” to perform a rapid investigation of an incident. The company provides the lunch (pizza, sandwiches, …) for the attendees and they supply the help an investigator needs. The first 30 minute meeting is held to get a complete Summer SnapCharT(R) drawn. A single investigator can put this SnapCharT(R) built using Post-It Notes into the TapRooT(R) Software in about 30 minutes. Or you can train an admin person to do this for the investigator and save even more time. The investigator will also identify the Causal Factors (time spent 30-45 minutes). Then the investigator can hold another lunch meeting to review the SnapCharT(R) and Causal Factors with those involved to get agreement that the chart and Causal Factors are accurate (30 minutes). After this meeting, the investigator then takes the Causal Factors through the Root Cause Tree(R). The investigator does NOT go “circle happy (circling every possibility that could have contributed to the incident) but rather ONLY identifies the root causes that indisputably will prevent the recurrence of the incident if they are corrected. The investigator should take no more than 10 to 15 minutes per Causal Factor in going through the Root Cause Tree(R). On average for minor events (with just 2 or 3 Causal factors), this should take about 30 to 40 minutes. The investigator then holds a third lunch meeting with the right people (perhaps some additional attendees) to develop effective corrective actions (with the help of the Corrective Action Helper(R) module of the TapRooT(R) Software. Finally, the investigator takes an addition 30 minutes to 1 hour to finish the documentation in the TapRooT(R) Software and initiate any work orders required to implement corrective actions. Total investigator time spent – about 3 to 4 hours. The time required for other participants is limited to the three 30 minute lunches. Since this time was also spent eating lunch, there is essentially no cost (besides the cost of lunch) for this time.

d. Skip Generic Root Cause Analysis: When causal Factors are taken through the Root Cause Tree(R), Specific Root Causes are identified. The next step in the TapRooT(R) process is to check to see if there are Generic Causes for the Specific Root Causes. For less serious investigations, the investigator can skip this step. The identification of Generic Root Causes for the more minor investigations can be left for the trending system to identify.

e. Reduced Review: All investigation that are going to have root causes recorded in the database and corrective actions should have a peer review. For minor investigations this peer review should be limited to 15 minutes. additional investigation or changes in corrective actions should be allowed for only the most glaring errors. Instead, this review should be focused on providing feedback to the investigator to improve their skills (an thus make future investigations better and faster). The peer review should comment about what was good about this investigation and what could be improved in future investigations and corrective actions. A timer should be used to insure that the review does not take more than 15 minutes.

f. Trained Supervisors: One major slow down in investigations is trying to piece together or recreate evidence that was destroyed before the investigator arrives. Broken parts are cleaned up and thrown away. Records are misplaced. Souvenirs are taken by onlookers. Witnesses depart or confuse their observations by having discussions with others. To prevent this loss of basic evidence, supervisors, who might be the first to arrive on the scene after and accident or incident, should be trained to collect and preserve evidence. This can save hours, days, weeks, or months from an investigation. Or it might make an investigation possible when otherwise, with lost or contaminated evidence, it would be impossible.

g. Trained Management: A true waste of investigative effort and time is presenting investigations to management and have them send the investigator back to do more investigation or change reports because the managers do not understand root cause analysis or how it can help them improve performance. This is especially true when management does not understand that by finding and correcting Management System causes, investigations can make major improvements in the way a facility is managed and potentially save manager’s jobs (by avoiding a major accident). Management can also cause time to be wasted by insisting on mini-root cause analysis for events that don’t deserve investigations, assigning untrained investigators to perform investigations, requiring reports in too little time (“Have it on my desk in the morning.”), or not insisting on good root cause analysis (instead they accept poor investigations with what seem to be easy to implement – but ineffective – corrective actions.

Show Comments

Leave a Reply

Your email address will not be published. Required fields are marked *

Follow us on Facebook
Follow us on Twitter
Check out our videos
Join us on LinkedIn