Root cause predefined trees

This chapter addresses methods and tools used successfully to identify multiple root causes. Process safety incidents are usually the result of more than one root cause. This chapter provides a structured approach for determining root causes. It details some powerful, widely used tools and techniques available to incident investigation teams including timelines, logic trees, predefined trees, checklists, and fact/hypothesis. Examples are included to demonstrate how they apply to the types of incidents readers are likely to encounter. 

This useful companion disk contains root cause analysis examples, predefined tree examples, practical checklists that can be customized, and incident evidence photograph examples. It includes a quick checklist for investigators traveling to an incident, examples of methodologies that may be usefiil in training the onsite team, and checklists and samples from the text that can be printed out at the incident site to help organize the team s work. 

In general, the companies surveyed use one of two main methodologies to determine root causes. The first involves timeline construction followed by logic tree development. The second involves timeline construction, identification of causal factors, followed by the use of predefined trees or checklists. These two approaches are discussed in detail in Chapter 9. 

Once the causal factors have been identified, the factors are analyzed using a root cause analysis tool, such as 5-AVhys or predefined trees. See Chapter 9 for a more detailed discussion of Barrier Analysis (sometimes called hazard-barrier-target analysis or HBTA) and Change Analysis (also referred to as Change Evaluation/Analysis or CE/A). In essence, these tools act as a filter to limit the number of factors, which are subjected to further analysis to determine root causes. 

Like checklists, the comprehensiveness of the various predefined trees varies. Some are very detailed with numerous categories and subcategories, whereas others may not fully reach root causes. This is hardly surprising, as the predefined trees are essentially a graphical representation of numerous checklists, organized by subject matter, such as human error, equipment failure, or other topics. The more comprehensive techniques were developed from many years of incident experience and management system experience across the chemical and allied industries. 

The use of predefined trees is also discussed in detail in Chapter 9. See the accompanying CD-ROM for examples of predefined trees, including Comprehensive List of Causes (CLC) and SOURCE/Root Cause Map. 

Figure 9-1, the two flowcharts describing root cause determinations using Methods A and B, presents general frameworks for root cause determination. Method A focuses on the logic tree method using a simplified fault tree approach. Method B focuses on the predefined tree method. 

Root Cause Determination Using Predefined Trees— Method B... 

FIGURE 9-27. Flowchart for root cause determination— predefined tree/checklist. 

The causal factors need to be examined further to determine why those factors existed. The investigation team may use a predefined tree to examine each causal factor individually. The first causal factor is analyzed starting at the top of the tree, and then working down all of the branches as far as the facts permit. When an appropriate subcategory on one of the branches is identified, it is recorded as a root cause. The remaining branches are checked as one causal factor may have multiple root causes. The procedure is then repeated for each causal factor in turn. 

Several quality assurance tests should be applied when using predefined trees. Firstly, predefined trees are designed to capture most root causes, but may not be comprehensive. A completeness check should be conducted on each branch of the tree to see if there are other root causes associated with the category of that branch that are not listed on the tree. 

Some predefined trees do fully reach down to the root cause level. A system test should be applied to each identified root cause to ensure that it relates to a management system failure. By applying the 5-AAdiys tool to each cause identified at the end of the relevant branches of the tree, the investigator can determine if another underlying cause can be identified. 

Once the actual incident scenario is understood and its multiple causal factors identified, this information may be used to determine the incident s root causes. One means of performing root cause analysis involves the use of ready-made, predefined trees. A predefined tree provides a systematic approach for analyzing and selecting the relevant elements of the incident scenario. It is a deductive approach, looking backward in time to examine preceding events necessary to produce the specified incident. 

Unlike the procedure followed in developing logic trees, the investigation team does not construct the tree. Rather they apply each causal factor to each branch of the predefined tree in turn, and those branches that are not relevant to the incident are discarded. This prescriptive approach offers consistency and repeatability by presenting different investigators with the same standard set of possible root causes for each incident. 

