Was vorher fertig sein muss
Eine Liste identifizierter Risiken liegt vor (aus Risk Storming, Pre-Mortem oder Discovery-Output), jedes mit Kurzbeschreibung.
Was vor Start vorliegen muss
Whiteboard oder Miro-Board mit Matrix (3x3 oder 5x5, Wahrscheinlichkeit horizontal, Auswirkung vertikal); farbliche Zonen (grün/gelb/rot); Risikoliste als Karten; Skala-Definitionen sichtbar; Timer.
Ein Facilitator, der Skala wachhält und Konsens moderiert; 3-10 Teilnehmer mit Risiko-Kontext (Engineering, Operations, Compliance, Product, Sponsor); ein Scribe für Bewertung und Aktionen.
Risikoliste vorab verteilt; schriftliche Definition der Skalen (z. B. Wahrscheinlichkeit 1=selten, 5=fast sicher; Auswirkung 1=kosmetisch, 5=existenzbedrohend); Zonen-Definition (grün=akzeptieren, gelb=beobachten, rot=Aktion).
30-60 min
Matrix-Raster auf Board zeichnen (5x5 üblich). Skala-Werte beschriften. Zonen farblich markieren (grün=W*A 1-6, gelb=7-14, rot=15-25). Skalendefinitionen als Banner sichtbar.
Die eine Frage, die diese Methode beantwortet
Wo verortet jedes Risiko sich auf der Wahrscheinlichkeits-Auswirkungs-Skala, und welche Risiken brauchen sofort Aktion, welche Beobachtung, welche akzeptierte Inkaufnahme?
Marker: Phase
| Schritt | Dauer | Aktion | Hinweis |
|---|---|---|---|
1Phase 1: Skala kalibrieren | 10 min | Skalen-Definitionen gemeinsam durchgehen. Mindestens ein Beispiel pro Stufe (z. B. „A=5: Komplettausfall >24h“, „A=1: Tooltip falsch“). Konsens festhalten. | Ohne kalibrierte Skala wird Bewertung Bauchgefühl. Wenn Beispiele nicht spontan greifbar, Skala-Definition vor Workshop schärfen. |
2Phase 2: Risiken einzeln einordnen | 15-30 min | Pro Risiko Karte vorlesen, Team schätzt W und A getrennt (z. B. per Daumen-Zeichen oder Voting-Tool). Bei Divergenz kurz diskutieren, dann Konsens-Wert oder Mittel. | Maximal 2 min Diskussion pro Risiko. Wenn keine Konvergenz, höheren Wert nehmen (Vorsichtsprinzip). Endlose Debatten sind Symptom für unklare Skala. |
3Phase 3: Zonen-Analyse | 10 min | Verteilung der Risiken auf Zonen prüfen. Rote Zone als Top-Liste extrahieren. Gelbe Zone als Beobachtungsliste. Grüne Zone als „Accepted“ dokumentieren. | Mehr als 10 rote Risiken ist Signal für unterbewertetes System oder zu strenge Skala. Skala neu kalibrieren oder Risikoreduktion vor weiterem Vorhaben. |
4Phase 4: Maßnahmen pro Hochrisiko | 15-20 min | Pro rotem Risiko Maßnahme definieren: Vermeiden, Vermindern (Mitigate), Transferieren oder Akzeptieren. Owner und Frist setzen. Übergabe an ROAM-Board oder RAID-Log. | Ohne Maßnahme ist Matrix Bilderbuch. Mindestens jede rote Zone hat Owner und nächste Aktion. „Akzeptieren“ ist valide Maßnahme, muss aber bewusst dokumentiert sein. |
Was am Ende rauskommt
Matrix-Diagramm (Board-Export oder Foto) plus Risikoliste in Markdown oder Tabelle mit Beschreibung, W, A, Zone, Maßnahme, Owner, Frist. Skala-Definitionen als Header-Sektion.
Pro Bewertungs-Runde Snapshot mit Datum. Bewertungs-Änderungen mit Begründung dokumentieren. Resolved Risiken als „Resolved“ markieren, nicht entfernen. Quartalsweise neue Matrix als Update, alte archivieren.
Kompakte Arbeitsvorlage für Risk Matrix mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
# Risk Matrix Arbeitsmatrix
| Element | Beschreibung | Bewertung | Evidenz | Owner | Nächster Schritt |
|---|---|---|---|---|---|
| 1 | | | | | |
| 2 | | | | | |
| 3 | | | | | |
## Ergebnisartefakte
- Risikomatrix:
- Top-Risiko-Liste:
## Entscheidung oder Empfehlung
Welche Konsequenz ergibt sich aus der Matrix?Konkret gefülltes Szenario
## Risk Matrix - Order-Service-Release v2, 2026-05-18
**Skala**
- Wahrscheinlichkeit: 1=selten (jährlich), 2=möglich, 3=wahrscheinlich (quartalsweise), 4=häufig (monatlich), 5=fast sicher (wöchentlich).
- Auswirkung: 1=kosmetisch, 2=Workaround vorhanden, 3=Degradation, 4=teilweiser Ausfall, 5=Komplettausfall.
**Bewertete Risiken (12)**
| Risiko | W | A | Zone | Maßnahme | Owner | Frist |
|--------|---|---|------|----------|-------|-------|
| DB-Replikation ohne Failover | 4 | 5 | rot | Mitigate (Multi-Leader-Spike) | @ben | 30.05. |
| Payment-Webhook kein Retry | 3 | 5 | rot | Mitigate (Sprint 23) | @anna | 14.06. |
| Order-Service Bus-Faktor 1 | 4 | 4 | rot | Mitigate (Knowledge Sharing) | @lisa | 15.06. |
| PSP-Breaking-Change Q3 | 3 | 4 | gelb | Eskalation an PSP | @marcus | 31.05. |
| Inventory ohne Idempotenz | 3 | 4 | gelb | Mitigate (Sprint 24) | @ben | 28.06. |
| Veraltete Doku Order-API | 2 | 2 | grün | Accepted, Quartalsreview | @lisa | - |
**Zonenverteilung**: 3 rot, 4 gelb, 5 grün. Rote Zone überschaubar, Aktionen im Sprint-Plan.Symptome erkennen, gegensteuern
Teilnehmer interpretieren W=3 unterschiedlich, Bewertungen sind inkonsistent.
Vor Bewertung pro Skala-Stufe mindestens ein konkretes Beispiel an die Wand. Bei Unklarheit Workshop unterbrechen und Skala schärfen, nicht durchpressen.
W*A wird als präzise Zahl behandelt, Differenz zwischen 14 und 16 wird wichtig genommen.
Skala ist ordinal, nicht numerisch genau. Zonen-Übergänge sind grobe Orientierung. Bei Grenzfällen ehrliche Diskussion, nicht Rechenakrobatik.
Bewertung wird durch dominante Stimme oder Senior-Meinung geprägt, leise Perspektiven untergehen.
Verdecktes Voting (Karten, Tool) statt offener Diskussion. Bei Divergenz Annahmen erfragen, nicht Konsens erzwingen.
Rote Risiken werden bewertet, aber keine Maßnahme abgeleitet.
Pro rotem Risiko vor Workshop-Ende Maßnahmen-Typ und Owner. „Accepted“ ist valide, muss aber dokumentiert sein. Workshop endet nicht mit unaktionierten roten Risiken.
Matrix wird einmal erstellt, hängt im Wiki, Risiken ändern sich aber laufend.
Quartalsweise Review-Cadence. Bei Architektur- oder Org-Änderung außerplanmäßiges Update. Matrix ist lebendes Artefakt, nicht Kunstwerk.
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.