Risikoregister: Was es ist und wie man es aufbaut (Vorlage)

Ein Risikoregister ist das Dokument, das vage Projektangst in eine strukturierte, handhabbare Liste verwandelt. Jedes Projekt hat Risiken. Die Frage ist, ob diese Risiken im Kopf von jemandem leben oder in einem gemeinsamen Dokument, auf das das gesamte Team reagieren kann.

Was ist ein Risikoregister?

Ein Risikoregister ist ein Projektmanagement-Tool, das identifizierte Risiken, ihre Wahrscheinlichkeits- und Auswirkungsbewertungen, zugewiesene Eigentümer und geplante Reaktionsstrategien in einem einzigen gemeinsamen Dokument erfasst. Es wird manchmal auch als Risikoprotokoll bezeichnet, wobei beide Begriffe in der Praxis im Wesentlichen austauschbar sind.

Das Register beseitigt keine Risiken. Es macht Risiken sichtbar, damit das Team entscheiden kann, welche Risiken eingedämmt, welche beobachtet und welche einfach akzeptiert werden sollen. Ein dokumentiertes Risiko ist ein steuerbares Risiko. Ein Risiko, das nur im Gedächtnis von jemandem existiert, ist ein Termin, der explodieren wird.

Key Facts

• Projekte mit aktiven Risikomanagementpraktiken sind 2,5-mal wahrscheinlicher, ihre Ziele zu erreichen als solche ohne (PMI Pulse of the Profession, 2023).
• Schlechtes Risikomanagement ist die zweithäufigste Ursache für Projektversagen, genannt von 39 % der Projektmanagement-Fachleute weltweit (PMI, 2024).
• Organisationen, die Risiken proaktiv managen, verschwenden 13-mal weniger Geld als diejenigen, die es nicht tun (PMI Pulse of the Profession, 2023).

Was in ein Risikoregister gehört (die Spalten)

Ein Risikoregister funktioniert am besten, wenn jede Spalte einen klaren Zweck hat. Hier sind die Standardfelder und was jedes davon tut.

So sieht ein befülltes Risikoregister mit einigen realistischen Zeilen aus:

Die Spalte Risikobewertung ist das Priorisierungsinstrument. Risiken mit einem Wert von 6 oder höher stehen typischerweise auf der wöchentlichen Agenda. Risiken mit einem Wert von 3 oder darunter können auf eine Beobachtungsliste verschoben werden, sofern sich nichts ändert.

Risikoregister vs. Risikoprotokoll vs. RAID-Log

Diese Begriffe überschneiden sich stärker als nötig, was zu echten Verwirrungen in Projektteams führt. Hier ein klarer Vergleich.

In der Praxis werden "Risikoregister" und "Risikoprotokoll" in den meisten Teams synonym verwendet. Der wesentliche Unterschied besteht zwischen einem eigenständigen Risikoregister (nur Risiken, in voller Tiefe) und einem RAID-Log, das Risiken zusammen mit Annahmen, Issues und Abhängigkeiten in einem einzigen Dokument mit moderater Tiefe abdeckt.

Für die meisten Projektmanager ist das RAID-Log der richtige Ausgangspunkt. Das Risikoregister eignet sich, wenn das Projekt groß genug oder ausreichend reguliert ist, dass die Risikokategorie allein ein eigenes dediziertes Dokument mit vollständiger Wahrscheinlichkeits-Auswirkungs-Analyse benötigt.

Vorteile eines Risikoregisters

Es bringt Risiken ans Licht, bevor sie zu Krisen werden. Der Prozess des Aufbaus eines Risikoregisters zwingt das Team, durchzudenken, was schiefgehen könnte, bevor tatsächlich etwas passiert. Teams, die diese Übung beim Projektkickoff durchführen, entdecken Probleme Wochen oder Monate früher als Teams, die es nicht tun.

Es schafft eine gemeinsame Sprache für Unsicherheit. Wenn alle im Team auf dasselbe Risikoregister zeigen können, wird aus "Ich mache mir Sorgen um den Lieferantenzeitplan" ein "R-001 ist mit Hoch/Hoch bewertet und Alex ist für die Maßnahme verantwortlich." Diese Präzision verändert die Gespräche in Statusmeetings.

Es gibt dem Projektmanager etwas, das er vorweisen kann. Wenn ein Sponsor fragt, warum ein Liefertermin gerutscht ist, zeigt das Risikoregister, ob das Ereignis protokolliert war, wer es besessen hat und ob der Maßnahmenplan eingehalten wurde. Das ist nicht nur defensiv. So bauen Projektteams langfristig Glaubwürdigkeit auf.