While the use of predefined trees does not directly challenge the investigation team to think laterally of other possible causes, many predefined trees present a wide range of causal factors, some of which the team may not have otherwise considered. It is therefore possible, but unlikely, that the incident could involve a novel root cause that was not previously experienced by those who developed the predefined tree. The addition of a final test based on another tool, such as brainstorming, can overcome this apparent weakness. 

Although there are differences between various predefined trees, the basic method to perform a root cause analysis using the trees is similar whichever tree is used. The following basic steps apply ... 

Predefined trees are relatively easy to use and generally require less training and effort to conduct root cause analysis tban logic trees. 

Each of the causal factors can now he analyzed for its specific root causes using a predefined tree, as shown in Figure 9-3 f. 

After the root causes have been identified from the predefined tree, a generic cause test should be applied. By considering the plant operating history, especially other incidents that may indicate repetitive failures, the investigator may identify other generic management system problems. 

Predefined trees are a convenient means of identifying root causes. Providing all of the causal factors have been determined, use of a comprehensive predefined tree should ensure that most, if not all, root causes are identified. Several quality assurance tests should help identify any remaining root causes. 

Varieties of public and proprietary predefined trees are available for use, although most owe some allegiance to MORT. The comprehensiveness of the different trees varies from some that may not fully reach root causes, to others that are very detailed with numerous categories and sub-categories. Several of these trees are listed in the appendix and examples of TapRooT SOURCE /Root Cause Map and Comprehensive List of Causes (CLC) < 4) are included on the CD-ROM. 

The use of checklists as a primary root cause analysis tool is virtually identical to the use of predefined trees. This is hardly surprising as most predefined trees are really a succession of checklists organized by subject matter (category) into an arrangement of branches within the tree. 

A timeline or sequence diagram is first developed, and then causal factors identified. Care should be taken to ensure that the checklist is not used too early. Be sure to determine what happened and how it happened before determining why it happened. Otherwise, the team will think that they have identified the right root cause(s), when in reality only one or two of several multiple causes have been determined. The causal factors are then applied one at a time to each page of the checklist(s) to identify relevant root causes. Those pages that are not relevant to the particular incident of interest are discarded. Similar quality assurance checks should be applied as those described for predefined trees. 

Checklists represent a root cause analysis tool that has similar advantages to, and ease of use as, predefined trees. 

The article (Rooney Vanden Heuvel, 2004) uses the term Root Cause Map as an equivalent to the term predefined tree, when the fourth step of the method B of root cause analysis is discussed. According to the article, root cause identification involves the use of a decision diagram called the Root Cause Map to identify the underlying reason or reasons for each causal factor . Fig. 3 shows a small part of a specific Root Cause Map that is reproduced from (CCPS, 2003). It is a subtree of larger decision tree. Displayed part helps the investigator identify detail causes in the SMS, namely, in a fraction of its component (iii) operation control. 

Integrated approach to the incident investigation requires certain modifications of the meanings of terms predefined tree, Root Cause Map and root cause. The modifications are specified below ... 

Predefined tree and Root Cause Map are not the equivalent terms in the integrated approach. The term Root Cause Map denotes only the set of final nodes from the predefined tree. Hence, the part ofRoot Cause Map that corresponds to Fig. 3 does not contain bold nodes and the upmost node. 

Predefined tree has to have specific properties in order to be suitable for the integrated approach. It covers not only all components of the SMS but also all components of safety culture. Hence, also the root cause definition has to be modified. It identifies a correctable failure(s) in management system or in safety culture. 

If the specific predefined tree conforms with the modification 2, then the relevant Root Cause Map is proclaimed to be the boundary of internal safety management. In this case it represents the complete and disjoint coverage of the union of SMS components and safety culmre components. 

Suppose that a causal factor chart is developed (see example in Fig. 1). However, there is no warranty, that each of the specific chains of underlying causes from the causal factor chart wiU be coimected to a corresponding generic chain of underlying causes from the predefined tree. Some of causal factors may have no root causes. 

Modified definitions of predefined tree and Root Cause Map encompassing the safety culture components were proposed since they seem to be useful and natural. 

---