Flussdiagramm Projektrisikomanagement: erfassen bis abschließen
Flussdiagramm für das Projektrisikomanagement: Risiko erfassen, Wahrscheinlichkeit und Auswirkung bewerten, eskalieren, eine Reaktion wählen, überprüfen und abschließen oder als Issue weiterführen.
Was ist flussdiagramm projektrisikomanagement: erfassen bis abschließen?
Die meisten Projektrisikoregister werden einmal geschrieben und nie gelesen. Sie entstehen in einem Workshop zum Projektstart, werden bewertet und abgestimmt, und erst dann wieder geöffnet, wenn jemand vor dem nächsten Lenkungsausschuss eine Folie braucht. Zu diesem Zeitpunkt beschreibt die Hälfte der Einträge eine Phase, die längst abgeschlossen ist, und das Risiko, das dem Projekt tatsächlich geschadet hat, stand nie darin. Was ein Projektrisikomanagement funktionieren lässt, ist nicht die Bewertungsmethode. Es ist die Schleife: Jedes offene Risiko kommt in einem festen Takt zurück und verändert sich, tritt ein oder wird geschlossen.
Diese Seite zeigt den Zyklus auf Projektebene, gezeichnet über fünf Bahnen und fünf Phasen. Sie ist nicht die organisationsweite Methode der Risikobeurteilung: Kriterien, die Skalen für Eintrittswahrscheinlichkeit und Auswirkung, Brutto- und Restbewertung sowie die Wirksamkeit bestehender Maßnahmen gehören in das Flussdiagramm zur Risikobeurteilung unter /de/templates/risikobeurteilung-prozess, und dieses Diagramm setzt jene Skalen voraus und wendet sie schlicht an. Sie ist auch keine Prüfung, wohin ein einzelnes Risiko gehört: Welches Gremium ein bestimmtes Risiko tragen soll, arbeitet ein Entscheidungsbaum zur Risikoeskalation weit ausführlicher durch als die eine Schwellenentscheidung hier, und wer das Tragen eines Risikos zeichnen darf, klärt der Entscheidungsbaum zur Risikoakzeptanz unter /de/templates/risikoakzeptanz-entscheidung. Das Diagramm endet außerdem in dem Moment, in dem ein Risiko real wird: Von dort übernimmt das Issue-Log, und laufende Störungen gehen in den Incident-Management-Prozess unter /de/templates/incident-management-prozess.
Zwei Dinge, die die meisten Risikoverfahren im Projekt stillschweigend voraussetzen, sind hier ausdrücklich gezeichnet. Die Eskalationsschwelle ist eine Entscheidung, die die Projektleitung vor der Wahl der Reaktion beantwortet und nicht erst, nachdem die Maßnahme kalkuliert wurde. So erreichen schwere Risiken den Lenkungsausschuss, solange dort noch ein Mandat und ein Budget zu holen sind. Und „Risiko eingetreten?“ ist eine echte Verzweigung: Ein eingetretenes Risiko ist kein Risiko mehr, also wird es als Projekt-Issue eröffnet und der Registereintrag als eingetreten geschlossen, statt Monat für Monat neu bewertet zu werden. Alles zwischen Reaktion und Abschluss ist eine Schleife: „Risiko weiterhin aktuell?“ schickt offene Risiken zurück in die nächste Bewertung, und nur ein Risiko, dessen Zeitfenster vorbei ist, erreicht den Abschluss und die Lesson, die in die nächste Identifikationsrunde einfließt.
Was dieses Flussdiagramm abdeckt
In dieser Vorlage
- Fünf Swimlanes (Projektteam, Risikoeigner, Projektleitung, Lenkungsausschuss und PMO) über fünf Phasen: Identifikation, Bewertung, Reaktion, Überwachung und Abschluss.
- Identifikation aus jeder Quelle in ein einziges Register: Das Risiko wird im Projekt erkannt, mit Ursache und Wirkung im Risikoregister erfasst, und ein benannter Risikoeigner übernimmt die Risikoverantwortung, bevor überhaupt bewertet wird.
- „Über der Eskalationsschwelle?“, beantwortet von der Projektleitung. Darüber führt zum Lenkungsausschuss, der das eskalierte Risiko prüft und Mandat und Budget für die Reaktion freigibt; Darunter geht direkt in die Reaktionsplanung.
- Eine vierfache Entscheidung „Welche Reaktionsstrategie?“ (Vermeiden, Vermindern, Übertragen, Akzeptieren), bei der Vermeiden, Vermindern und Übertragen in „Maßnahmen, Verantwortliche und Termine festlegen“ zusammenlaufen, während Akzeptieren direkt in die Überwachung geht, wo nichts bleibt außer zu beobachten.
- Die Überwachungsschleife: „Risiko bei jeder Überprüfung neu bewerten“ führt zu „Risiko eingetreten?“ und danach zu „Risiko weiterhin aktuell?“, dessen Zweig Aktuell das Risiko in die nächste Überprüfung zurückschickt statt aus dem Prozess hinaus.
- Zwei Endpunkte statt einem. Ein eingetretenes Risiko wird als Projekt-Issue eröffnet und verlässt den Prozess bei „Weiterführung im Issue-Log“; ein Risiko, dessen Zeitfenster vorbei ist, wird vom PMO im Register geschlossen und endet bei „Risiko geschlossen, Lessons Learned erfasst“.
Wann Sie diese Vorlage verwenden sollten
- Sie schreiben das Risikokapitel eines Projektmanagementplans und brauchen ein Bild davon, wer identifiziert, wer verantwortet, wer eskaliert und wer abschließt.
- In Ihrem Register stehen Einträge, die sich seit Monaten nicht bewegt haben, und Sie wollen die Überprüfungsschleife und die Abschlussprüfung im Prozess verankert sehen statt bei dem, der zufällig die Gremienunterlage vorbereitet.
- Risiken und Issues laufen in derselben Liste, und Sie wollen den Übergangspunkt und die Übergabe an das Issue-Log gezeichnet haben statt vorausgesetzt.
- Der Lenkungsausschuss bekommt Risiken regelmäßig zu spät, um noch etwas ändern zu können, und die Eskalationsentscheidung soll vor die Reaktionsplanung rücken statt dahinter.
- Sie schulen Projektleitungen oder Teilprojektleitungen und wollen Verantwortung, Eskalationsschwelle und die vier Reaktionsstrategien aus einem einzigen Diagramm vermitteln.
So funktioniert es
Benennen Sie die Bahnen nach Ihrer Projektgovernance
Ersetzen Sie Projektteam, Risikoeigner, Projektleitung, Lenkungsausschuss und PMO durch die Rollen und Gremien, die es bei Ihnen wirklich gibt. Halten Sie den Risikoeigner von der Projektleitung getrennt: Der eine trägt das Risiko, die andere führt den Prozess. Gibt es kein PMO, führen Sie diese Bahn mit der Projektleitung zusammen, statt ein Gremium im Diagramm stehen zu lassen, das nie etwas tut, und wenn Lenkungsausschuss und Auftraggeber dieselbe Person sind, schreiben Sie das hin.
Schreiben Sie die Eskalationsschwelle als Zahlen
„Über der Eskalationsschwelle?“ bleibt wirkungslos, solange keine Zahlen daran hängen. Die meisten Projekte setzen einen Kostenwert, der an das delegierte Budget der Projektleitung gekoppelt ist, und einen Terminwert, der an Puffer oder einen vertraglichen Meilenstein gebunden ist, und behandeln den zuerst gerissenen Wert als Auslöser. Ergänzen Sie einen Weg, der die Bewertung vollständig ignoriert, wenn es um Arbeitssicherheit, Recht, Regulierung oder Reputation geht. Diese Risiken eskalieren aufgrund ihrer Natur, nicht aufgrund ihrer Punktzahl.
Legen Sie die Pflichtfelder des Registers fest
Entscheiden Sie, was „Risiko im Risikoregister erfassen“ enthalten muss: Ursache, Ereignis und Wirkung als getrennte Felder, Meldedatum, vorgesehener Risikoeigner, betroffenes Arbeitspaket oder betroffener Meilenstein, Wahrscheinlichkeit und Auswirkung mit dem Datum der Bewertung, die gewählte Reaktion, die Maßnahmen mit Terminen und der aktuelle Status. Was optional bleibt, ist binnen eines Monats leer, und ein in drei Worten notiertes Risiko kann niemand neu bewerten, der nicht im Raum war.
Fixieren Sie den Überprüfungstakt und die Sonderauslöser
Die Schleife dreht sich nur, wenn es eine geplante Überprüfung gibt. Koppeln Sie sie an den bestehenden Berichtsrhythmus des Projekts, statt einen neuen Termin zu erfinden, prüfen Sie höher bewertete Risiken häufiger als die übrigen, und benennen Sie die Ereignisse, die eine Neubewertung vorziehen: ein Lieferantenwechsel, ein gerissener Meilenstein, eine neue Abhängigkeit, eine Änderung des Umfangs, ein Vorfall oder eine verspätete Maßnahme. Ein Register, das nur vor der Gremiensitzung angefasst wird, ist einen Tag im Monat zutreffend.
Machen Sie die Maßnahmen verbindlich
„Maßnahmen, Verantwortliche und Termine festlegen“ heißt: eine benannte Person je Maßnahme, ein Fälligkeitsdatum und eine Zeile im Projektplan, in der der Aufwand steht. Maßnahmen, die nur im Risikoregister leben, konkurrieren mit der Arbeit, an der alle gemessen werden, und verlieren. Führen Sie sie dort, wo das Team ohnehin hinsieht, und lassen Sie den Risikoeigner in der Überprüfung den Fortschritt berichten statt nur zu melden, dass sich am Risiko nichts geändert hat.
Vereinbaren Sie die Regel vom Risiko zum Issue und veröffentlichen Sie eine Fassung
Definieren Sie, was als eingetreten gilt, wer das ohne Wartezeit auf eine Sitzung erklären darf und wie der Querverweis in beide Richtungen mitgeführt wird, damit die Historie den Wechsel überlebt. Gehen Sie das fertige Diagramm danach mit der Projektleitung, einem Risikoeigner und der Person durch, die den Lenkungsausschuss leitet, korrigieren Sie es auf das, was diese tatsächlich tun, und veröffentlichen Sie diese Fassung unter Beibehaltung der älteren, damit später erkennbar ist, welche Version jemand vor sich hat.
Häufig gestellte Fragen
Welche Schritte umfasst das Risikomanagement im Projekt?
Risiko erkennen, mit Ursache und Wirkung im Register erfassen, von einem benannten Risikoeigner die Verantwortung übernehmen lassen, Wahrscheinlichkeit und Auswirkung bewerten, prüfen, ob die Eskalationsschwelle gerissen ist, eine Reaktion aus Vermeiden, Vermindern, Übertragen und Akzeptieren wählen, Maßnahmen mit Verantwortlichen und Terminen festlegen, das Risiko bei jeder Überprüfung neu bewerten, es beim Eintreten in ein Issue überführen und es schließen, sobald sein Zeitfenster vorbei ist. Die Methoden nutzen unterschiedliche Begriffe für dasselbe Grundgerüst: PRINCE2 beschreibt ein Risikomanagementverfahren von Identifizieren und Bewerten über Planen und Umsetzen der Reaktionen, mit Kommunikation als Querschnitt, und die früheren prozessorientierten Ausgaben des PMBOK Guide trennten das Planen einer Reaktion von deren Umsetzung und Überwachung. In der Praxis scheitert selten die Liste. Es scheitert der Rücksprung in die Neubewertung.
Was ist der Unterschied zwischen einem Risiko und einem Issue?
Ein Risiko ist ungewiss: Es kann eintreten oder nicht, wird deshalb als Ursache, Ereignis und Wirkung beschrieben und trägt eine Eintrittswahrscheinlichkeit. Ein Issue ist bereits eingetreten oder nunmehr sicher. Beide werden unterschiedlich gesteuert, und genau deshalb lohnt es sich, die Trennung durchzusetzen. Ein Risiko bekommt vor dem Ereignis eine Reaktionsstrategie und Maßnahmen; ein Issue bekommt Eindämmung, einen Wiederherstellungsplan und häufig einen Änderungsantrag für die Zeit oder das Geld, das es verbraucht. Beides in einer Liste zu führen füllt das Register mit Dingen, die sich nicht mehr mindern lassen, und begräbt die wirklich ungewissen Einträge. In diesem Diagramm ist der Wechsel eine ausdrückliche Verzweigung: „Risiko eingetreten?“ eröffnet ein Projekt-Issue, der Registereintrag wird als eingetreten geschlossen, und der Querverweis wird in beide Richtungen mitgeführt.
Welche vier Reaktionsstrategien für Risiken gibt es?
Vermeiden, vermindern, übertragen und akzeptieren. Vermeiden beseitigt die Ursache, meist durch eine Änderung von Umfang, Reihenfolge oder Vorgehen, und ist die einzige Option, die das Risiko vom Register nimmt statt es nur zu verkleinern. Vermindern senkt Wahrscheinlichkeit, Auswirkung oder beides und ist der Ort, an dem die meisten Maßnahmen landen. Übertragen verschiebt die Folge über einen Festpreisvertrag, eine Haftungsklausel oder eine Versicherung auf eine andere Partei und wird am häufigsten überschätzt: Verschoben wird in der Regel die finanzielle Folge, die Lieferfolge bleibt beim Projekt. Akzeptieren heißt, das Risiko bewusst zu tragen: mit benanntem Genehmigenden, einer Reserve und einem Überprüfungstermin; ein Risiko, für das niemand Budget hinterlegt hat, ist kein akzeptiertes Risiko. Behandelt Ihre Methode Chancen als positives Risiko, gibt es die Spiegelbilder: nutzen, verstärken, teilen und akzeptieren.
Wer sollte ein Risiko im Projekt verantworten?
Eine benannte Person, nah genug an der Ursache, um Veränderungen zu bemerken, und weit genug oben, um etwas tun zu können. In der Praxis ist das meist eine Teilprojekt-, Fach- oder Lieferantenverantwortung und nicht die Projektleitung, die den Prozess verantwortet und nicht jeden einzelnen Eintrag. Zwei Muster verursachen den größten Teil der Probleme: die Zuordnung an ein Team oder eine Abteilung, wo niemand neu bewertet, weil niemand konkret gefragt wurde, und jedes Risiko bei der Projektleitung, was das Register in eine persönliche Aufgabenliste verwandelt, die irgendwann nicht mehr bewertet wird. Dieses Diagramm macht „Risikoverantwortung übernehmen“ deshalb zu einem eigenen Schritt vor der Bewertung, denn ein Eigner, der nie zugestimmt hat, einer zu sein, erscheint nicht zur Überprüfung.
Worin unterscheidet sich das von einem Flussdiagramm zur Risikobeurteilung?
Die beiden decken unterschiedliches Gelände ab. Ein Flussdiagramm zur Risikobeurteilung ist die Methode: wie Kriterien und Skalen abgestimmt werden, wie Risiken beschrieben werden, wie Brutto- und Restbewertung entstehen, wie die Wirksamkeit bestehender Maßnahmen beurteilt wird und wie eine Behandlung gewählt wird. Es wird einmal geschrieben und gilt organisationsweit. Diese Seite ist der Betriebszyklus auf Projektebene, der jene Skalen verbraucht (erkennen, erfassen, verantworten, bewerten, eskalieren, reagieren, handeln, überprüfen, überführen oder schließen) über die Laufzeit eines Projekts, mit Lenkungsausschuss, PMO und Issue-Log darin. Wenn Sie festlegen, wie Risiken bewertet werden, nehmen Sie die Vorlage für die Risikobeurteilung. Wenn Sie festlegen, wie Ihr Projekt sein Register Woche für Woche führt, nehmen Sie diese.