Es verbindet Risiken mit dem Projektstrukturplan. Sobald Risiken dokumentiert sind, lässt sich nachverfolgen, welche Arbeitspakete das größte Risikopotenzial tragen. Das informiert darüber, wie Puffer im Zeitplan verteilt werden und wo die stärksten Mitarbeiter eingesetzt werden.

Es ermöglicht eine bessere Stakeholder-Analyse. Zu wissen, welche Risiken welche Stakeholder betreffen, hilft zu entscheiden, wer informiert, wer konsultiert und wer zur Genehmigung eines Reaktionsplans befugt werden muss.

Häufige Fehler

Risiken einmalig protokollieren und nie wieder überprüfen. Ein Risikoregister, das nicht regelmäßig überprüft wird, wird zur Fiktion. Risiken ändern ihren Status. Neue Risiken entstehen. Eigentümer verlassen das Unternehmen. Einen festen Slot im wöchentlichen Statusmeeting für eine 10-minütige Risikoprüfung einplanen, sonst driftet das Dokument.

Vage Beschreibungen verwenden. "Kommunikationsrisiko" ist kein Risiko. "Kunden-Stakeholder haben die Freigabe des Scope-Dokuments nicht bestätigt, und das Projekt kann ohne diese Freigabe nicht in die Build-Phase übergehen" ist ein Risiko. Spezifisch genug formulieren, dass jemand, der nicht dabei war, als das Risiko protokolliert wurde, genau versteht, was auf dem Spiel steht.

Risiken Teams statt Personen zuweisen. "Das IT-Team" ist kein Eigentümer. Eine namentlich genannte Person ist der Eigentümer. Diese Person überwacht das Risiko, eskaliert bei Bedarf und aktualisiert den Status bei jeder Überprüfung. Ein Team kann nicht zur Rechenschaft gezogen werden. Eine Person schon.

Alles als Hoch einstufen. Wenn jedes Risiko eine 9 ist, ist keine eine 9. Bewertungen ehrlich kalibrieren. Ein gut bewertetes Register ermöglicht es, Energie auf die Risiken zu konzentrieren, die wirklich wichtig sind. Ein Register voller 9en erzeugt Lärm und verbrennt Aufmerksamkeit für Dinge, die es nicht rechtfertigen.

Das Register als Compliance-Artefakt behandeln. Manche Projektmanager erstellen ein Risikoregister, weil das Governance-Framework es vorschreibt, und öffnen es dann nie wieder. Ein Risikoregister verdient seinen Platz nur, wenn es ein lebendiges Dokument in aktiver Nutzung ist.

Gelöste Risiken nicht zu schließen vergessen. Wenn ein Risiko eingedämmt oder vermieden wurde, es mit einem Vermerk abschließen, was geschehen ist. Diese geschlossenen Einträge werden zum institutionellen Wissen für das nächste ähnliche Projekt.

So baut man ein Risikoregister auf

Schritt 1: Risiken identifizieren

Beim Projektkickoff beginnen. Ein strukturiertes Brainstorming mit dem Kernteam durchführen: Was könnte schiefgehen? Was nehmen wir an, das möglicherweise nicht zutrifft? Von was sind wir abhängig, was von externen Teams oder Lieferanten kommt? Lessons-Learned-Dokumente aus ähnlichen vergangenen Projekten heranziehen. Ziel ist es, so viele Risiken wie möglich zu erfassen, bevor mit der Bewertung begonnen wird. In dieser Phase zählt Quantität vor Qualität.

Gängige Kategorien zur Gesprächsstimulation: technische Risiken, Ressourcenrisiken, Terminrisiken, Budgetrisiken, externe Abhängigkeiten, Compliance- und regulatorische Risiken sowie Stakeholder-Risiken.

Schritt 2: Klare, spezifische Beschreibungen formulieren

Für jedes Risiko eine ein- bis zweiSatz-Beschreibung schreiben, die erklärt, was das Risiko ist und warum es für das Projekt relevant ist. Abkürzungen vermeiden. "API-Integrationsfehler" ist weniger nützlich als "Die Zahlungs-API eines Drittanbieters unterstützt möglicherweise nicht das Authentifizierungsprotokoll und erfordert eine benutzerdefinierte Middleware-Entwicklung, die vier bis sechs Wochen zum Zeitplan hinzufügt."

Schritt 3: Wahrscheinlichkeit und Auswirkung bewerten

Eine konsistente Skala für das gesamte Register verwenden. Eine 3-Punkte-Skala (Niedrig, Mittel, Hoch entsprechend 1, 2, 3) reicht für die meisten Teams. Eine 5-Punkte-Skala eignet sich für große Programme. Keine Skalenmischung innerhalb desselben Registers.

