Risikoregister und Risikobericht
Das Risikoregister ist das Dokument, in dem das Projektteam jedes Einzelrisiko festhält: seine Kennung, seine Formulierung als Ursache, Ereignis und Auswirkung, seinen Risikoeigner, die geplante Reaktion und seinen Status. Der Risikobericht ist ein zweites Dokument. Das Team erstellt ihn aus dem Register und aus den übrigen Unsicherheitsquellen des Projekts. Er zeigt dem Auftraggeber das Gesamtrisiko des Projekts, seine Quellen und eine Zusammenfassung der Einzelrisiken. Der PMBOK Guide zählt beide zu den Ergebnissen des Prozesses Risiken identifizieren. Die Prozesse der Analyse, der Reaktion und der Überwachung ergänzen sie bis zum Projektabschluss.
Ziel
Das Register sagt dem Team, was geschehen kann und wer sich darum kümmert. Der Bericht sagt dem Auftraggeber, wie stark das ganze Projekt exponiert ist und was diese Exposition am stärksten erhöht.
Der PMBOK Guide definiert ein Risiko als unsicheres Ereignis oder unsichere Bedingung mit positiver oder negativer Wirkung auf ein oder mehrere Ziele, falls es eintritt. Das Register führt deshalb Bedrohungen und Chancen in denselben Spalten. Die Chancenanalyse behandelt die günstige Seite im Detail und trägt ihre Ergebnisse ins Register ein.
Mit dem Register wählt das Team für jedes Risiko eine Reaktion und nennt die Person, die sie trägt. Mit dem Bericht entscheidet der Auftraggeber, ob er das Projekt fortführt, neu ausrichtet oder abbricht.
Risikoanalyse und Risikomanagement beschreibt den Prozess, der das Register füllt: identifizieren, analysieren, bewerten, behandeln. Die Technik legt auch die Skalen für Wahrscheinlichkeit und Auswirkung fest, die das Register übernimmt.
Einsatz
Wann einsetzen
- Auftraggeber oder Steuerungsausschuss: Der Bericht liefert ihnen an jeder Sitzung die Gesamtexposition und die erwarteten Entscheide.
- Ende einer Phase oder eines Release: HERMES beurteilt die Risiken, bevor die nächste Phase oder das nächste Release freigegeben wird.
- Mehrere Risikoeigner: Jede Zeile nennt, wer den Auslöser beobachtet und wer handelt.
- Team an mehreren Standorten: Ein gemeinsames Register hält die Liste ohne Präsenzworkshop aktuell.
- Unabhängige Prüfung erwartet: Ein Register mit Änderungsverlauf zeigt, wann ein Risiko erkannt und was entschieden wurde.
- Projektabschluss: Das abgeschlossene Register fliesst in die Lessons Learned für das nächste Projekt ein.
Wann nicht einsetzen
- Ereignis bereits eingetreten: Es ist ein Problem. Es gehört ins Problemprotokoll, das Item Tracking führt.
- Kurzes Mandat mit geringer Tragweite: Das Register kostet mehr, als es bringt. Die Pendenzenliste im Protokoll genügt.
Beschreibung
Register und Bericht
Der PMBOK Guide definiert das Risikoregister als das Dokument, in dem das Team die Ergebnisse der Risikomanagementprozesse festhält. Es führt die Einzelrisiken des Projekts auf. Diese Prozesse speisen es vom Anfang bis zum Ende des Projekts: Risiken identifizieren, sie analysieren, Reaktionen planen, Reaktionen umsetzen und Risiken überwachen. Grösse und Komplexität des Projekts bestimmen den Umfang des Registers. Der Risikomanagementplan legt sein Format fest.
Der Risikobericht zeigt die Quellen des Gesamtrisikos des Projekts und eine Zusammenfassung der Einzelrisiken. Das Team baut ihn Schritt für Schritt auf: Jeder Prozess fügt seine Ergebnisse hinzu. Das Gesamtrisiko ist die Wirkung der Unsicherheit auf das Projekt als Ganzes. Die Einzelrisiken sind ein Teil davon. Eine wacklige Aufwandschätzung oder eine Technologie, die das Team erst kennenlernt, kann dazu beitragen, ohne eine Zeile im Register zu belegen.
Wer die Zeilen des Registers addiert, erfasst deshalb nur die Einzelrisiken. Der PMBOK Guide definiert die Risikoexposition als aggregiertes Mass der möglichen Auswirkung aller Risiken zu einem bestimmten Zeitpunkt. Der Bericht vergleicht die Exposition des Projekts mit der Schwelle des Auftraggebers und nennt, was die Exposition erhöht. Der PMBOK Guide definiert den Risikoappetit als das Mass an Unsicherheit, das eine Organisation in Erwartung eines Gewinns akzeptiert. Die Risikoschwelle beziffert ihn: Eine tolerierte Abweichung von ±5% vom Budget zeigt einen geringeren Appetit an als eine Abweichung von ±10%.
Was ins Register gehört
Ab der Identifikation verlangt der PMBOK Guide vom Team, Risiken von Nicht-Risiken zu trennen: von Befürchtungen und Problemen. Ein Problem ist bereits eingetreten oder dauert noch an. Es gehört ins Problemprotokoll. Ein Risiko ist ein Problem, das später eintreten kann. Tritt ein Risiko ein, wechselt seine Zeile in den Status "eingetreten". Im Problemprotokoll öffnet sich dann ein Problem. Eine Befürchtung drückt eine Sorge aus, ohne zu sagen, was geschehen könnte. Sie kommt ins Register, sobald sie als Ereignis umformuliert ist.
Eine Planungsannahme gehört ins Annahmenprotokoll. Die Annahmen- und Restriktionsanalyse leitet daraus ein Risiko ab, wenn sich die Annahme als wacklig erweist: Aus "der Lieferant liefert im März" wird "der Lieferant kann nach März liefern".
Ein Risiko formulieren: Ursache, Ereignis, Auswirkung
Der PMBOK Guide schlägt vor, ein Risiko durch Ursache, Ereignis und Auswirkung zu beschreiben. Diese Formulierung trennt das Risiko von seinen Ursachen und seinen Folgen. Sie passt in einen Satz: Aufgrund von <Ursache> kann <unsicheres Ereignis> eintreten, was <Auswirkung auf ein Ziel> zur Folge hätte.
Die Ursache ist eine Tatsache, die heute schon feststeht: ein gefällter Entscheid, eine Restriktion, eine Lage. Das Ereignis ist unsicher. Die Auswirkung sagt, welches Ziel es trifft: Termin, Kosten, Umfang, Qualität. Jeder Teil dient einem Entscheid. Eine vorbeugende Reaktion setzt bei der Ursache an. Der Auslöser meldet, dass das Ereignis näher rückt. Die Auswirkung nennt das bedrohte Ziel und damit die Person, die informiert werden muss.
| Geschriebene Zeile | Mangel | Neu geschriebene Zeile |
|---|---|---|
| "Fehlende Ressourcen" | Eine Ursache ohne Ereignis und ohne Auswirkung | Weil zwei Analysten auch einem zweiten Projekt zugeteilt sind, kann das zweite Projekt im Frühling Vorrang erhalten, was die Spezifikation der Prüfungen um sechs Wochen verzögern würde. |
| "Verzögerung der Inbetriebnahme" | Eine Auswirkung ohne Ursache und ohne Ereignis | Weil die Gemeinden drei verschiedene Softwarelösungen einsetzen, kann die Schnittstelle zu einer davon im Integrationstest scheitern, was die Inbetriebnahme in zwölf Gemeinden verzögern würde. |
| "Der Lieferant hat Los 1 verspätet geliefert" | Ein Problem: Das Ereignis ist eingetreten | Ins Problemprotokoll. Das Register nimmt das Risiko auf, das es offenlegt: Los 2 kann sich um dieselbe Dauer verspäten. |
| "Die Gemeinden sind nicht bereit" | Eine Befürchtung ohne Ereignis | Wegen der Belastung der Gemeindekanzleien zum Jahresende kann sich die Schulung der Anwenderinnen und Anwender über die Inbetriebnahme hinaus verschieben, was die Anrufe beim Support im ersten Monat verdoppeln würde. |
Eine Ursache führt oft zu mehreren Ereignissen. Jedes Ereignis erhält seine eigene Zeile, weil jedes seinen eigenen Auslöser und seine eigene Reaktion hat. Die gemeinsame Ursache lässt sich dann in der Spalte der Ursachen ablesen. Der Bericht übernimmt sie als Quelle des Gesamtrisikos.
Die Felder einer Zeile
Der PMBOK Guide legt den Inhalt des Registers bei der Identifikation fest. Jedes Risiko erhält eine eindeutige Kennung und eine Beschreibung, die sich nur auf eine Weise lesen lässt. Das Team notiert die möglichen Reaktionen und den möglichen Risikoeigner, sofern er bekannt ist. Die Analyse bestätigt den Risikoeigner, die Reaktionsplanung bestätigt die Reaktionen.
Der PMBOK Guide zählt weitere Felder auf. Der Risikomanagementplan übernimmt jene, die das Projekt braucht.
| Feld | Inhalt | Verwendung |
|---|---|---|
| Kurztitel | Einige Wörter, die das Risiko benennen | Das Risiko in der Sitzung und im Bericht nennen |
| Kategorie | Technik, Organisation, Regulierung, Lieferanten… | Die Risiken im Bericht nach Kategorie zählen |
| Status | Zum Beispiel offen, überwacht, eingetreten, geschlossen | Die Zeilen herausfiltern, die eine Massnahme verlangen |
| Ursachen | Eine oder mehrere | Ursachen erkennen, die mehrere Zeilen teilen |
| Auswirkungen auf die Ziele | Eine oder mehrere: Termin, Kosten, Umfang, Qualität | Die Personen bestimmen, die informiert werden müssen |
| Auslöser | Die Ereignisse oder Bedingungen, die anzeigen, dass das Risiko kurz vor dem Eintreten steht | Die Reaktion rechtzeitig auslösen |
| PSP-Referenz | Die betroffenen Aktivitäten im Projektstrukturplan | Das Risiko mit dem Terminplan verknüpfen |
| Zeitangaben | Datum der Identifikation, Zeitraum des möglichen Eintretens, Datum, ab dem das Risiko nicht mehr relevant ist, Frist für die Massnahme | Die Fristen einhalten und abgelaufene Zeilen schliessen |
Die Ergebnisse der folgenden Prozesse kommen rechts dazu: geschätzte Wahrscheinlichkeit und Auswirkung, Priorität, gewählte Reaktion und Stand der Massnahmen. Die Bewertungsskalen und die Wahrscheinlichkeits- und Auswirkungsmatrix gehören zur Analyse. Die Wahl der Reaktion ist Sache der Risikoreaktionsstrategien.
Niemand überwacht eine Zeile ohne namentlichen Risikoeigner: "Das Projektteam" achtet auf keinen Auslöser. Ein Register, das nur wächst, begräbt die offenen Risiken unter abgelaufenen Zeilen. Das Team schliesst deshalb jede Zeile, deren Risiko seit dem eingetragenen Datum nicht mehr relevant ist.
Der Risikobericht
Nach der Identifikation nennt der Bericht die Quellen des Gesamtrisikos und zeigt, welche die Exposition des Projekts am stärksten erhöhen. Er fasst auch die Einzelrisiken zusammen: die Zahl der Bedrohungen und Chancen, ihre Verteilung nach Kategorie, Kennzahlen und deren Trend.
Die folgenden Prozesse ergänzen den Bericht. Die quantitative Analyse fügt zum Beispiel die Wahrscheinlichkeit hinzu, den Termin der Inbetriebnahme zu halten. Die Monte-Carlo-Simulation berechnet sie. Die Sensitivitätsanalyse ordnet die Risiken nach ihrer Wirkung auf den Termin der Inbetriebnahme oder auf die Endkosten. Die Reaktionsplanung fügt die Reaktionen auf das Gesamtrisiko hinzu. Die Überwachung fügt danach die Wirkung dieser Reaktionen hinzu.
Der PMBOK Guide wendet die Reaktionsarten für Einzelrisiken auf das ganze Projekt an. Um das Gesamtrisiko zu vermeiden, nimmt das Team die riskantesten Elemente aus dem Umfang. Um es zu mindern, plant das Team neu oder verteilt die Ressourcen anders. Um es zu akzeptieren, legt der Auftraggeber eine Kontingenzreserve für das ganze Projekt fest. Die Reserveanalyse bemisst sie. Um ein günstiges Gesamtrisiko auszunutzen, nimmt das Team Elemente mit hohem Wert in den Umfang auf. Bringt keine Reaktion das Projekt unter die Schwelle zurück, kann die Organisation es abbrechen. Der Bericht schliesst mit den Entscheiden, die er vom Auftraggeber verlangt. Jeder verweist auf die Zeile im Register oder auf die Quelle, die ihn begründet.
Weder der PMBOK Guide noch das Orange Book des britischen Finanzministeriums legen das Layout des Berichts fest. Der PMBOK Guide verweist auf die Berichtsanforderungen des Risikomanagementplans. Das Orange Book verlangt vom Leitungsorgan, Art, Quelle, Format und Häufigkeit der Informationen festzulegen, die es erwartet. Für jedes Hauptrisiko empfiehlt es eine Zusammenfassung: die Lage gegenüber dem Risikoappetit, das Ergebnis der Massnahmen, die Warnindikatoren und den Trend.
Die häufige Falle ist der Bericht, der die zehn obersten Zeilen des Registers abschreibt. Er sagt nicht, ob das ganze Projekt die Schwelle überschreitet und welche Quelle es darüber treibt. Die zweite Falle ist der Bericht, der nur die Bedrohungen zählt. Er überschätzt die Exposition.
Beide Dokumente aktuell halten
Der PMBOK Guide hält fest, dass die erste Identifikation unvollständig bleibt, weil manche Risiken erst im Lauf des Projekts auftauchen. In regelmässigen Abständen bis zum Abschluss aktualisiert das Team das Register: Es nimmt neue Risiken auf, beurteilt die bestehenden neu und passt die Reaktionen an. Für die agile Entwicklung nennt der PMBOK Guide das Beispiel eines Teams, das die Risiken zu Beginn jedes Sprints überprüft. Am Ende jeder Iteration geht es sie mit den Stakeholdern erneut durch.
Der Bericht begleitet jede Sitzung des Steuerungsausschusses und jedes Phasenende. Sein Trend vergleicht die heutige Überprüfung mit der letzten: neue Risiken, geschlossene Risiken, eingetretene Risiken. Beim Abschluss geht das vollständige Register in die Lessons Learned. Das nächste Projekt lernt aus den wirksamen Reaktionen und aus den Risiken, die niemand gesehen hatte.
In HERMES
In HERMES 2022 führt die Projektleitung die Aufgabe Risiken managen aus. Sie identifiziert die Risiken, gruppiert sie, analysiert sie und beurteilt sie. Für jedes Risiko legt sie eine Strategie (Vermeidung, Verminderung, Auslagerung, Akzeptanz) und Massnahmen fest. HERMES definiert kein Ergebnis "Risikoregister". Bei klassischer Vorgehensweise enthält die Detailplanung der nächsten Phase jedoch die Aktivität "Risikoliste und Massnahmen nachführen" (7.4.5.3). Die Projektleitung hält die Risiken im Projektstatusbericht fest, die effektiven Risiken danach im Phasen- oder Releasebericht. Bei klassischer Vorgehensweise bereitet die Risikobeurteilung an jedem Phasenende den Entscheid über die Freigabe der nächsten Phase vor. Bei agiler Vorgehensweise findet sie am Ende jedes Release statt.
HERMES kennt auch einen QS- und Risikobericht. Der Qualitäts- und Risikomanager erstellt ihn im Auftrag des Auftraggebers. Er beurteilt das Projekt aus unabhängiger Sicht. Der Bericht umfasst Auftrag und Abgrenzung, Vorgehensweise, Gesamtbeurteilung mit Projektstatus, Qualitätsbeurteilung, Risikobeurteilung und Empfehlungen. Der Risikobericht des PMBOK Guide ist ein Projektdokument, das das Team selbst erstellt.
| PMBOK Guide | HERMES 2022 | Verfasst von | Gelesen von |
|---|---|---|---|
| Risikoregister | Kein eigenes Ergebnis. Risikoliste, die bei der Planung jeder Phase nachgeführt wird. Die Risiken stehen im Projektstatusbericht | Projektleitung | Projektteam, Auftraggeber |
| Risikobericht | Rubrik "Risiken" des Projektstatusberichts; effektive Risiken im Phasen- oder Releasebericht | Projektleitung | Auftraggeber, Steuerungsausschuss |
| Keine Entsprechung | QS- und Risikobericht | Qualitäts- und Risikomanager im Auftrag des Auftraggebers | Auftraggeber |
KI-Überlegungen
Ein Sprachmodell formuliert eine Befürchtung als Ursache, Ereignis und Auswirkung um. Es findet die Zeilen, die ein Problem oder nur eine Ursache beschreiben. Es schlägt eine Kategorie vor, erkennt Doppelungen und markiert Zeilen ohne namentlichen Risikoeigner oder ohne Auslöser. Aus einem Export des Registers zählt es Bedrohungen und Chancen nach Kategorie und schreibt den Trend von einer Überprüfung zur nächsten. Der PMBOK Guide zählt generative KI und Datenanalyse zu den Techniken, mit denen sich Risiken identifizieren und analysieren lassen.
Das Modell kennt die echten Ursachen des Projekts nicht. Es erzeugt plausible generische Risiken, die das Register aufblähen. Eine vorgeschlagene Zeile kommt ins Register, wenn ein Risikoeigner sie anerkennt und die Verantwortung dafür übernimmt. Der Auftraggeber beurteilt die Gesamtexposition und die Schwelle. Das Register nennt Personen, Lieferanten und Schwächen in Verträgen. Es geht nur an einen externen KI-Dienst, wenn die Organisation das erlaubt. In einer Schweizer Verwaltung entscheiden darüber das anwendbare Datenschutzrecht und der Ort des Hostings.
Beispiele
Ein Westschweizer Kanton digitalisiert die Baugesuche. Das Projekt folgt HERMES und schliesst die Phase Konzept ab. Das Register zählt 14 offene Risiken. Der Auszug zeigt fünf davon, darunter zwei Chancen. Die Spalten der Analyse lässt der Auszug weg.
| Risiko | Ursache | Ereignis | Auswirkung | Risikoeigner | Reaktion | Auslöser | Status |
|---|---|---|---|---|---|---|---|
| R-03 Bedrohung · Technik | Die Gemeinden setzen drei Softwarelösungen für die Dossierverwaltung ein | Die Schnittstelle zur Software C scheitert im Integrationstest | Zwölf Gemeinden bleiben bei der Inbetriebnahme beim Papierdossier | Lösungsarchitekt | Prototyp der Schnittstelle vor dem Integrationstest mit dem Hersteller getestet | Der Hersteller liefert seine Schnittstellenspezifikation nicht bis zum 30. September | Offen |
| R-05 Bedrohung · Regulierung | Das kantonale Raumplanungsgesetz wird revidiert | Der Grosse Rat ändert vor der Inbetriebnahme die Liste der Gesuchsunterlagen | Formulare und Prüfungen müssen für rund CHF 90'000 neu erstellt werden | Jurist des Amts für Raumplanung | Konfigurierbare Liste der Unterlagen | Die parlamentarische Kommission verabschiedet den Gesetzesentwurf | Offen |
| R-07 Bedrohung · Organisation | Zwei der drei Analysten arbeiten auch an der Erneuerung des Grundbuchs | Die Erneuerung des Grundbuchs erhält im Frühling Vorrang | Die Spezifikation der Prüfungen gerät sechs Wochen in Verzug | Projektleitung | Eskalation an den Steuerungsausschuss zum Entscheid über den Vorrang | Das Grundbuch zieht seinen Termin für die Inbetriebnahme vor | Offen |
| R-08 Chance · Technik | Der Nachbarkanton betreibt auf derselben Plattform ein Modul zur Prüfung der Pläne | Der Nachbarkanton ist bereit, sein Modul zu teilen | Acht Wochen Entwicklung eingespart | Projektleitung | Eine Vereinbarung über die gemeinsame Nutzung vorschlagen | Antwort des Nachbarkantons auf die Anfrage vom 15. Oktober | Offen |
| R-09 Chance · Organisation | Neun Gemeinden erhalten die Pläne bereits als PDF | Diese Gemeinden sind bereit, den Dienst drei Monate vor den anderen zu öffnen | Supportkosten auf Basis der Belastung berechnet, die vor der allgemeinen Inbetriebnahme gemessen wird | Verantwortliche für die Einführung | Eine Pilotphase vorschlagen | Zustimmung der neun Gemeindekanzleien | Offen |
Der Bericht an den Steuerungsausschuss fasst diese Zeilen nach Quellen des Gesamtrisikos zusammen. Er führt auch eine Quelle auf, die keine Zeile im Register belegt. Das Team schätzt den Aufwand für die Übernahme der laufenden Dossiers auf ±30% genau. Wie die Einzelrisiken erhöht diese Unsicherheit die Exposition.
Visualisierungen
Das Register ist eine Tabelle: eine Zeile pro Risiko, eine Spalte pro Feld. Der Bericht passt auf eine Seite. Er zeigt die Exposition gegenüber der Schwelle, die Verteilung nach Kategorie und den Trend von einer Überprüfung zur nächsten. Die Wahrscheinlichkeits- und Auswirkungsmatrix ordnet die analysierten Risiken nach ihren beiden Faktoren an. Ein Schema verbindet die Zeilen des Registers mit den Rubriken des Berichts. Ein zweites verfolgt beide Dokumente durch die fünf Prozesse des Risikomanagements.
Aufwand
| Phase | Stufe | Begründung |
|---|---|---|
| Vorbereitung | Mittel | Im Risikomanagementplan die Felder des Registers, die Kategorien, die Schwelle des Auftraggebers und den Inhalt des Berichts festlegen. |
| Durchführung | Mittel | Ein Identifikationsworkshop zu Beginn, danach eine kurze Überprüfung des Registers an jeder Statussitzung oder in jedem Sprint. |
| Dokumentation | Hoch | Jede Zeile bis zu ihrem Abschluss aktuell halten und den Bericht vor jeder Sitzung des Steuerungsausschusses erstellen. |
Werkzeuge
Für ein Register mit einigen Dutzend Zeilen genügt eine Tabellenkalkulation: Auswahllisten für Kategorie und Status, ein Filter auf die Fristen. Ein Tracking-Tool wie Jira oder Azure DevOps führt Risiken als Tickets eines eigenen Typs. Es protokolliert jede Statusänderung und benachrichtigt den Risikoeigner. Software für Risikomanagement und Module für Governance, Risk und Compliance (GRC) fassen mehrere Projekte zusammen und führen einen Prüfpfad. Das Team schreibt den Bericht in einer Textverarbeitung oder auf einer Folie. Ein Dashboard-Tool wie Power BI erzeugt ihn aus einem Export des Registers. Für eine Schweizer Verwaltung bestimmt der Speicherort der Daten die Wahl, sobald das Register Lieferanten oder Personen nennt.
Quellen
- Project Management Institute, A Guide to the Project Management Body of Knowledge (PMBOK Guide), 8. Aufl., PMI: Risiko, Problem, Gesamtrisiko, Risikoappetit, Risikoschwelle und Risikoexposition (§2.7.1); die iterative Identifikation und die Trennung von Risiken und Nicht-Risiken (§2.7.2.2); das agile Beispiel und generative KI (§2.7.3); der Inhalt von Risikoregister und Risikobericht (Section 4, Einträge Risk register und Risk report); die Strategien für das Gesamtrisiko (Section 5).
- Bundeskanzlei, HERMES 2022, Referenzhandbuch Projektmanagement: die Aufgabe Risiken managen (5.4.3.41); die Detailplanung der nächsten Phase (7.4.5.3); die Ergebnisse Phasenbericht (4.4.1.29), Projektstatusbericht (4.4.1.36) und QS- und Risikobericht (4.4.1.42).
- HM Treasury, The Orange Book: Management of Risk, Mai 2023, Abschnitt D "Risk reporting": die vom Leitungsorgan festgelegten Informationen und ihre zusammengefasste Darstellung für jedes Hauptrisiko.