Was vorher fertig sein muss
Eine Liste identifizierter Risiken liegt vor (aus Risk Storming, PI-Planning, Risk Matrix oder vergleichbarer Aktivität).
Was vor Start vorliegen muss
Board mit 4 Spalten (Resolved, Owned, Accepted, Mitigated); Risikoliste als Karten oder Notizen; Definitionen pro Spalte sichtbar; Tool für Async-Pflege (Notion, Jira, Miro); Review-Termin im Kalender.
Ein Risk-Owner (RTE, Programmleitung, Tech Lead) für Pflege; alle Risiko-Owner; Reviewer pro Cadence (Team-Vertreter, Stakeholder); optional ein Coach für ROAM-Einführung.
Risikoliste aus Vorstufe; Definition pro Kategorie schriftlich; Review-Cadence-Vorschlag (z. B. wöchentlich oder pro Sprint); Eskalationsregeln für nicht-bewegte Risiken.
20-40 min initial, danach 10-15 min pro Review
Board mit vier Spalten. Definitionen pro Spalte als Banner: Resolved=erledigt; Owned=beobachtet mit Owner; Accepted=bewusst akzeptiert ohne Aktion; Mitigated=aktive Gegenmaßnahme läuft. Review-Termin als wiederkehrende Serie.
Die eine Frage, die diese Methode beantwortet
Welche Risiken sind in welchem Folge-Zustand, wer ist verantwortlich, und welche brauchen jetzt Bewegung zwischen den Spalten?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Definitionen kalibrieren | 10 min | Definition pro Spalte gemeinsam durchgehen. Klären, dass jedes Risiko in genau einer Spalte ist. Edge Cases besprechen (z. B. „beobachtet UND mitigiert“ -> Mitigated gewinnt). | Wenn Definitionen unklar bleiben, landen Risiken in der falschen Spalte. Mitigated muss aktiv heißen, nicht „wir denken drüber nach“. |
2Phase 2: Risiken initial zuordnen | 15-20 min | Pro Risiko Spalte wählen, Owner benennen. Bei Owned und Mitigated nächste Aktion und Frist. Bei Accepted Begründung im Kommentar. | Risiko ohne Owner ist Risiko ohne Folge. Wer Owner nicht benennt, hat keine Verantwortung definiert. Workshop endet nicht mit Risiken ohne Owner. |
3Phase 3: Review-Cadence festlegen | 5 min | Cadence-Frequenz wählen (wöchentlich für aktive Programme, alle 2 Wochen für stabile). Termin als Serie im Kalender. Verantwortliche für Pflege festlegen. | Cadence verfällt schnell, wenn nicht im Kalender. Erster Review innerhalb von 1 Woche nach Initialerstellung. Ohne Cadence stirbt das Board in 4 Wochen. |
4Phase 4: Reviews durchführen | 10-15 min pro Review | Pro Risiko: Status geändert? Owner aktiv? Aktion gemacht? Status-Wechsel zwischen Spalten dokumentieren. Eskalation bei mehrfach unbewegten Risiken. | Mitigated -> Resolved ist Ziel-Pfad. Owned, das nach 4 Wochen unverändert ist, prüfen: realer Owner? oder Accept-Kandidat? |
Was am Ende rauskommt
ROAM-Board mit Risiken in vier Spalten, Owner-Spalte, Status-Datum, Aktion-Notiz. Snapshot pro Review im Wiki archiviert. Eskalations-Liste für nicht-bewegte Risiken.
Board ist lebendig. Pro Review Snapshot (Datum) als Archiv. Status-Wechsel mit Datum und Begründung dokumentieren. Resolved-Risiken nach 3 Monaten in Archiv verschieben, nicht löschen.
Kompakte Arbeitsvorlage für ROAM Board mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# ROAM Board Canvas
## Kontext
Wofür wird die Methode eingesetzt?
## Kernfrage
Welche Frage soll am Ende beantwortet sein?
## Input
Welche Daten, Beobachtungen oder Materialien liegen vor?
## Arbeitsfläche
- Bereich 1:
- Bereich 2:
- Bereich 3:
- Beziehungen / Muster:
## Ergebnisartefakte
- ROAM Board:
- Owner-Liste:
## Offene Fragen
- ...
## Nächster Schritt
Owner, Datum, Erfolgssignal.Konkret gefülltes Szenario
## ROAM Board - PI-Planning Q3/2026, Review-Stand 2026-05-18
**Resolved (3)**
- R1: Multi-Tenant-Mandantenverwaltung Datenmodell offen -> Q1 mit Bounded-Context-Workshop geklärt.
- R2: SSO-Anbindung blockiert von IT-Genehmigung -> Genehmigung in Woche 14 erhalten.
- R3: QA-Kapazität unklar -> 2 zusätzliche QA-Engineers ab April.
**Owned (5)**
- O1: PSP-Breaking-Change Q3. Owner: @marcus. Nächste Aktion: Sandbox-Zugang anfordern bis 31.05.
- O2: Order-Service Bus-Faktor 1. Owner: @lisa. Knowledge-Sharing-Plan bis 15.06.
- O3: Veraltete Doku Order-API. Owner: @lisa. Quartalsreview Q3.
- O4: Compliance-Audit Termin offen. Owner: @ben. Klärung bis 25.05.
- O5: Frontend-Performance bei mehr als 1000 Mandanten. Owner: @anna. Monitoring-Setup bis 22.05.
**Accepted (2)**
- A1: Browser-Support für IE11 bleibt aus. Begründung: <0,5% Nutzer-Anteil, Aufwand nicht gerechtfertigt.
- A2: Saisonaler Throughput-Einbruch im August. Begründung: Erfahrungswert, eingeplant.
**Mitigated (4)**
- M1: DB-Replikation ohne Failover. Mitigation: Multi-Leader-Spike läuft, ETA 30.05. Owner: @ben.
- M2: Payment-Webhook kein Retry. Mitigation: Sprint 23 Implementation. Owner: @anna.
- M3: Inventory ohne Idempotenz. Mitigation: Sprint 24. Owner: @ben.
- M4: KI-Belegerkennung Anbieter-Risiko. Mitigation: Anbieter-Vergleich läuft. Owner: @anna.
**Eskalation**: O3 seit 6 Wochen unbewegt, Diskussion in nächstem Review: re-classify als Accepted?Symptome erkennen, gegensteuern
Risiken kleben in mehreren Spalten oder oszillieren zwischen Mitigated und Owned ohne Regel.
Regel: ein Risiko, eine Spalte. Bei Übergang von Mitigated zurück zu Owned (z. B. Mitigation pausiert) Begründung dokumentieren. Klare Definitionen helfen.
Erster Review findet statt, nach 4 Wochen Termin verschoben, nach 8 Wochen Board vergessen.
Cadence im Kalender als Serie. Pflege-Verantwortlicher mit Erinnerungspflicht. Bei Cadence-Skip mindestens kurze Status-Notiz.
Risiken landen in Accepted, weil niemand sich kümmern will, ohne bewusste Entscheidung.
Accepted braucht Begründung. Ohne Begründung gehört Risiko in Owned. Quartalsweise Accepted-Liste prüfen, ob Akzeptanz noch gerechtfertigt ist.
Owner ist gesetzt, nächste Aktion fehlt, Risiko bleibt monatelang Owned ohne Bewegung.
Owned braucht Aktion mit Frist. Stille-Owned > 4 Wochen wird in Eskalation diskutiert: ist Aktion noch geplant? Wenn nein, re-classify.
Board lebt im PM-Tool, Team und Stakeholder kennen es nicht, Risiken werden parallel woanders diskutiert.
Board in Team-Meetings sichtbar machen (Sprint-Review, Stakeholder-Briefing). Link in zentralen Kommunikationskanälen. Wer Risiko meldet, geht aufs Board.
Done-Signale, in unter einer Minute prüfbar
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen — oder direkt zur nächsten Methode im Katalog.