Fault Tree Analysis — Working Backward From a Failure

FTA starts from a failure that already happened and works backward through AND/OR logic to its contributing causes — the standard tool for an OOS root-cause investigation, and the mirror image of FMEA’s forward-looking approach.
A banner titled 'Fault Tree Analysis — Working Backward From a Failure' with the tagline 'Find the causes. Fix the system. Prevent recurrence.' and the note that FTA starts from a failure that already happened and works backward through logic to its contributing causes — a standard tool for OOS investigations and a key part of a robust quality system. Panels: (1) The One Idea — FMEA asks, before anything has gone wrong, 'what could fail in this process?'; FTA asks, after something already has, 'what chain of causes could have produced exactly this failure?'; they run in opposite directions through the same failure space, and a mature quality system uses both, captioned 'Start with the failure. Work backward. Find the real cause. Prevent it from happening again.'; (2) Worked Example — OOS Assay Result (HPLC), a fault tree with the top event 'Reported assay result outside the specification range,' branching through an OR gate into Analytical/Laboratory Error (False OOS) and True Failure (Product Out of Spec); the error branch further ORs into standard out of date or degraded, system suitability failed but overridden or missed, sample preparation error, and instrument malfunction, each with a way to check it; the true-failure branch ANDs a manufacturing process producing an out-of-spec batch with no analytical error found in the investigation; captioned that an OOS investigation follows this logic — Phase I (laboratory investigation) works the analytical-error branches first, Phase II (full investigation) proceeds to the true-failure branch only if no assignable analytical cause is found; (3) Steps to Build a Fault Tree — a seven-step numbered list: define the top event (be specific), identify immediate causes, use AND/OR logic gates to build branches for all plausible pathways, continue decomposition by asking 'why' until reaching basic events, evaluate with data to confirm or rule out each basic event, identify root cause(s) (there may be more than one), implement and verify corrective actions; (4) Logic Gates — an OR gate (any one input can cause the event above, 'this or this') and an AND gate (all inputs must be present for the event above), with the note to use OR and AND gates to map all plausible causes, continuing until reaching basic events that can be confirmed or ruled out with data; (5) Example Basic Events (HPLC Assay) — a bulleted list: wrong diluent used, column contamination or carryover, incorrect mobile phase composition, detector wavelength mis-set, integration parameters changed, analyst transcription error, software/processing error, degraded reference standard, sample instability, environmental factor (temperature); (6) FTA vs. FMEA — Complementary Tools, a comparison table across direction (backward/reactive vs. forward/prospective), starting point (a specific observed failure vs. a process/method/system), purpose (find root causes vs. identify and prioritize potential failures), output (causal logic tree vs. Risk Priority Numbers and an action plan), use case (OOS investigations and deviations vs. analytical method development, process design, control strategy), and when to use (after a failure has occurred vs. before failures occur, and to check coverage after an event); (7) Strengths and Limitations — strengths (structured logical approach, ensures all plausible causes are considered, visual and easy to communicate, drives data-based investigation, links directly to corrective actions and prevention) and limitations (only as good as the top event's definition, can become large and complex, does not rank or prioritize causes, requires disciplined use of basic events, may miss systemic issues if the scope is too narrow, typically used alongside FMEA or risk ranking for a complete view), captioned 'Define the failure clearly. Use the data. Keep it focused. FTA finds the cause — your quality system prevents the next one.'; (8) Key Takeaways — FTA works backward from a defined failure using AND/OR logic; it is the standard tool for OOS root-cause investigations; the quality of the analysis depends on a clear top event and disciplined decomposition; FTA does not score or rank — it is a diagnostic tool, not a replacement for FMEA; use FTA and FMEA together to build a stronger, more resilient quality system. Footer: 'Science + Risk-Based Thinking = Better Medicines for Patients,' Temple University branding, and the tagline 'All science ultimately serves people.'

The one idea

FMEA asks, before anything has gone wrong, “what could fail in this process?” FTA asks, after something already has, “what chain of causes could have produced exactly this failure?” They run in opposite directions through the same failure space, and a mature quality system uses both.

Mechanics

A fault tree starts with a single, precisely defined top event — the failure that occurred — and branches downward through logic gates to the conditions that could produce it:

  • An AND gate means every branch beneath it must be true for the event above to occur (e.g., a wrong result reaches release and the reviewer misses it).
  • An OR gate means any one branch beneath it is sufficient (e.g., a degraded standard, a mis-set instrument parameter, or a transcription error could each independently cause a wrong reported value).

The tree bottoms out in basic events — causes you either confirm or rule out with data, not further decomposition. No formal Boolean notation is required to use this at the bench; the value is in the discipline of writing every “or this could have happened” branch down before deciding which one is true.

Worked example — an out-of-specification (OOS) assay result

Top event: Reported assay result outside the specification range.

Reported assay OOS
 └─ OR: Result is a true failure vs. a lab/analytical error
     ├─ OR (analytical/lab error branch)
     │    ├─ Standard was out of date or degraded
     │    │    → check standard prep date, storage conditions, prior QC data
     │    ├─ System suitability failed but was overridden or missed
     │    │    → review the suitability data logged that run
     │    ├─ Sample preparation error (dilution, weighing, transcription)
     │    │    → re-check the prep worksheet against the raw balance/pipette record
     │    └─ Instrument malfunction (detector drift, pump seal, injector carryover)
     │         → review instrument maintenance and diagnostic logs
     └─ AND (true-failure branch)
          ├─ Manufacturing process produced an out-of-spec batch
          │    → review batch record deviations, in-process controls
          └─ No analytical error found in the OOS investigation above
               → confirms the result should stand

An OOS investigation under Q7/GMP follows exactly this shape: Phase I (laboratory investigation) works the analytical-error branches first, because a confirmed lab error can invalidate the result without ever reaching the manufacturing branch; Phase II (full investigation) only proceeds down the true-failure branch once Phase I finds no assignable analytical cause.

When to reach for it vs. FMEA

FTA is reactive — it exists because a specific, already-observed failure needs a root cause, and it only makes sense once that top event is precisely defined. FMEA is prospective — it exists to find failure modes before they happen, and it doesn’t require anything to have gone wrong yet. In practice, a documented FMEA is often what an OOS investigation checks against: “was this failure mode already identified, and if so, why did the existing control not catch it?”

Known weaknesses

  • FTA is only as good as the top event’s definition — a vaguely stated failure (“something went wrong with the assay”) produces an unusably broad tree.
  • Trees for a complex, multi-step method can become large fast; without discipline about what counts as a “basic event,” the tree can sprawl without converging on an actionable root cause.
  • FTA doesn’t score or prioritize the way RPN does — it’s a diagnostic tool for one failure, not a ranking tool across many, which is why it’s typically paired with an FMEA or risk ranking rather than used as the whole risk program.