In critical processes, it is not enough to plan only for the normal case. Failure Scenario Analysis looks at the path into failure and shows which failures, chains, and control gaps cause the most damage.
Engineering Analysis method
Failure Scenario Analysis
Failure scenario analysis anticipates failures, assesses controls, and shows gaps in testing, prevention, and response.
Failure scenario analysis models plausible disruptions as paths through a system and examines triggers, effects, and existing barriers. It highlights where layered protection or resilience work is needed.
Which credible failure paths threaten a critical service, how will we detect and limit them, and which residual uncertainty needs rehearsal?
- Participants
- 3-8
- Time
- 90–180 minutes per system area; add technical validation and drills.
The steps form one complete method run.

Service
Protected outcome
Define critical service, success criterion, and unacceptable impacts.
Scenarios
Scenario space
Collect credible triggers from architecture, history, and environment; include compound cases.
Paths
Failure paths
Model trigger through intermediate states to impact; mark assumptions and escalation points.
Protection
Protection matrix
Check detection, prevention, mitigation, and recovery per path; mark single points and blind spots.
Exercise
Drill plan
Run prioritised scenarios as tabletop, GameDay, or technical test with stop rules.
Add new evidence at review and version decisions with the prior state.
A good fit when
In kritischen Prozessen reicht es nicht, nur den Normalfall zu planen. Failure Scenario Analysis betrachtet den Weg ins Scheitern und zeigt, welche Ausfälle, Ketten und Kontrolllücken am meisten Schaden erzeugen.
Ideal for
- Resilience planning
- Architecture and operational risks
- Release readiness
Not good for
- Already occurred incidents without reconstruction
- Pure creative ideas
- Trivial single tasks
Outputs

