methodatlas
Session Builder

Plan my session

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

Method session60-180 min, depending on complexityWorkshop or asyncChange Matrix

Session: Change 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 2-6. 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 Change Matrix. After the session, the artifact should be shareable, reviewable, or reusable.

  1. 1

    Phase 1: Capture baseline and actual state

    20-30 min

    Describe the baseline state (when it last worked) and the current state concretely per category. Version IDs, configuration hashes, staffing, environmental conditions. Hint: If the baseline cannot be reconstructed concretely, Change Analysis will not work. Better spend time rebuilding the baseline than relying on surface-level guesses.

    FacilitatorChange Matrix
  2. 2

    Phase 2: List differences

    30-60 min

    List all differences between should and is per category. Capture even seemingly irrelevant changes (library update, new person on the team, changed supplier service). Hint: Common mistake: only capture the obvious changes. Differences such as 'new security patch in the OS' or 'changed NTP server' often appear only with a systematic list.

    FacilitatorCause Hypotheses
  3. 3

    Phase 3: Evaluate differences

    30-45 min

    For each difference: causally plausible, contributing, or random. Provide a reason for each rating. If several causes are plausible, set the order of verification. Hint: Avoid confirmation bias: the most obvious difference is not automatically the cause. For each difference, check when it would take effect and whether that fits the timeline.

    FacilitatorValidation Questions
  4. 4

    Phase 4: Test the hypothesis

    30-90 min

    Check the suspicious difference in isolation: rollback in staging, A/B comparison, targeted test. Document the result. Hint: Test instead of guessing. If testing is not possible, at least check plausibility using timeline and logs. A hypothesis without a test remains a candidate, not a result.

    FacilitatorAction List
  5. 5

    Phase 5: Measures and lessons

    30-45 min

    Define a corrective action for the causal difference. Structural lesson: why was this change possible without attention. Improve change management. Hint: Often the change turns out to be unplanned or not communicated. Structural means not 'more reviews', but better detection of relevant differences, for example a change calendar or diff notifications.

    OwnerChange Matrix
  6. 6

    Publish artifact

    10 min

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

    OwnerChange Matrix
Usable artifact

Session Brief

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

session-brief.md

Session Brief: Change Analysis

Goal

Artifact: Change Matrix

Working Question

Which differences between should and is explain the observed deviation, and which of those differences are causal, contributing, or random?

Context

What worked last time, what no longer works now; time window of the deviation; list of known changes since baseline (deploys, configs, people, external systems); logs and diffs.

Setup

  • Format: Method session
  • Duration: 60-180 min, depending on complexity
  • Mode: Workshop or async
  • Participants: One lead investigator; 2-5 people who know the change areas (engineering, ops, data, supplier); one scribe; in safety-critical systems, one independent reviewer.
  • Owner: One lead investigator
  • 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 Change Matrix. After the session, the artifact should be shareable, reviewable, or reusable.

Input

Whiteboard or table with three columns (should, is, difference); access to version control, config states, deploy logs, staff shift plans; template for the difference list.

Preparation

Create a table with should, is, and difference columns. Use categories as rows: code, configuration, data, infrastructure, people, supplier, environment, process. Instruction: make should and is as concrete as possible per row, and note difference with source and timestamp.

Agenda

  1. Phase 1: Capture baseline and actual state (20-30 min) Owner: Facilitator Action: Describe the baseline state (when it last worked) and the current state concretely per category. Version IDs, configuration hashes, staffing, environmental conditions. Hint: If the baseline cannot be reconstructed concretely, Change Analysis will not work. Better spend time rebuilding the baseline than relying on surface-level guesses. Output: Change Matrix

  2. Phase 2: List differences (30-60 min) Owner: Facilitator Action: List all differences between should and is per category. Capture even seemingly irrelevant changes (library update, new person on the team, changed supplier service). Hint: Common mistake: only capture the obvious changes. Differences such as 'new security patch in the OS' or 'changed NTP server' often appear only with a systematic list. Output: Cause Hypotheses

  3. Phase 3: Evaluate differences (30-45 min) Owner: Facilitator Action: For each difference: causally plausible, contributing, or random. Provide a reason for each rating. If several causes are plausible, set the order of verification. Hint: Avoid confirmation bias: the most obvious difference is not automatically the cause. For each difference, check when it would take effect and whether that fits the timeline. Output: Validation Questions

  4. Phase 4: Test the hypothesis (30-90 min) Owner: Facilitator Action: Check the suspicious difference in isolation: rollback in staging, A/B comparison, targeted test. Document the result. Hint: Test instead of guessing. If testing is not possible, at least check plausibility using timeline and logs. A hypothesis without a test remains a candidate, not a result. Output: Action List

  5. Phase 5: Measures and lessons (30-45 min) Owner: Owner Action: Define a corrective action for the causal difference. Structural lesson: why was this change possible without attention. Improve change management. Hint: Often the change turns out to be unplanned or not communicated. Structural means not 'more reviews', but better detection of relevant differences, for example a change calendar or diff notifications. Output: Change Matrix

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

Closeout

  • Update result artifact: Change Matrix
  • 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

Change Matrix: Change Analysis

Working Question

Which differences between should and is explain the observed deviation, and which of those differences are causal, contributing, or random?

Context

What worked last time, what no longer works now; time window of the deviation; list of known changes since baseline (deploys, configs, people, external systems); logs and diffs.

Participants

  • Owner: One lead investigator
  • Participants: One lead investigator; 2-5 people who know the change areas (engineering, ops, data, supplier); one scribe; in safety-critical systems, one independent reviewer.

Input

Whiteboard or table with three columns (should, is, difference); access to version control, config states, deploy logs, staff shift plans; template for the difference list.

Template

Change Analysis Working Matrix

ElementDescriptionRatingEvidenceOwnerNext step
1
2
3

Output artifacts

  • Change Matrix:
  • Cause Hypotheses:
  • Validation Questions:
  • Action List:

Decision or recommendation

What consequence follows from the matrix?

Completion Check

  • Change Matrix 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

Change Analysis Working Template

View templateCompact working template for Change Analysis with context, input, output artifacts, and next step.
spreadsheet

change-analysis-working-template.md

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

Change Analysis Working Matrix

ElementDescriptionRatingEvidenceOwnerNext step
1
2
3

Output artifacts

  • Change Matrix:
  • Cause Hypotheses:
  • Validation Questions:
  • Action List:

Decision or recommendation

What consequence follows from the matrix?

Ready to use when
  • Working question, owner, and target artifact are visible.
  • The result fits Change Matrix.
  • Date, incident ID, investigator, and reviewer in the header. Later findings as an update section at the end. For follow-up incidents with a similar pattern, link back to the previous Change Analysis.
  • Open questions are noted as follow-ups.
  • The next review or decision point is scheduled.
ProfileRunsheet