Meine Session planen

# Session Brief: Change Analysis

## Ziel
Artefakt: Change Matrix

## Arbeitsfrage
Welche Unterschiede zwischen Soll- und Ist-Zustand erklären die beobachtete Abweichung, und welche dieser Differenzen sind ursächlich, beitragend oder zufällig?

## Kontext
Was funktionierte zuletzt, was funktioniert jetzt nicht; Zeitraum der Abweichung; Liste der bekannten Veränderungen seit Baseline (Deploys, Configs, Personal, Daten, externe Systeme); Logs und Diffs.

## Setup
- Format: Methoden-Session
- Dauer: 60-180 min, je nach Komplexität
- Modus: Workshop oder async
- Teilnehmende: Ein Lead-Investigator; 2-5 Personen mit Kenntnis der Veränderungsbereiche (Engineering, Ops, Daten, Lieferant); ein Scribe; bei sicherheitskritischen Systemen ein unabhängiger Reviewer.
- Owner: Ein Lead-Investigator
- Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
- Ergebnislogik: Artefakt fertigstellen

## Beteiligungslogik
Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

## Ergebnislogik
Die Session arbeitet direkt auf Change Matrix hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

## Input
Whiteboard oder Tabelle mit drei Spalten (Soll, Ist, Differenz); Zugang zu Versionssystemen, Konfigurationsständen, Deploy-Logs, Mitarbeiter-Schichtplänen; Vorlage für Differenz-Liste.

## Vorbereitung
Tabelle mit Soll-, Ist- und Differenz-Spalten anlegen. Kategorien als Zeilen: Code, Konfiguration, Daten, Infrastruktur, Personal, Lieferant, Umfeld, Prozess. Anweisung: pro Zeile Soll und Ist möglichst konkret, Differenz mit Quelle und Zeitstempel.

## Agenda
1. Phase 1: Baseline und Ist-Zustand erfassen (20-30 min)
   Owner: Facilitator
   Aktion: Baseline-Zustand (wann funktionierte es zuletzt) und Ist-Zustand pro Kategorie konkret beschreiben. Versions-IDs, Konfigurations-Hashes, Personalbesetzungen, Umfeldbedingungen. Hinweis: Wenn Baseline nicht konkret rekonstruierbar ist, Change Analysis funktioniert nicht. Lieber Wochenarbeit für saubere Baseline als oberflächliche Vermutungen. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Change Matrix

2. Phase 2: Differenzen auflisten (30-60 min)
   Owner: Facilitator
   Aktion: Pro Kategorie alle Differenzen zwischen Soll und Ist notieren. Auch scheinbar irrelevante Änderungen erfassen (Library-Update, neue Person im Team, geänderter Lieferanten-Service). Hinweis: Häufiger Fehler: nur die offensichtlichen Änderungen erfassen. Differenzen wie „neuer Sicherheitspatch in OS“ oder „NTP-Server gewechselt“ tauchen oft erst bei systematischer Liste auf. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Ursachenhypothesen

3. Phase 3: Differenzen bewerten (30-45 min)
   Owner: Facilitator
   Aktion: Pro Differenz: ursächlich plausibel, beitragend, zufällig. Begründung pro Bewertung. Bei mehreren plausiblen Ursachen Reihenfolge der Prüfung festlegen. Hinweis: Confirmation Bias vermeiden: die offensichtlichste Differenz ist nicht automatisch die Ursache. Pro Differenz prüfen: wann wirkt diese Veränderung, passt das zur Timeline. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Validierungsfragen

4. Phase 4: Hypothese testen (30-90 min)
   Owner: Facilitator
   Aktion: Verdächtige Differenz isoliert prüfen: Rollback in Staging, A/B-Vergleich, gezielter Test. Ergebnis dokumentieren. Hinweis: Testen statt vermuten. Wenn Test nicht möglich, mindestens Plausibilität anhand Timeline und Logs prüfen. Hypothese ohne Test bleibt Kandidat, kein Ergebnis. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Maßnahmenliste

5. Phase 5: Maßnahmen und Lessons (30-45 min)
   Owner: Owner
   Aktion: Korrekturmaßnahme für ursächliche Differenz. Strukturelle Lessons: warum war diese Veränderung möglich ohne Aufmerksamkeit. Change-Management-Verbesserungen. Hinweis: Häufig zeigt sich: Veränderung war ungeplant oder nicht kommuniziert. Strukturell heisst nicht „mehr Reviews“, sondern bessere Erkennung relevanter Differenzen, z. B. Change Calendar oder Diff Notifications. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   Output: Change Matrix

6. Artefakt veröffentlichen (10 min)
   Owner: Owner
   Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.
   Output: Change Matrix

## Abschluss
- Ergebnisartefakt aktualisieren: Change Matrix
- Ablageort, Version und Review-Empfänger festlegen.
- Owner, nächster Schritt und Reviewtermin festlegen.

# Change Matrix: Change Analysis

## Arbeitsfrage
Welche Unterschiede zwischen Soll- und Ist-Zustand erklären die beobachtete Abweichung, und welche dieser Differenzen sind ursächlich, beitragend oder zufällig?

## Kontext
Was funktionierte zuletzt, was funktioniert jetzt nicht; Zeitraum der Abweichung; Liste der bekannten Veränderungen seit Baseline (Deploys, Configs, Personal, Daten, externe Systeme); Logs und Diffs.

## Beteiligte
- Owner: Ein Lead-Investigator
- Teilnehmende: Ein Lead-Investigator; 2-5 Personen mit Kenntnis der Veränderungsbereiche (Engineering, Ops, Daten, Lieferant); ein Scribe; bei sicherheitskritischen Systemen ein unabhängiger Reviewer.

## Input
Whiteboard oder Tabelle mit drei Spalten (Soll, Ist, Differenz); Zugang zu Versionssystemen, Konfigurationsständen, Deploy-Logs, Mitarbeiter-Schichtplänen; Vorlage für Differenz-Liste.

## Vorlage
# Change Analysis Arbeitsmatrix

| Element | Beschreibung | Bewertung | Evidenz | Owner | Nächster Schritt |
|---|---|---|---|---|---|
| 1 | | | | | |
| 2 | | | | | |
| 3 | | | | | |

## Ergebnisartefakte
- Change Matrix:
- Ursachenhypothesen:
- Validierungsfragen:
- Maßnahmenliste:

## Entscheidung oder Empfehlung

Welche Konsequenz ergibt sich aus der Matrix?

## Fertigstellungscheck
- Change Matrix ist vollständig genug für Review:
- Ablageort:
- Version / Status:
- Review durch:
- Nächster Schritt:

## Nächster Schritt
- Ergebnis prüfen
- offene Fragen markieren
- Review oder Entscheidung terminieren