Drill plan
Failure-scenario register with trigger, path, impact, detection, protection, recovery, residual risk, and drill.
Failure Scenario Analysis · working structure
Fictional example
Fictional values show the actual method fields.
| Scenario | Trigger | Failure path | Impact | Detection | Protection | Recovery | Exercise |
|---|---|---|---|---|---|---|---|
| Pool exhaustionAdd evidence and rationale. | Batch start | Batch → 72 connections → pool 95% → timeout | Reserved pickup >15 minutes | Pool alert missing | Pool separation and circuit breaker | Pause batch; drain pool | GameDay with 5% stop rule |
| Warehouse network downAdd evidence and rationale. | Switch failure | Scanner offline → inventory unknown → handoff stops | No confirmed handoff | Heartbeat after 2 minutes | Offline list, four-eyes check | Paper process; reconcile later | Network-loss tabletop |
1. Trigger
- Pool exhaustion
- Batch start
- Warehouse network down
- Switch failure
2. Failure path
- Pool exhaustion
- Batch → 72 connections → pool 95% → timeout
- Warehouse network down
- Scanner offline → inventory unknown → handoff stops
3. Impact
- Pool exhaustion
- Reserved pickup >15 minutes
- Warehouse network down
- No confirmed handoff
4. Detection
- Pool exhaustion
- Pool alert missing
- Warehouse network down
- Heartbeat after 2 minutes
5. Protection
- Pool exhaustion
- Pool separation and circuit breaker
- Warehouse network down
- Offline list, four-eyes check
6. Recovery
- Pool exhaustion
- Pause batch; drain pool
- Warehouse network down
- Paper process; reconcile later
7. Exercise
- Pool exhaustion
- GameDay with 5% stop rule
- Warehouse network down
- Network-loss tabletop
All values are fictional.
First step
Set critical service, operating state, guardrails, and horizon; prepare incidents and architecture.
Deep dive
Possible disruptions are thought through as realistic paths through the system and examined for triggers, consequences, and existing barriers. This brings out points where several layers of protection are needed or where a single fault can grow large. The procedure is strong for safety, operations, and resilience questions.
Failure Scenario Analysis starts by asking which realistic failure situations a system or process could face. For each scenario, the team looks at triggers, affected components, escalation paths, impacts, and existing controls. That turns failure from an abstract idea into a testable story. The scenarios then become tests, prevention measures, and response plans.
Use real incidents, architecture knowledge, and operational data as a starting point. Keep scenarios concrete enough for teams to derive actions. Do not focus only on spectacular outages; also look at frequent small disruptions with high total impact.
The method guide walks execution through 5 phases, timing, 5 pitfalls, and clear stop criteria.
Open method guideYour perspective
Does this method help with your work?
Your feedback helps shape the next improvements to methodatlas.
Sources and topics
Failure Scenario Analysis: WorksheetSet subject, evidence, roles, flow, and review.markdown
failure-scenario-analysis-working-template.md
Set subject, evidence, roles, flow, and review.
Failure Scenario Analysis: Worksheet
Question
To be confirmed
Desired outcome
To be confirmed
Scope
Complete run Time: 90–180 minutes per system area; add technical validation and drills.
Complete this worksheet on paper or in your own document during the work.
Preparation for this scope
Method setup
- Materials: System boundary, critical services, architecture/dependencies, scenario cards, signals, protections, and drill plan
- Roles: Service owner · reliability/safety · architecture · operations · affected domain perspectives · action owners
- Advance information: Set critical service, operating state, guardrails, and horizon; prepare incidents and architecture.
- Overall time needed: 90–180 minutes per system area; add technical validation and drills.
- Setup: Prepare a workspace with Service · Scenarios · Paths · Protection · Exercise; separate example from live data.
Prepare for the work steps
Service: Protected outcome
- Set critical service, operating state, guardrails, and horizon; prepare incidents and architecture.
- System boundary, critical services, architecture/dependencies, scenario cards, signals, protections, and drill plan
Scenarios: Scenario space
- Protected outcome
Paths: Failure paths
- Scenario space
Protection: Protection matrix
- Failure paths
Exercise: Drill plan
- Protection matrix
Failure Scenario Analysis · working structure
| Scenario | Trigger | Failure path | Impact | Detection | Protection | Recovery | Exercise |
|---|---|---|---|---|---|---|---|
| Pool exhaustion | |||||||
| Warehouse network down |
- Pool exhaustion: Add evidence and rationale.
- Warehouse network down: Add evidence and rationale.
The blank worksheet contains prompts only.
Reference · original teaching example
Service: Protected outcome
Expected artifact: Protected outcome
Define critical service, success criterion, and unacceptable impacts.
Entry:
...
- Is it clear what must be preserved under which conditions?
Scenarios: Scenario space
Expected artifact: Scenario space
Collect credible triggers from architecture, history, and environment; include compound cases.
Entry:
...
- Are scenarios concrete, plausible, and distinguishable?
Paths: Failure paths
Expected artifact: Failure paths
Model trigger through intermediate states to impact; mark assumptions and escalation points.
Entry:
...
- Is each connection mechanistic and time-aware?
Protection: Protection matrix
Expected artifact: Protection matrix
Check detection, prevention, mitigation, and recovery per path; mark single points and blind spots.
Entry:
...
- Does each control have signal, owner, and known limit?
Exercise: Drill plan
Expected artifact: Drill plan
Run prioritised scenarios as tabletop, GameDay, or technical test with stop rules.
Entry:
...
- Does drill test detection, decision, recovery, and communication?
Open questions and next steps
...
Method guide: https://methodatlas.meierhoff-systems.de/en/methods/failure-scenario-analysis/run-sheet
Alternatives and neighbors
Fitting alternatives with decision guidance, followed by other related methods.

Instead of Failure Scenario Analysis, choose Fault Tree Analysis when you want to break down a failure top-down through logical links and failure paths.

Instead of Failure Scenario Analysis, choose Red Teaming when you want to deliberately examine a solution for weaknesses from an adversarial perspective.

Sorts assumptions by uncertainty and leverage so the riskiest hypotheses get tested first.

Narrows down the fault space and symptoms step by step until only a few hypotheses and targeted tests remain.

Moves technical problems, hypotheses, and next steps toward a concrete result through "formulate the goal clearly", "derive probing questions for each goal", and "set the review cadence".

Describes the preferred default path for common use cases and adds templates, checks, and exceptions.
Constraints and origin
Profile
- Method form
- Analysis method
- Participants
- 3-8
- Time
- 1-3 h
- Maturity
- Established
- Origin
- Reliability Engineering Community

