Fault Tree Analysis — Working Backward From a Failure
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.