methodatlas
Session Builder

Plan my session

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

Method session2-4 h for initial RCA, then follow-up sessions depending on complexityWorkshop or asyncProblem Statement

Session: Root Cause 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 Problem Statement. After the session, the artifact should be shareable, reviewable, or reusable.

  1. 1

    Phase 1: Specify problem

    20-30 min

    Describe symptom concretely: what, when, where, how often, which effect. Quantify impact (users, revenue, data integrity). Delimit against similar problems. Hint: If problem statement already contains causes ("because X did not work"), that belongs in hypothesis phase. Clean symptom is basis for unbiased search.

    FacilitatorProblem Statement
  2. 2

    Phase 2: Hypothesis fan

    30-45 min

    Brainstorm possible causes across relevant categories (for example code, configuration, infrastructure, data, process, human). Fishbone or mind map as structure. Separate assumptions and evidenced causes. Hint: If only two or three hypotheses appear, search is too narrow. Force at least one hypothesis per category, even if unlikely. Avoid confirmation bias.

    FacilitatorCause Hypotheses
  3. 3

    Phase 3: Test hypotheses

    45-90 min

    Find data per hypothesis: logs, metrics, config diffs, witnesses. Verify or falsify. Remaining plausible hypotheses are candidates for Root Cause. Hint: If no data source can be named per hypothesis, it is speculative. Hypothesis test is core of method. "Sounds plausible" is no verification.

    FacilitatorConfirmed Causes
  4. 4

    Phase 4: Set Root Cause(s)

    30-45 min

    Identify Root Cause(s) from verified hypotheses. Often multiple causes plus triggering factor. For every cause check: controllable, systemic or individual case. Hint: A single Root Cause is suspicious. Complex systems usually have multiple interacting causes. Common endpoints "human error" are not Root Cause, but indicator of missing safety net.

    FacilitatorAction Plan
  5. 5

    Phase 5: Countermeasures and Lessons Learned

    30-45 min

    Countermeasure per Root Cause with owner and date. Separate symptom fix (hotfix), recurrence prevention (structural), detection (monitoring). Document Lessons Learned. Hint: If all countermeasures are monitoring or training, structural change is missing. Per Root Cause at least one action that prevents recurrence, not only improves visibility.

    OwnerProblem Statement
  6. 6

    Publish artifact

    10 min

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

    OwnerProblem Statement
Usable artifact

Session Brief

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

session-brief.md

Session Brief: Root Cause Analysis

Goal

Artifact: Problem Statement

Working Question

Which systemic causes caused or enabled the problem, and which countermeasures prevent recurrence instead of only treating symptoms?

Context

Incident timeline; relevant logs and metrics; available postmortems of similar incidents; symptom description as 1-2 sentence statement; affected customers or systems.

Setup

  • Format: Method session
  • Duration: 2-4 h for initial RCA, then follow-up sessions depending on complexity
  • Mode: Workshop or async
  • Participants: One facilitator with postmortem experience; 4-8 people with direct system contact from development, ops, support; one scribe; for larger incidents additionally one neutral investigator.
  • Owner: One facilitator with postmortem experience
  • 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 Problem Statement. After the session, the artifact should be shareable, reviewable, or reusable.

Input

Whiteboard or digital board with RCA template (Problem, Symptoms, Hypotheses, Data, Causes, Actions); logs, metrics, configuration states; postmortem template; method tools such as 5 Whys, Fishbone, Fault Tree for selection.

Preparation

Symptom at top of board as one sentence. List available methods (5 Whys for linear causality, Fishbone for broad hypothesis branching, Fault Tree for safety-critical systems). Postmortem template with sections Problem, Impact, Timeline, Root Cause, Countermeasures, Lessons Learned.

