methodatlas
Session Builder

Plan my session

Plan a concrete work block with agenda, roles, preparation, and a copyable result artifact.

Method sessionInitial 4-8 h, then iterative refinements per sub-treeWorkshop or asyncFault Tree

Session: Fault Tree Analysis

The plan translates the method into a concrete facilitated work block. Your inputs flow directly into the session brief and work artifact.

Derived automatically

Method session with 3-8. The plan uses the existing method logic and the runsheet.

Runsheet
Participation logic
Team round, shared work and alignment

Use the session for shared understanding. Contributions are collected visibly, assumptions are aligned, and open differences remain traceable in the artifact.

Outcome logic
Finish artifact

The session works directly toward Fault Tree. After the session, the artifact should be shareable, reviewable, or reusable.

  1. 1

    Phase 1: Top event and system boundary

    30-45 min

    Formulate top event precisely: state, threshold, time window, affected system. Define system boundary: what is in the tree and what stays black-box. Hint: If top event is not unambiguous (for example, "system down" without definition), the tree is arbitrary. Define it with testable acceptance criteria.

    FacilitatorFault Tree
  2. 2

    Phase 2: First branch layer

    45-60 min

    Identify immediate preconditions that must hold for top event to occur. Differentiate AND (all together) and OR (one is enough). Place this layer as sub-events under the top event. Hint: Common mistake: refining too quickly. First layer must be complete; otherwise structural logic is wrong. Test: would this layer alone explain the top event if fully verified?

    FacilitatorCritical Paths
  3. 3

    Phase 3: Iterative refinement

    2-4 h

    Further decompose each sub-event until base events are reached (component failure, operator error, external cause). Document assumptions and data sources per layer. Hint: Stop when additional refinement adds no value or no data is available. Trees can be infinitely deep in theory; practical stop at 4-6 levels or at measurable base events.

    FacilitatorCause Hypotheses
  4. 4

    Phase 4: Minimal cut sets

    45-90 min

    Identify minimal cut sets: smallest combinations of basic events whose simultaneous occurrence triggers the top event. Do manually or with tools. Hint: Cut sets of size 1 are single points of failure and often critical. Cut sets with high joint probability are also critical. Prioritize by impact times likelihood.

    FacilitatorControl Actions
  5. 5

    Phase 5: Actions and review

    45-90 min

    Derive measures for each critical cut set: redundancy, detection, recovery, prevention. Assign owner and date. For critical systems, an independent review is mandatory. Hint: Actions without independent review are prone to blind spots. In regulated systems, review is required, not optional.

    OwnerFault Tree
  6. 6

    Publish artifact

    10 min

    Check the artifact for completeness, define location, set version or status, and name review recipients.

    OwnerFault Tree
Usable artifact

Session Brief

For invitations, boards, tickets, PR descriptions, or workshop notes.

session-brief.md

Session Brief: Fault Tree Analysis

Goal

Artifact: Fault Tree

Working Question

Which logical combinations of basic events lead to the undesired top event, and which minimal cut sets are critical enough to trigger action?

Context

Top event as a precise undesired state (e.g., "Wrong dose administered to patient"); system diagram; available failure rates or estimates per component; standards or regulations if relevant.

Setup

  • Format: Method session
  • Duration: Initial 4-8 h, then iterative refinements per sub-tree
  • Mode: Workshop or async
  • Participants: An FTA coach with experience in reliability or safety analysis; 3-6 experts from affected domains (software, hardware, network, data, operations); a scribe for assumptions and sources; independent reviewer for critical systems.
  • Owner: An FTA coach with experience in reliability or safety analysis
  • Participation mode: Team round, shared work and alignment
  • Outcome logic: Finish artifact

Participation Logic

Use the session for shared understanding. Contributions are collected visibly, assumptions are aligned, and open differences remain traceable in the artifact.

Outcome Logic

The session works directly toward Fault Tree. After the session, the artifact should be shareable, reviewable, or reusable.

Input

Large whiteboard or digital diagram tool (e.g., draw.io, Lucidchart, OmniGraffle); FTA symbols (AND gate, OR gate, basic event, top event); system documentation; template for probabilities and sub-events.

Preparation

Place top event clearly at top of board as rectangle. Make FTA notation visible. Keep an "assumptions" section separately and number each assumption. Rule: AND gates connect events that must occur together; OR gates connect alternative causes.

