methodatlas
Session Builder

Meine Session planen

Plane einen konkreten Arbeitsblock mit Agenda, Rollen, Vorbereitung und kopierbarem Ergebnisartefakt.

Methoden-Session2-8 hWorkshop oder asyncProblem Analysis

Session: Kepner-Tregoe

Der Plan übersetzt die Methode in einen konkreten moderierten Arbeitsblock. Die Eingaben fließen direkt in Session Brief und Arbeitsartefakt.

Automatisch abgeleitet

Methoden-Session mit 2-8. Der Plan nutzt die vorhandene Methodenlogik und das Runsheet.

Runsheet
Beteiligungslogik
Teamrunde, gemeinsames Arbeiten und Alignment

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

Ergebnislogik
Artefakt fertigstellen

Die Session arbeitet direkt auf Problem Analysis hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

  1. 1

    Sektion 1: Situation Appraisal

    20-30 min

    Probleme, Entscheidungen und potenzielle Probleme listen. Pro Eintrag Dringlichkeit, Auswirkung und Wachstumsrate bewerten. Top-Themen für die folgenden KT-Prozesse priorisieren. Hinweis: Wenn die Liste über 10 Einträge umfasst, in zwei Sessions splitten. KT lebt von Fokus, nicht von Volumen.

    FacilitatorProblem Analysis
  2. 2

    Sektion 2: Problem Analysis (Ist/Ist-nicht)

    45-90 min

    Pro Problem Vier-Felder-Spezifikation: Was ist betroffen, was ist nicht betroffen, wo, wann, wie viel. Aus Unterschieden mögliche Ursachen ableiten und gegen jede Spezifikation testen. Hinweis: Die Spalte „Ist-nicht“ ist der diagnostische Hebel. Wenn sie leer bleibt, fehlt Datenkenntnis und die PA wird Spekulation.

    FacilitatorDecision Analysis
  3. 3

    Sektion 3: Decision Analysis

    30-60 min

    Entscheidungsaussage formulieren. Must-Kriterien (KO) und Want-Kriterien (gewichtet) auflisten. Optionen gegen Musts filtern, gegen Wants bewerten. Risiken pro Top-Option diskutieren. Hinweis: Mehr als sieben Wants verdünnen die Bewertung. Wichtigste drei bis fünf reichen. Gewichtung 1-10, nicht binär.

    FacilitatorRisk Plan
  4. 4

    Sektion 4: Potential Problem Analysis

    30-60 min

    Pro gewählter Option mögliche Probleme listen, Wahrscheinlichkeit und Auswirkung bewerten. Pro Top-Risiko Präventiv- und Kontingenzmaßnahmen festlegen, Trigger und Owner benennen. Hinweis: Trigger müssen messbar sein. „Wenn es Probleme gibt“ ist kein Trigger, „wenn Error Rate über 2% in 5 min“ ist einer.

    FacilitatorProblem Analysis
  5. 5

    Sektion 5: Followups

    15-20 min

    Pro Ergebnis Owner, Datum und Review-Termin. Offene Tests aus PA als Spike-Aufgaben anlegen. Entscheidung und Begründung im Decision Log archivieren. Hinweis: Spikes mit Datum, sonst geht die diagnostische Lücke verloren und KT war nur Theaterdokumentation.

    OwnerDecision Analysis
  6. 6

    Artefakt veröffentlichen

    10 min

    Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.

    OwnerProblem Analysis
Nutzbares Artefakt

Session Brief

Für Einladung, Board, Ticket, PR-Beschreibung oder Workshop-Notiz.

session-brief.md

Session Brief: Kepner-Tregoe

Ziel

Artefakt: Problem Analysis

Arbeitsfrage

Welche Ursache, Entscheidung oder Risikomaßnahme lässt sich durch disziplinierte Trennung von Fakten, Hypothesen und Entscheidungskriterien rational ableiten?

Kontext

Problemstellung, Zeitraum, beobachtete Symptome; bekannte Workarounds; verfügbare Daten und deren Quellen; Eskalationsstand und Stakeholder.

Setup

  • Format: Methoden-Session
  • Dauer: 2-8 h
  • Modus: Workshop oder async
  • Teilnehmende: Ein Facilitator mit KT-Erfahrung, der durch die vier Prozesse führt; zwei bis acht Teilnehmer mit Domain- und Datenkenntnis; ein Scribe, der Hypothesen und Tests protokolliert.
  • Owner: Ein Facilitator mit KT-Erfahrung, der durch die vier Prozesse führt
  • 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 Problem Analysis hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

Input

Vorlage mit vier KT-Prozessen (Situation Appraisal, Problem Analysis, Decision Analysis, Potential Problem Analysis); Tabellen für Ist/Ist-nicht-Vergleiche und Entscheidungskriterien; Zugriff auf Logs, Metriken, Dokumentation.

Vorbereitung

Vorlage geteilt verfügbar machen. Mit Situation Appraisal beginnen und entscheiden, welcher KT-Prozess primär angewandt wird (PA, DA, PPA). Telefone aus, parallele Threads pausieren.