Agenda

  1. Phase 1: Specify problem (20-30 min) Owner: Facilitator Action: Describe symptom concretely: what, when, where, how often, which effect. Quantify impact (users, revenue, data integrity). Delimit against similar problems. Hint: If problem statement already contains causes ("because X did not work"), that belongs in hypothesis phase. Clean symptom is basis for unbiased search. Output: Problem Statement

  2. Phase 2: Hypothesis fan (30-45 min) Owner: Facilitator Action: Brainstorm possible causes across relevant categories (for example code, configuration, infrastructure, data, process, human). Fishbone or mind map as structure. Separate assumptions and evidenced causes. Hint: If only two or three hypotheses appear, search is too narrow. Force at least one hypothesis per category, even if unlikely. Avoid confirmation bias. Output: Cause Hypotheses

  3. Phase 3: Test hypotheses (45-90 min) Owner: Facilitator Action: Find data per hypothesis: logs, metrics, config diffs, witnesses. Verify or falsify. Remaining plausible hypotheses are candidates for Root Cause. Hint: If no data source can be named per hypothesis, it is speculative. Hypothesis test is core of method. "Sounds plausible" is no verification. Output: Confirmed Causes

  4. Phase 4: Set Root Cause(s) (30-45 min) Owner: Facilitator Action: Identify Root Cause(s) from verified hypotheses. Often multiple causes plus triggering factor. For every cause check: controllable, systemic or individual case. Hint: A single Root Cause is suspicious. Complex systems usually have multiple interacting causes. Common endpoints "human error" are not Root Cause, but indicator of missing safety net. Output: Action Plan

  5. Phase 5: Countermeasures and Lessons Learned (30-45 min) Owner: Owner Action: Countermeasure per Root Cause with owner and date. Separate symptom fix (hotfix), recurrence prevention (structural), detection (monitoring). Document Lessons Learned. Hint: If all countermeasures are monitoring or training, structural change is missing. Per Root Cause at least one action that prevents recurrence, not only improves visibility. Output: Problem Statement

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

Closeout

  • Update result artifact: Problem Statement
  • 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

Problem Statement: Root Cause Analysis

Working Question

Which systemic causes caused or enabled the problem, and which countermeasures prevent recurrence instead of only treating symptoms?

Context

Incident timeline; relevant logs and metrics; available postmortems of similar incidents; symptom description as 1-2 sentence statement; affected customers or systems.

Participants

  • Owner: One facilitator with postmortem experience
  • Participants: One facilitator with postmortem experience; 4-8 people with direct system contact from development, ops, support; one scribe; for larger incidents additionally one neutral investigator.

Input

Whiteboard or digital board with RCA template (Problem, Symptoms, Hypotheses, Data, Causes, Actions); logs, metrics, configuration states; postmortem template; method tools such as 5 Whys, Fishbone, Fault Tree for selection.

Template

Root Cause Analysis Working Template

Goal

Structured analysis to find the effective causes of a problem behind its symptoms.

Context

When and for what do we use this method?

Input

Which data, observations, decisions, or materials are available?

Execution

Short notes along the runsheet.

Output artifacts

  • Problem Statement:
  • Cause Hypotheses:
  • Confirmed Causes:
  • Action Plan:

Assumptions and open questions

  • ...

Decision / Next step

Owner, date, and success signal.

Completion Check

  • Problem Statement 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

Root Cause Analysis Working Template

View templateCompact working template for Root Cause Analysis with context, input, output artifacts, and next step.
markdown

root-cause-analysis-working-template.md

Compact working template for Root Cause Analysis with context, input, output artifacts, and next step.

Root Cause Analysis Working Template

Goal

Structured analysis to find the effective causes of a problem behind its symptoms.

Context

When and for what do we use this method?

Input

Which data, observations, decisions, or materials are available?

Execution

Short notes along the runsheet.

Output artifacts

  • Problem Statement:
  • Cause Hypotheses:
  • Confirmed Causes:
  • Action Plan:

Assumptions and open questions

  • ...

Decision / Next step

Owner, date, and success signal.

Ready to use when
  • Working question, owner, and target artifact are visible.
  • The result fits Problem Statement.
  • Date, incident ID, author and decider in header. Append later findings as update section at end, do not overwrite. If Root Cause later proves false, status to `revised`, keep original analysis.
  • Open questions are noted as follow-ups.
  • The next review or decision point is scheduled.
ProfileRunsheet