Agenda

  1. Phase 1: Top event and system boundary (30-45 min) Owner: Facilitator Action: Formulate top event precisely: state, threshold, time window, affected system. Define system boundary: what is in the tree and what stays black-box. Hint: If top event is not unambiguous (for example, "system down" without definition), the tree is arbitrary. Define it with testable acceptance criteria. Output: Fault Tree

  2. Phase 2: First branch layer (45-60 min) Owner: Facilitator Action: Identify immediate preconditions that must hold for top event to occur. Differentiate AND (all together) and OR (one is enough). Place this layer as sub-events under the top event. Hint: Common mistake: refining too quickly. First layer must be complete; otherwise structural logic is wrong. Test: would this layer alone explain the top event if fully verified? Output: Critical Paths

  3. Phase 3: Iterative refinement (2-4 h) Owner: Facilitator Action: Further decompose each sub-event until base events are reached (component failure, operator error, external cause). Document assumptions and data sources per layer. Hint: Stop when additional refinement adds no value or no data is available. Trees can be infinitely deep in theory; practical stop at 4-6 levels or at measurable base events. Output: Cause Hypotheses

  4. Phase 4: Minimal cut sets (45-90 min) Owner: Facilitator Action: Identify minimal cut sets: smallest combinations of basic events whose simultaneous occurrence triggers the top event. Do manually or with tools. Hint: Cut sets of size 1 are single points of failure and often critical. Cut sets with high joint probability are also critical. Prioritize by impact times likelihood. Output: Control Actions

  5. Phase 5: Actions and review (45-90 min) Owner: Owner Action: Derive measures for each critical cut set: redundancy, detection, recovery, prevention. Assign owner and date. For critical systems, an independent review is mandatory. Hint: Actions without independent review are prone to blind spots. In regulated systems, review is required, not optional. Output: Fault Tree

  6. Publish artifact (10 min) Owner: Owner Action: Check the artifact for completeness, define location, set version or status, and name review recipients. Output: Fault Tree

Closeout

  • Update result artifact: Fault Tree
  • Define location, version, and review recipients.
  • Define owner, next step, and review date.
Usable artifact

Work artifact

Pre-filled starting point based on the matching template.

work-artifact.md

Fault Tree: Fault Tree Analysis

Working Question

Which logical combinations of basic events lead to the undesired top event, and which minimal cut sets are critical enough to trigger action?

Context

Top event as a precise undesired state (e.g., "Wrong dose administered to patient"); system diagram; available failure rates or estimates per component; standards or regulations if relevant.

Participants

  • Owner: An FTA coach with experience in reliability or safety analysis
  • Participants: An FTA coach with experience in reliability or safety analysis; 3-6 experts from affected domains (software, hardware, network, data, operations); a scribe for assumptions and sources; independent reviewer for critical systems.

Input

Large whiteboard or digital diagram tool (e.g., draw.io, Lucidchart, OmniGraffle); FTA symbols (AND gate, OR gate, basic event, top event); system documentation; template for probabilities and sub-events.

Template

Fault Tree Analysis Canvas

Context

What is this method used for?

Core question

Which question should be answered at the end?

Input

Which data, observations, or materials are available?

Working area

  • Area 1:
  • Area 2:
  • Area 3:
  • Relationships / patterns:

Output artifacts

  • Fault Tree:
  • Critical Paths:
  • Cause Hypotheses:
  • Control Measures:

Open questions

  • ...

Next step

Owner, date, and success signal.

Completion Check

  • Fault Tree is complete enough for review:
  • Location:
  • Version / status:
  • Review by:
  • Next step:

Next Step

  • Review result
  • Mark open questions
  • Schedule review or decision
Template base

Fault Tree Analysis Working Template

View templateCompact working template for Fault Tree Analysis with context, input, output artifacts, and next step.
canvas

fault-tree-analysis-working-template.md

Compact working template for Fault Tree Analysis with context, input, output artifacts, and next step.

Fault Tree Analysis Canvas

Context

What is this method used for?

Core question

Which question should be answered at the end?

Input

Which data, observations, or materials are available?

Working area

  • Area 1:
  • Area 2:
  • Area 3:
  • Relationships / patterns:

Output artifacts

  • Fault Tree:
  • Critical Paths:
  • Cause Hypotheses:
  • Control Measures:

Open questions

  • ...

Next step

Owner, date, and success signal.

Ready to use when
  • Working question, owner, and target artifact are visible.
  • The result fits Fault Tree.
  • One FTA per system and top event. Record version with date, author, and reviewer. For system changes, create a new FTA version with diff and keep predecessor.
  • Open questions are noted as follow-ups.
  • The next review or decision point is scheduled.
ProfileRunsheet