Agenda

  1. Sektion 1: Situation Appraisal (20-30 min) Owner: Facilitator Aktion: Probleme, Entscheidungen und potenzielle Probleme listen. Pro Eintrag Dringlichkeit, Auswirkung und Wachstumsrate bewerten. Top-Themen für die folgenden KT-Prozesse priorisieren. Hinweis: Wenn die Liste über 10 Einträge umfasst, in zwei Sessions splitten. KT lebt von Fokus, nicht von Volumen. Output: Problem Analysis

  2. Sektion 2: Problem Analysis (Ist/Ist-nicht) (45-90 min) Owner: Facilitator Aktion: Pro Problem Vier-Felder-Spezifikation: Was ist betroffen, was ist nicht betroffen, wo, wann, wie viel. Aus Unterschieden mögliche Ursachen ableiten und gegen jede Spezifikation testen. Hinweis: Die Spalte „Ist-nicht“ ist der diagnostische Hebel. Wenn sie leer bleibt, fehlt Datenkenntnis und die PA wird Spekulation. Output: Decision Analysis

  3. Sektion 3: Decision Analysis (30-60 min) Owner: Facilitator Aktion: Entscheidungsaussage formulieren. Must-Kriterien (KO) und Want-Kriterien (gewichtet) auflisten. Optionen gegen Musts filtern, gegen Wants bewerten. Risiken pro Top-Option diskutieren. Hinweis: Mehr als sieben Wants verdünnen die Bewertung. Wichtigste drei bis fünf reichen. Gewichtung 1-10, nicht binär. Output: Risk Plan

  4. Sektion 4: Potential Problem Analysis (30-60 min) Owner: Facilitator Aktion: Pro gewählter Option mögliche Probleme listen, Wahrscheinlichkeit und Auswirkung bewerten. Pro Top-Risiko Präventiv- und Kontingenzmaßnahmen festlegen, Trigger und Owner benennen. Hinweis: Trigger müssen messbar sein. „Wenn es Probleme gibt“ ist kein Trigger, „wenn Error Rate über 2% in 5 min“ ist einer. Output: Problem Analysis

  5. Sektion 5: Followups (15-20 min) Owner: Owner Aktion: Pro Ergebnis Owner, Datum und Review-Termin. Offene Tests aus PA als Spike-Aufgaben anlegen. Entscheidung und Begründung im Decision Log archivieren. Hinweis: Spikes mit Datum, sonst geht die diagnostische Lücke verloren und KT war nur Theaterdokumentation. Output: Decision Analysis

  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: Problem Analysis

Abschluss

  • Ergebnisartefakt aktualisieren: Problem Analysis
  • Ablageort, Version und Review-Empfänger festlegen.
  • Owner, nächster Schritt und Reviewtermin festlegen.
Nutzbares Artefakt

Arbeitsartefakt

Vorgefüllter Startpunkt auf Basis der passenden Vorlage.

arbeitsartefakt.md

Problem Analysis: Kepner-Tregoe

Arbeitsfrage

Welche Ursache, Entscheidung oder Risikomaßnahme lässt sich durch disziplinierte Trennung von Fakten, Hypothesen und Entscheidungskriterien rational ableiten?

Kontext

Problemstellung, Zeitraum, beobachtete Symptome; bekannte Workarounds; verfügbare Daten und deren Quellen; Eskalationsstand und Stakeholder.

Beteiligte

  • Owner: Ein Facilitator mit KT-Erfahrung, der durch die vier Prozesse führt
  • Teilnehmende: Ein Facilitator mit KT-Erfahrung, der durch die vier Prozesse führt; zwei bis acht Teilnehmer mit Domain- und Datenkenntnis; ein Scribe, der Hypothesen und Tests protokolliert.

Input

Vorlage mit vier KT-Prozessen (Situation Appraisal, Problem Analysis, Decision Analysis, Potential Problem Analysis); Tabellen für Ist/Ist-nicht-Vergleiche und Entscheidungskriterien; Zugriff auf Logs, Metriken, Dokumentation.

Vorlage

Kepner-Tregoe Arbeitsvorlage

Ziel

Strukturiert Situation, Problem, Entscheidung und Risikoanalyse in getrennte Denkprozesse.

Kontext

Wann und wofür nutzen wir diese Methode?

Input

Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?

Durchführung

Kurze Notizen entlang des Runsheets.

Ergebnisartefakte

  • Problem Analysis:
  • Decision Analysis:
  • Risk Plan:

Annahmen und offene Fragen

  • ...

Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

Fertigstellungscheck

  • Problem Analysis 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
Vorlagenbasis

Kepner-Tregoe Arbeitsvorlage

Vorlage ansehenKompakte Arbeitsvorlage für Kepner-Tregoe mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
markdown

kepner-tregoe-working-template.md

Kompakte Arbeitsvorlage für Kepner-Tregoe mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.

Kepner-Tregoe Arbeitsvorlage

Ziel

Strukturiert Situation, Problem, Entscheidung und Risikoanalyse in getrennte Denkprozesse.

Kontext

Wann und wofür nutzen wir diese Methode?

Input

Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?

Durchführung

Kurze Notizen entlang des Runsheets.

Ergebnisartefakte

  • Problem Analysis:
  • Decision Analysis:
  • Risk Plan:

Annahmen und offene Fragen

  • ...

Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

Direkt nutzbar, wenn
  • Arbeitsfrage, Owner und Zielartefakt sind sichtbar.
  • Das Ergebnis passt zu Problem Analysis.
  • Pro Vorfall oder Entscheidung eigener Eintrag mit Datum und Decider im Header. Spätere Erkenntnisse als Update-Sektion am Ende, nicht überschreiben. Bei revidierter Entscheidung Status auf `revised` setzen.
  • Offene Fragen sind als Follow-up notiert.
  • Der nächste Review oder Entscheidungspunkt ist terminiert.
SteckbriefRunsheet