In komplexen Projekten kann viel schief gehen. Schlimmer noch: Frei nach Murphys Gesetz geht häufig (fast) alles schief, was schief gehen kann. Umso wichtiger ist es, Projektrisiken AKTIV zu identifizieren, zu bewerten und systematisch zu bearbeiten.
Der aktuelle Newsletter des „Risk Doctor“ Dr. David Hillson hat mich dazu inspiriert, mal einen einfachen Risikoprozess zu skizzieren. Hier das Ergebnis:
Gutes Risikomanagement ist – gleich wie gutes Projektmanagement – kommunikationsgetrieben und pragmatisch. Damit ist gemeint, dass die einzelnen Schritte getragen sein sollten von einer intensiven Kommunikation und Diskussion im Team.
Übrigens: Auch intuitive Risikobewertungen durch die Beteiligten sollten zulässig und sogar erwünscht sein! Hierzu eine kurze Geschichte:
Neulich hatte ich die Gelegenheit, das Projektmanagement bei den Bregenzer Festspielen im Rahmen einer Führung vorgestellt zu bekommen. Wie man sich vorstellen kann, sind derartige Großveranstaltungen in der Planung und Organisation höchst anspruchsvoll – und auch riskant. Der technische Projektleiter beschrieb den Umgang mit Risiken (sinngemäß) folgendermaßen: „Ich möchte, dass sich das schlechte Bauchgefühl auf das gesamte Team verteilt. Alle Beteiligten sind mitverantwortlich, Risiken zu erkennen, zu spüren, aktiv zu kommunizieren und zu bekämpfen.“
Diese Beschreibung hat mir ausgezeichnet gefallen – denn genau darum geht es. Es ist eine Illusion, dass ein/e Projektleiter/in alle Risiken wahrnehmen kann. Vielmehr liegt das Wissen und die Erfahrung im Umgang mit diversen Projektrisiken bei den einzelnen Teammitgliedern. Ziel muss es also sein, die Verantwortung für das Risikomanagement ein Stück weit auf alle Beteiligten zu verlagern. Nur so können komplexe Projekte gelingen.
Zurück zum Risikoprozess. Der Umgang mit Risiken verfolgt eine gewisse Logik, die in der obigen Darstellung hoffentlich ersichtlich wird. Gleichzeitig ist das Risikomanagement ein kontinuierlicher Prozess, welcher sich über das gesamte Projekt erstreckt. In diesem Sinne – happy risk management 😉
Schöne Einführung. Ich würde in der Abbildung die Aktivitäten 7. Lessons Learned und 2. Risiken identifizieren noch miteinander verbinden. Damit würde zum einen ausgedrückt, dass Risiko Management eine kontinuierliche Aktivität ist und zum anderen, würde dies einen sich ständig optimierenden Plan – Do – Check – Act (PDCA) Zyklus realisieren.
@Jens: Vielen Dank für den Hinweis – hab’s korrigiert.
Grüße nach Hamburg!
“Ich möchte, dass sich das schlechte Bauchgefühl auf das gesamte Team verteilt. Alle Beteiligten sind mitverantwortlich, Risiken zu erkennen, zu spüren, aktiv zu kommunizieren und zu bekämpfen.”
Dieser Satz ist SUPER. genau das ist es. RM betrifft immer alle und baut sehr stark auf dem Bauchgefühl auf, das alle Beteiligten haben. Zum Glück sind diese Bauchgefühle nicht bei allen gleich, was uns zu dem Punkt bringt, dass gutes RM eine intensive Kommunikation über Risiken voraussetzt. Also auch einen Projektleiter, der diesem Thema Platz einräumt.
Die Grafik finde ich gut, nur der Zeitpunkt für RM, sofort nach der Zieldefinition finde ich nicht gut. Man kann so früh (und für mich steht die Zieldefinition relativ am Anfang eines Projekts) sicherlich auch Risiken identifizieren (ich bezeichne diese immer als „existenzielle Risiken“, weil zu Beginn eher grundlegende Risiken kommen). Mir fehlen allerdings die Durchführungsrisiken, die ich erst dann sinnvoll ermitteln kann, wenn die Durchführung einmal komplett durchgeplant ist. Dann kann ich sagen, welche Risiken in der geplanten Umsetzung liegen und diese noch einmal im Sinne des Risikomanagements adaptieren. Das hat zusätzlich den Nebeneffekt, dass gegen Ende der Planung noch einmal eine Kontrollrunde über die gesamte Planung gemacht wird.
Hallo Hagen,
interessante und informative Grafik. Drei Dinge sind mir dabei aufgefallen:
* Lessons Learned ist für mich eine einmaliger Akt am Ende eines Projektes, und nicht Teil des RM-Zykluses. Es sollte daher von 6 (Risikokontrolle) wieder zu 2 (Risiken identifizieren) gehen, und 7 (Lessons Learned) dann am rechten Ende stehen.
* Mir fehlt eine Runde RM vor Projektstart. Zum Zeitpunkt der Projektdefinition und der Budgetschätzung müssen die dann bekannten Risken identifiziert, bewertet und Maßnahmen geplant werden. Diese Maßnahmen werden natürlich erst im Projekt durchgeführt, müssen aber in der Projekt-Budgetplanung berücksichtigt werden.
* Unter dem Punkt 5 (Risikomanagement durchführen) sind mögliche Maßnahmen aufgeführt, die aber eigentlich zu 4 (Maßnahmenplanung) gehören.Hier könnte man auch präventive und korrektive Maßnahmen differenzieren. Im Punkt 5 sollte meines Erachtens nur die Durchführung der präventiven Maßnahmen als normale Arbeitspakete im Projekt enthalten sein.
@Achim: Risikomanagement sollte im Projekt ein zyklisch wiederholter Prozess sein, und ich denke, das will die Grafik auch vermitteln.
@Achim: Danke für das Feedback und den Input.
Natürlich kann eine Grafik nie alle Aspekte im Detail wiedergeben. Ich verstehe RM natürlich als kontinuierlichen Prozess, der sich über das gesamte Projekt erstreckt – sprich von der Initiierung/Definition bis zum Projektabschluss. Entsprechend wird RM natürlich auch während der Durchführung eines Projekts praktiziert, wodurch nach meinem Verständnis in diesem Prozess auch die Durchführungsrisiken enthalten sind.
Es stimmt aber, dass diese Darstellung den Schluss zulässt, dass RM ein in sich abgeschlossener Prozess am Beginn eines Projekts darstellt. Dies möchte die Grafik aber nicht vermitteln.
@Gustavo: Auch Ihnen danke für den Input. Die Sache mit den LL schaue ich mir nochmals an. Ich denke, LL können und sollen durchaus auch während der einzelnen Abwicklungsphasen eines Projekts diskutiert werden. Denn Learnings sollten ja hoffentlich auch während des Projekts schon in die weitere Bearbeitung einfließen.
Wie gesagt: Die Prozessdarstellung kann derzeit nicht vermitteln, dass diese RM Schritte durchaus auch VOR der offiziellen Projektfreigabe/-beauftragung durchgeführt werden.
LG, Stefan
das rm ein zyklischer prozess ist, war mir schon klar. trotzdem danke für die hinweise.