Wahrscheinlichkeit basierend darauf bewerten, wie wahrscheinlich das Eintreten des Risikos ist, in Anbetracht des Projektkontexts, des Teams, der Lieferantenhistorie und des Marktumfelds. Auswirkung danach bewerten, wie schlimm das Ergebnis wäre, wenn das Risiko einträte. Dann multiplizieren: eine mittlere Wahrscheinlichkeit (2) kombiniert mit hoher Auswirkung (3) ergibt eine Bewertung von 6.

Schritt 4: Nach Bewertung priorisieren und Eigentümer zuweisen

Das Risikoregister nach Bewertung sortieren, höchste zuerst. Risiken ab 6 erhalten aktive Maßnahmenpläne und wöchentliche Überprüfung. Risiken zwischen 3 und 4 kommen auf die Beobachtungsliste und werden monatlich überprüft. Risiken zwischen 1 und 2 werden akzeptiert: protokolliert, aber ohne Ressourcenzuweisung für Maßnahmen.

Für jedes Risiko ab 4 einen namentlich genannten Eigentümer zuweisen. Diese Person ist verantwortlich für die Überwachung des Risikos, die Ausführung des Reaktionsplans und die Meldung jeder Statusänderung. Mit der RACI-Matrix abgleichen, um sicherzustellen, dass die Eigentümerzuweisung mit den Verantwortlichkeitsrollen im Projekt übereinstimmt.

Schritt 5: Reaktionsstrategien definieren

Jedes Risiko braucht eine dokumentierte Reaktion. Es gibt vier Standardtypen:

• Vermeiden: Den Projektplan anpassen, um das Risiko vollständig zu beseitigen. Beispiel: wenn ein Lieferant schlechte Referenzen hat, vor dem Eintreten des Risikos den Lieferanten wechseln.
• Mindern: Maßnahmen ergreifen, um Wahrscheinlichkeit oder Auswirkung zu reduzieren. Beispiel: einen zweiten Entwickler an kritischen Bereichen einarbeiten, um die Auswirkung eines Key-Person-Risikos zu verringern.
• Übertragen: Das Risiko auf einen Dritten verlagern. Beispiel: Projektversicherung abschließen oder eine Leistungsklausel in einen Lieferantenvertrag aufnehmen.
• Akzeptieren: Das Risiko anerkennen und einen Notfallplan vorbereiten, ohne proaktive Maßnahmen zu ergreifen. Am besten für Risiken mit niedrigem Score, bei denen Maßnahmen mehr kosten als die potenzielle Auswirkung.

Schritt 6: Während des gesamten Projekts überprüfen und überwachen

Das Risikoregister ist kein Kickoff-Artefakt. Es ist ein lebendes Dokument. In jedem Statusmeeting wöchentlich überprüfen: Status aktualisieren, bestätigen, dass Reaktionspläne ausgeführt werden, gelöste Risiken schließen und neue hinzufügen, sobald sie entstehen. Während risikoreicherer Phasen des Projektlebenszyklus eine Midweek-Risikoprüfung für alle offenen Hochrisikopunkte in Betracht ziehen.

Wenn ein Risiko eintritt, wird es zu einem Issue und sollte entsprechend verfolgt werden. In einem RAID-Log wird es vom Risikoabschnitt in den Issue-Abschnitt verschoben. In einem eigenständigen Risikoregister den Status auf "Eingetreten" setzen und einen separaten Issue-Log-Eintrag öffnen.

Risikoregister-Beispiele nach Projekttyp

Verschiedene Projekttypen haben unterschiedliche Risikoprofile. So sieht ein Risikoregistereintrag in drei gängigen Kontexten aus.

Bei Software-Projekten dominieren technische und Ressourcenrisiken. Bei Bauprojekten sind regulatorische Compliance- und wetterbedingte Terminrisiken am schwersten. Bei Marketing-Launches sind Lieferanten- und Kreativliefertermine das größte Risikopotenzial. Die Struktur des Registers bleibt über alle drei hinweg gleich. Nur Kategorien und Bewertungen verschieben sich.

Wenn das Projekt mehrere Arbeitspakete umfasst, sollte das Risikoregister mit der Methode des kritischen Pfads verknüpft werden. Risiken, die Aufgaben auf dem kritischen Pfad betreffen, verdienen eine höhere Priorität als Risiken, die Aufgaben mit zeitlichem Spielraum betreffen, auch bei gleicher Wahrscheinlichkeits-Auswirkungs-Bewertung.

Best Practices

Einen namentlich genannten Eigentümer pro Risiko zuweisen. Kein Team. Keine Rolle. Eine Person.

Das Register in jedem Statusmeeting überprüfen. Selbst ein 10-minütiger Durchlauf reicht, um es aktuell und glaubwürdig zu halten.

Hochbewertete Risiken mit der Projektumfangsbeschreibung verknüpfen. Wenn ein Risiko zentrale Liefergegenstände bedroht, ist das ein Gespräch mit dem Sponsor, keine bloße PM-Notiz.

