Fault Tree Analysis: Map the Event Chains Behind a Single Failure

Fault Tree Analysis builds a top-down fault tree to analyse the logical combination of events that can lead to a specific failure or defect. You start with one failure you care about. You then work downwards, asking what must happen, or what could happen, for that failure to occur.

The structure matters. A fault tree is not a list of causes. It is a hierarchy. Each layer explains the layer above it, and logic gates describe how the lower events combine. An OR gate means any one of the child events is enough. An AND gate means every child event must occur together.

This tool sits in the Analyse phase of RDMAICS. By that point you have defined the problem and measured it. You know the failure exists and roughly how often. What you do not yet know is the pathway. Fault Tree Analysis gives you that pathway in a form a team can argue with, correct and agree on.

Reach for it when the failure is specific and the causal chain has depth. If your problem is one obvious cause with one obvious fix, a fault tree is overkill. If several different events can independently produce the same defect, the tree earns its place.

The worked example used throughout this guide is fictional. It is the sample data that loads with the tool, and it describes an invoice processing failure in a back office finance function.

The top event is called Invoice processing failure. It carries a probability of 0.35 and an OR gate. Below it sit two intermediate events. Data entry error has a probability of 0.22 and an OR gate. Approval delay has a probability of 0.25 and an OR gate. Both feed the top event.

Beneath those, four base events complete the tree. Illegible scan at 0.12 and Staff inexperience at 0.10 both feed Data entry error. Approver unavailable at 0.15 and Routing error at 0.10 both feed Approval delay. Base events carry no gate, because nothing sits beneath them.

The notes column adds context without adding numbers. Data entry error is flagged as the largest contributor. Approval delay is noted for its cycle time impact. Illegible scan points to vendor scan quality. Staff inexperience points to new hire ramp-up. Approver unavailable refers to out of office periods and meetings. Routing error refers to manual routing mistakes.

The tool works from a single table. Each row is one event. You fill in six fields, and the tool assembles the hierarchy from what you enter.

The Event or Node field is the name. Keep it short and factual. Illegible scan and Routing error are good examples. Avoid names that contain a solution or a blame.

Type tells the tool where the event sits. Use Top Event once, for the failure you are analysing. Use Intermediate for events that have causes beneath them. Use Base Event for the lowest level, the point where you stop decomposing.

Probability is the likelihood you assign to that event. Logic Gate applies only to the top and intermediate events, because only those combine children. Parent Event is the structural glue. It names the event directly above. The top event has no parent, shown as a dash. Notes carry the context your team will need in three months when nobody remembers why a row exists.

The tool returns a fault tree structure with the events arranged by hierarchy and parent relationship. It groups them into three bands: TOP EVENT, INTERMEDIATE and BASE EVENT.

At the top sits Invoice processing failure, shown with Probability 0.35 and Gate OR. Below it, the intermediate band shows Data entry error at probability 0.22 with an OR gate, feeding Invoice processing failure, and Approval delay at probability 0.25 with an OR gate, also feeding Invoice processing failure.

The base band shows four events, each with a dash in place of a gate and each labelled with what it feeds. Illegible scan at 0.12 and Staff inexperience at 0.10 feed Data entry error. Approver unavailable at 0.15 and Routing error at 0.10 feed Approval delay.

Read it downwards first, then upwards. Downwards tells you the story of how the failure happens. Upwards tells you which small events have influence far above their size. The tool also offers an AI review that explains the result in plain language if you want a second reading before you take it to a team.

A fault tree is useful because it narrows where you spend effort. In the sample, Approval delay carries the higher intermediate probability at 0.25, while Data entry error sits at 0.22. Those two numbers are close, which is itself a finding. There is no single dominant branch to chase.

Go one level lower and the picture sharpens. Approver unavailable at 0.15 is the highest single base event in the tree. Illegible scan follows at 0.12. Staff inexperience and Routing error both sit at 0.10. If you are choosing a first improvement, the base events are where the work actually lands, because they are the events you can change directly.

The OR gates matter here. Both intermediate events use OR, which means either branch alone can produce the top event. Fixing one branch completely does not close the other. That is an argument against single-fix thinking and in favour of a staged plan.

The notes field also guides the type of intervention. Vendor scan quality points outside your process boundary. New hire ramp-up points at training and support. Out of office periods point at delegation rules. Manual routing mistakes point at process design. Four base events, four very different kinds of countermeasure.

The most frequent error is decomposing too far. People keep adding layers until the tree is enormous and nobody can read it. The sample stops at seven events across three levels. Stop when the base event is something you can act on or measure. That is the correct depth.

The second error is mixing causes with symptoms. A fault tree describes events, not states of mind or performance ratings. Routing error is an event. Poor teamwork is not.

The third error is careless gate choice. An OR gate says any child is sufficient. An AND gate says all children are required together. Choosing OR when the real logic is AND will overstate how easily the failure occurs. All four gate positions in the sample tree use OR, and that is a deliberate statement about how the process fails.

The fourth error is treating assigned probabilities as measurements. Unless each number comes from counted data, it is an estimate. Record where each one came from in the notes, so the tree can be challenged honestly.

Fault Tree Analysis will not tell you whether your probabilities are correct. The tool accepts 0.35 for the top event and 0.15 for Approver unavailable without question. If those figures are guesses, the tree is a structured guess. It will look just as tidy either way.

It will not discover causes you did not enter. The tree contains four base events because four were supplied. Anything your team failed to think of is simply absent, and the tree gives no signal that something is missing.

It will not rank your improvement options or estimate a benefit. The structure tells you Approver unavailable sits highest among base events at 0.15. It does not tell you that fixing it is cheap, fast or even possible. Cost, feasibility and effort live outside this tool.

It will not prove causation. A fault tree is a logical model of how a failure could occur, built from what people believe about the process. It is a hypothesis you can test, not evidence in itself. Use it to organise your thinking and direct your next measurement, then go and confirm the branches that matter with real data. The tool offers an AI review to help you interpret the structure, but interpretation is not verification. That part is still your job.