Creating a Simplified Fault Tree for Root Cause Analysis

Step 1. Define an event of interest as the TOP event of the fault tree

Clearly describe a specific, known event of interest for which you will explore the potential underlying causes. Events such as the primary events and conditions and the secondary events and conditions can be the events of interest. Examples might be, "Flow control valve FCV-1 opened prematurely" or "The room temperature was greater than 80 ºF." Typically, the event of interest for a fault tree is an equipment or system failure or a human error.

When using a fault tree as the primary analysis tool, the accident is the TOP event.

Step 2. Define the next level of the tree

Determine the combinations of events and conditions that can cause the event to occur. If two or more events must occur to cause the event, use an AND gate and draw the events under the AND gate. For example, for a fire to exist, fuel, an oxygen source, and an ignition source must all occur simultaneously. If there are multiple ways for an event to occur, use an OR gate. For example, the fuel for a fire can be paper or gasoline.

Regardless of whether an AND gate or an OR gate is selected, this level of development is a "baby step." It should be the smallest logical step, within reason, toward the underlying potential causes of the event above it. Taking too large a step can cause you to overlook important possibilities. Remember to include equipment failures, human errors, and external events as appropriate.

After the tree level is developed, test the tree for logic. Start with each event at the bottom of the tree. Does the logic of the tree reflect your understanding of the event or system? If an event is connected to an OR gate above, then it must be enough to cause the event above. If an event is connected to an AND gate above, is it required to cause the event above? Must ALL of the other events connected to the AND gate also occur for the event above to occur?

Step 3. Develop questions to examine the credibility of branches

Develop questions to test the credibility of each branch. What evidence would be present if this branch were true?

Step 4. Gather data to answer questions

Gather data to answer the questions that were generated in the previous step.

Step 5. Use data to determine the credibility of branches

Use the data gathered in the previous step to evaluate which branches of the tree do or do not contribute to the event of interest. Do the data support or refute the presence of this branch? Do you have sufficient information to determine the credibility of the branch? If not, you need to gather more data or continue on to the next level of the tree. Cross out any branches that you can dismiss with high confidence, and list the specific data used to make this determination beneath the crossed-out branch.

For chronic problems, assigning probabilities (i.e., percentages) to the various events will help characterize the types of events that occur most often. For chronic events, you may not be able to address every type of event that occurs, so you need to focus on those that occur most frequently. These percentages will be used in Step 6 to determine if we need to develop the event further.

If all branches leading to the event of interest through an OR gate or one or more branches leading to the event of interest through an AND gate are eliminated, either (1) the event of interest did not occur, (2) some of the data are inaccurate or were misapplied, or (3) other ways exist for the event of interest to occur.

Step 6. Is the branch credible?

Determine if the branch is credible. For acute problems, if the branch is credible, continue on to Step 7. If the branch is not credible, proceed to Step 8. For chronic problems, if the percentage of events for this branch is high, continue on to Step 7. If the percentage of events for this branch is low, proceed to Step 8.

Step 7. Is the branch sufficiently developed?

Determine if the branch is sufficiently developed. The branch is complete when it is detailed enough to allow an understanding of how the top event occurs. If the branch is not complete, return to Step 2. If the branch is complete, move on to Step 9.

Step 8. Stop branch development

There is no reason to develop the branch further if you have determined it is not credible. Stop development of this branch and move on to Step 9.

Step 9. Stop when the scenario model is "complete"

The model is complete when you have a clear understanding of how the accident occurred. Keep your model "barely adequate" for identifying the issues of concern for your analysis; avoid unnecessary detail or resolution that will not influence your results. For acute problems, if you have more than one possible way for the event of interest to have occurred and cannot gather data to dismiss any of the remaining possibilities, you should consider each as a potential causal factor and make recommendations to prevent each. For chronic problems, you will typically need to address a number of primary contributors to the event of interest.

Step 10. Identify causal factors (optional)

If the fault tree method is being used as the primary analysis tool, causal factors should be identified.

Remember, you need not be, and probably will not be, the subject matter expert for the analysis. Use the expertise of others to help you develop the fault tree structure and apply the known data to dismiss branches appropriately.

Use Post-it^® Notes to "draw" the tree

• Allows for rapid revision of the tree
• Use different colors for different items
  • green (events)
  • yellow (OR gates)
  • pink (AND gates)

Conclusions about 5 Whys

• Resulting subevents and conditions should be at or near the root causes of the event
• More or less detailed evaluation may be necessary for some cases to reach management system root causes
• Judgment and experience are key factors in selecting the right level of evaluation and the completeness of results
• This technique can be time consuming compared totechniques that do not require brainstorming
• This technique works, even when the management systems are ill defined
• The results are not reproducible or consistent, but the application is auditable

Source: USCG Risk-based Decision-making (RBDM) Guidelines.

Certisafety Section Home Page