Risiken mit einem schriftlichen Vermerk schließen. Wenn ein Risiko gelöst oder vermieden wurde, dokumentieren, was geschehen ist. Künftige Teams bei ähnlichen Projekten werden diese geschlossenen Einträge nutzen.

Das Register nicht ohne Bereinigung wachsen lassen. Ein Register mit 80 offenen Risiken ist nicht nutzbar. Akzeptierte Risiken schließen, gelöste archivieren und die aktive Liste auf das fokussieren, worauf das Team tatsächlich einwirken kann.

Zur Kennzeichnung des Schweregrads nicht nur Farbe verwenden. Manche Teammitglieder sind farbenblind, und Exporte verlieren oft die Formatierung. Text-Labels (Niedrig, Mittel, Hoch) neben der Farbkodierung verwenden, damit die Information auch bei Formatwechseln erhalten bleibt.

Häufig gestellte Fragen

Was ist der Unterschied zwischen einem Risikoregister und einer Risikobewertung?

Eine Risikobewertung ist der Prozess der Identifizierung und Bewertung von Risiken. Ein Risikoregister ist das Output-Dokument, das die Ergebnisse dieser Bewertung sowie die fortlaufende Verfolgung über die Zeit aufzeichnet. Die Risikobewertung wird durchgeführt, um das Register zu befüllen. Dann wird das Register während des gesamten Projekts gepflegt, um zu überwachen, ob sich das Risikoumfeld verändert.

Wie oft sollte ein Risikoregister aktualisiert werden?

Mindestens einmal wöchentlich im regulären Projektstatusmeeting. Offene Risiken mit hohem Schweregrad benötigen häufig häufigere Prüfungen, besonders in Projektphasen, in denen diese Risiken am wahrscheinlichsten eintreten. Neue Risiken hinzufügen, sobald ein Änderungsantrag, eine neue Abhängigkeit oder ein unerwartetes Ereignis eine Unsicherheit einführt, die das Team bisher nicht verfolgt hatte.

Wer ist für das Risikoregister verantwortlich?

Der Projektmanager ist als Dokumentverantwortlicher für die Aktualität des Registers zuständig. Aber jedes einzelne Risiko hat seinen eigenen namentlich genannten Eigentümer, die Person, die für die Überwachung und Reaktion auf dieses spezifische Risiko verantwortlich ist. Dieser Unterschied ist wichtig: der PM sollte nicht der Standard-Eigentümer für jedes Risiko sein. Die Person, die dem Risiko am nächsten ist, ob das ein technischer Leiter, ein Finanzanalyst oder ein Einkaufsmanager ist, ist üblicherweise der richtige Eigentümer.

Was ist der Unterschied zwischen einem Risikoregister und einem Issue-Log?

Der Zeitpunkt. Ein Risikoregister verfolgt Ereignisse, die noch nicht eingetreten sind. Ein Issue-Log verfolgt Probleme, die bereits eingetreten sind. Wenn ein Risiko sich materialisiert, wechselt es vom Risikoregister in das Issue-Log. Manche Teams kombinieren beides in einem einzigen Dokument, was gut funktioniert, solange der Status klar zwischen prospektiven Risiken und aktiven Issues unterscheidet.

Braucht jedes Projekt ein Risikoregister?

Nicht immer in einem formalen Sinne. Ein zweiwöchiges internes Projekt mit einem kleinen Team kommt mit einer gemeinsamen Notiz oder einem kurzen Risikogesprächs beim Kickoff aus. Aber jedes Projekt mit mehreren Stakeholdern, externen Abhängigkeiten, einem Budget über einem bestimmten Schwellenwert oder regulatorischen Anforderungen sollte ein formales Risikoregister haben. Der Projektauftrag ist ein guter Ort für diese Entscheidung: Wenn das Projekt komplex genug ist, um einen Projektauftrag zu benötigen, ist es komplex genug, um ein Risikoregister zu benötigen.

---

Die besten Risikoregister sind einfach genug, um tatsächlich genutzt zu werden, und detailliert genug, um tatsächlich zu nützen. Mit den neun Spalten oben beginnen, Risiken ehrlich bewerten, echte Eigentümer zuweisen und das Dokument jede Woche überprüfen. Das konsequent tun, und das Register wird zu einem der wertvollsten Gespräche, die das Team während des gesamten Projekts führt.

Weiterführende Artikel

• RAID-Log: Risiken, Annahmen, Issues und Abhängigkeiten
• Projektauftrag: Scope definieren und Stakeholder-Zustimmung sichern
• Projektstrukturplan: So erstellen Sie einen
• RACI-Matrix: Rollen in jedem Projekt klären
• Stakeholder-Analysematrix
• Magisches Dreieck im Projektmanagement