Root cause checklists

EPA ARIP Responses to questionnaires sent by EPA from facilities that have had significant releases purpose is to learn about causes and consequences of hazardous material incidents 1986-Present Supplements NRC reports for more significant events Additional information on causal factors, consequences, and company safety programs Data are easily analyzed for common causes Includes all states and localities Survey relies on voluntary compliance Not comprehensive limited to select cases Checklist approach limits value of information to understand root cause Not designed to be a lessons-leamed database... 

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. 

Checklist analysis tools can be a user-friendly means to assist investigation teams as they conduct root cause analysis.h) Each causal factor is reviewed against the checklist to determine why that factor existed at the time of the incident. The Systematic Cause Analysis Technique (SCAT)(9> is an example of a proprietary checklist tool. 

The comprehensiveness of the various checklists varies greatly. Some are very detailed with numerous categories and suhcategories, whereas others do not reach down to the level of root causes. 

A disadvantage is that a checklist may allow an investigation team to jump to conclusions, and does not provide the opportunity to think outside the box. This is especially important if the checklist is one of the less comprehensive types. It is also tempting to use the checklist too early, before all causal factors have been identified. Be sure to determine what happened and how it happened before determining why it happened. Otherwise, the team will think it has identified the right root causes, when in reality not all of the root causes have been determined. 

Checklists may also be used to supplement other tools for example, checklists on human factors may be used in conjunction with logic trees. Similarly, checklists may be used in combination with structured brainstorming tools such as What If/Checklist and Hazard and Operability (HAZOP) Analysis.(P It is also a good practice to apply a tool like the 5-Whys to the root causes identified from the checklist to verify whether they are truly 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. 

CHECKLISTS - Root cause investigation methods often include a set of integrated and comprehensive checklists (or accompanying reference documents) to ensure that common generic causes and issues are considered. 

Chapter 9 describes the use of human factors checklists in root cause analysis. 

This step is always performed. Using analysis tools and methods such as fault trees, causal factor charting, checklists, predeveloped trees, or alternative methodologies will help to identify the root causes of the failures. 

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

Checklists of varying content and detail are used in incident investigation methodologies as a user-friendly tool to assist root cause analysis. Sometimes a comprehensive checklist may be used as the primary root cause analysis tool, or alternatively a checklist may be simply used to supplement another primary tool. 

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. 

The use of checklists to supplement another root cause analysis method can be a very powerful technique, for example, human factors checklist(s) may be used in conjunction with logic trees. The checklist may be used as a guide during development of a logic tree, or as a check after the tree has been developed. The checklist essentially acts as a memory jogger to direct the investigation team. This is especially helpful if the team lacks previous experience in the subject matter. 

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

Checklist approach limits value of information to understand root cause... 

It was noted in Chapter 1 that major incidents tend to be rooted in process safety rather than occupational safety deficiencies. Therefore, one way of looking for root causes using a categorization approach is to create a checklist based on the elements of process safety as listed in Chapter 1. 

Out of the hazard log a checklist was created, asking for the root causes of these hazards. The questions are assigned to different roles in a project where development is performed. The respective employees get their questions on a sheet and have to answer these questions and return the filled in and signed sheets before the system integration phase begins. 

Based on the root cause and classification of coupling, there are three separate sets of checklists for CCF avoidance, viz. preparation, execution, and restoration. There are cause-defense matrices available, which shall include CCF, root cause, coupling factor, defense alternatives impact, and cost, etc. For further details [1,6,7] may be referenced. With this discussion on failure types concluded, we move on to look at reliability issues. 

Conducting frequent inspections, using a checklist, to evaluate physical conditions. Investigating loss-producing events thoroughly to determine the root cause and how hazards can be minimized or controlled. 

Scenarios are used to highlight unwanted incidents, potential accident or loss of science in a particular project or activity. The scenarios are based on findings from the checklist, discussion with the design team to identify conditions where there are some unease or based on discussing key root causes from known documented accidents. The scenarios with errors and recoveries are modelled by using a simple STEP analysis, where critical steps are... 

An early phase of the CRIOP process is to pick relevant items from the total checklist. In our validation, the checklist items from CRIOP included potential incidents. These items were similar to the root causes identified in the survey. 

NOTE 1 The evaluation of the potential dependent failures plausibility can be supported by appropriate checklists, e.g. checklists based on fleld experience. The checklists provide the analysts with representative examples of root causes and coupling factors such as same design, same process, same... 

The following (example) checklist is intended to serve only as a guide to possible causes of an incident. The list is not complete, but should function as a starting point to help guide the analysis team toward finding both the immediate, and most importantly, the root cause. 

We will later apply the accident-analysis framework in a review of different types of methods used in the collection and analysis of data of accident risks. We will start at the output side of the model by reviewing the different types of classification systems used to document the consequences of accidents and different measures of loss. We will then continue by looking into the classification systems used to document incidents and deviations. Finally, we will review the different classification systems for contributing factors and root causes. Our aims will be twofold first, to be complete, i.e. by presenting all alternative means of measuring and classification, and second, to give specific advice on the preferred method. The reader will find recommended alternatives in shaded tables and checklists. 

The theoretical basis of the different causal models becomes more obvious at the upper management level. MORT was the first comprehensive model to include organisational and individual factors at the top management level. At this level, it draws from quality assurance management principles. The SMORT and ILCI models have been influenced by this pioneering work and represent variations on the same theme. The concept of root causes originates from the MORT model. The checklist above shows the different items of a root-cause analysis. 

The purpose of the hazards checklist is to prevent hazards in a new project that are similar to hazards already known in other systems. Checklist questions are derived from existing hazards, asking for the root cause mechanisms of those hazards. For every product family the applicability of the checklist questions is decided. All applicable questions have to be answered prior to a product release to increase the awareness of the developers of the possible problems and to avoid their inplemen-tation. 

Procedure development. People often learn, or are reminded, how to perform a task through procedures, and it is highly likely that most people will forget how to do tasks that are not repeated with frequency, hence the need for written procedures. Additionally, procedures often include checklists and forms that provide extra control and documentation to help ensure that work is performed properly and in accordance with established methods and safety precautions. Lack of procedures or a failure to follow procedures is a key root cause in many incidents and near misses both large and small. 

---