Wie verwaltet man Risiken in Projekten?

Große Lieferverzögerungen, verursacht durch Komplexität und fehlende Kompatibilität von Software im Kabelsalat von Großflugzeugen. Oder der plötzliche Profitabilitätssturz bei Levis wegen Problemen bei dem ERP-Rollout. Vorfälle wie diese haben Vielen vor Augen geführt, wie Projektrisiken viel Schaden anrichten können.

Aber Projekte scheitern auch, ohne dass solche außergewöhnlichen Ereignisse ("Black Swans") auftreten müssen. Eine sichere Sache in einem Projekt ist die, dass ein Projektumfeld Unsicherheit mit sich bringt. Und dass sich ungesteuertes Risiko in Form von verfehltem Leistungsumfang, erhöhten Kosten, Zeitverzögerungen und geringer Qualität auswirken kann. Projekte scheitern nicht etwa deshalb, weil sich das Risiko nicht vollständig beseitigen lässt, sondern weil dieses Risiko nicht richtig gemanagt wird. In der IT-Planning-Studie des Softwareherstellers Alfabet räumen drei Viertel der gefragten CIOs ein, mindestens einmal das Scheitern eines geschäftskritischen Projekts erlebt zu haben. Wenn Risiken sowieso nicht komplett vermeidbar sind, welche Ansätze gibt es dann, um mit dem Risiko richtig umzugehen?

Welches Vorgehen empfiehlt sich zu Projektbeginn?

Zum einen heißt "Risiken managen" auch: "Erwartungen managen". Also sollte das Projekt-Management für das gesamte Projekt ein klares Erwartungsbild schaffen. Auf dieser Basis lassen sich dann die möglichen Risiken analysieren. Genau definiert werden muss die Frage: "Was will das Geschäft mit dem Projekt erreichen?" Dann sollte der Nutzen des Projekts in Form einer wirtschaftlichen Analyse herausgestellt werden. Zuletzt sind die Rahmenbedingungen zu detaillieren, die das Projekt zu einer Notwendigkeit machen und die für den erfolgreichen Ablauf notwendig sind.

Wesentliche Veränderungen in einer dieser drei Perspektiven wirken sich in dem Spannungsfeld Leistungsumfang, Termin, Kosten und Qualität aus und können im Extremfall zu einem Abbruch des Projekts führen. Die Aufgaben des Risiko-Managements bestehen darin, die assoziierten Risiken von Anfang an aufzuzeigen und mögliche Konsequenzen zu bewerten, um unrealistischen Erwartungen vorzubeugen.

Im Projekt sollte das Risiko-Management laufend dessen wirtschaftlichen Nutzen prüfen, um sicherzustellen, dass das Ziel auch erreicht werden kann. Damit stellt sich auch heraus, ob es zum gegenwärtigen Zeitpunkt überhaupt noch sinnvoll ist, das Vorhaben weiterzuführen. Letzteres ist vor allem dann wichtig, wenn sich Rahmenbedingungen geändert haben.

Zum anderen gehört zum Risiko-Management auch, die Risikokultur zu fördern. Wir alle kennen Projekte, an denen man festgehalten hat, weil irgendwann das Projektgeschehen wichtiger wurde als die Ziele. Wir kennen auch Projekte, die rechtzeitig, im Budget und auch in guter Qualität geliefert wurden, aber den Leistungsumfang verfehlten. Die Projektmitarbeiter, insbesondere in IT-Projekten, tendieren dazu, sich Scheuklappen aufzusetzen und nur noch das Projekt und dessen Erreichung zu sehen.

Ein Teil des Problems bilden sicher fehlendes Wissen, Kommunikationsfehler und falsches Verständnis vom Reporting. Außerdem sollte man sich immer des Faktors Mensch bewusst sein: Das Projektteam und das Management können einer selektiven Wahrnehmung anheimfallen - möglicherweise, um kognitive Dissonanzen zu vermeiden. Damit besteht das Risiko, dass widersprüchliche Informationen zu einer bereits gefällten Entscheidung oder einer Situationseinschätzung so lange ignoriert werden, bis die Handlungsoptionen hinsichtlich einer Korrektur extrem eingeschränkt oder aber kostenintensiv sind.

Ein Projekteiter muss sich bewusst sein, dass trotz aller Standards die jeweilige Kultur eine bedeutsame Rolle spielt: Um ein Projekt abzubrechen, muss die Unternehmenskultur dafür bereit sein. Der Abbruch eines Projekts oder eine grundlegende Veränderung des Scope dürfen kein Tabu sein.

Wie erkennt man Risiken und wie selektiert man sie?

Zur Identifikation von Risiken haben sich Workshops bewährt, in denen mit Hilfe einer Checkliste die Risiken und Ursachen beschrieben werden. Die Teilnehmer des Workshops sollten aus den betroffenen Fachbereichen und aus der IT kommen. Sie müssen ihre Sichtweisen offen schildern können. Anschließend lassen sich die Risiken dann, soweit möglich, nach Eintrittswahrscheinlichkeit, Eintrittszeitpunkt und Schadensausmaß quantitativ, also monetär und zeitlich, bewerten.

Das Ergebnis des Workshops lässt sich in einem "Risikoradar" veranschaulichen:

Nach der Identifikation und Bewertung der Risiken sind Maßnahmen zum Umgang damit abzuleiten. Vier Risikostrategien stehen dabei zur Verfügung:

• Akzeptieren,

• Vermindern,

• Übertragen (zum Beispiel an den Auftraggeber, durch den Abschluss einer geeigneten Versicherung oder an einen besser aufgestellten Lieferanten) und

• Vermeiden.

Letztendlich sollten die Auswirkung nach Einsatz der Maßnahmen bewertet werden, um gegebenenfalls die Bedingungen eines Projektabbruchs oder einer Veränderung des Scope festzulegen.

Im letzten Schritt gilt es, Stresstest-Szenarien durchzugehen. Im Anschluss an die Ableitung einer geeigneten Risikostrategie sollten im Anschluss auch extreme Stresstests durchgegangen werden. So lassen sich sogar für die Black Swans wirksame Handlungsoptionen finden. Wie bereits angedeutet, bezeichnet dieser Begriff Katastrophen erheblichen Ausmaßes mit nicht planbarem Charakter. Klassische Fragen für diese Stresstests sind die folgenden:

• Was, wenn das Projektbudget um 200 Prozent überschritten wird?

• Was, wenn unser Projekt-Sponsor das Unternehmen verlässt?

• Was, wenn das Projekt zwei Jahre länger dauert als geplant?

• Was, wenn ein kritischer Lieferant vom Markt verschwindet?

Diese kreative Übung sollte regelmäßig durchlaufen werden. Sie ist quasi eine der Kernaufgaben des Projekt-Managers - auf jeden Fall immer beim Erreichen wichtiger Meilensteine.

Wie minimiert man die Risiken in Projekten?

Nun zur geeigneten Risikostrategie. Hinsichtlich der vier Optionen sind folgende Überlegungen anzustellen:

Akzeptieren: Wird ein Risiko akzeptiert, so ist diese Entscheidung durch die Risikokultur des Unternehmens beeinflusst, und sie sollte genau begründet werden.

Vermindern: Hier sind vier verschiedene Kategorien zu betrachten.

• Das Umfeld: Welche Signale sind ständig zu beobachten, damit eine nicht beeinflussbare Veränderung frühzeitig erkannt wird?

• Auftrag und Erwartungen: Welche Interessen hat der Auftraggeber oder Kunde, und welche laufende Kommunikation muss aufgesetzt werden, um Veränderungen in der Erwartungshaltung zu beeinflussen?

• Das Projekt-Management: Wird im Projekt kontinzierlich und proaktiv auf mögliche Risiken und mögliche Korrekturmaßnahmen hingewiesen?

• Die Leute: Sind die richtigen Mitarbeiter am Projekt beteiligt? Haben sie die erforderlichen Kompetenzen? Stehen Sie dem Projekt mit ausreichender Zeit zur Verfügung?

Übertragen: Ein Risiko kann nie vollständig auf einen Dienstleister übertragen werden. Deswegen ist ausreichend Zeit auf die Ausgestaltung des Vertrags zu verwenden. Neben der zu erbringenden Leistung und der erwarteten Qualität sollten auch die genaue Ausgestaltung des Projekt-Managements, die Gremien, das Reporting und die Nutzungsrechte am Ergebnis beschrieben werden.

Ebenso besteht die Möglichkeit, den Vertragsnehmer über eine Bonus-Malus-Regelung zu motivieren. Das ist sowohl im Dienstleistungsvertrag, als auch im Werkvertrag möglich. Dabei sollte eine überdurchschnittliche Leistung den Wegfall von fakturierbaren Tagen für den Zulieferer substanziell kompensieren.

Vermeiden: Damit etwas bewusst nicht oder jedenfalls anders umgesetzt wird, spielt die Risikokultur eine wichtige Rolle. Die Unternehmenskultur beeinflusst auch die Projektkultur und darüber das individuelle Risikoverhalten im Projekt. Gestaltungsmöglichkeiten gibt es hier durch die Ausgestaltung der individuellen Zielvereinbarung, wo beispielsweise risikoreiches Verhalten gerade nicht belohnt werden sollte.

Das richtige Team auswählen

Bereits bei der Zusammenstellung des Projektteams lasen sich Risiken minimieren. Das geschieht dadurch, dass unterschiedliche Persönlichkeitsprofile im Team sind. Im Idealfall enthält ein Team die folgenden:

• Der Genaue achtet auf Details, arbeitet gewissenhaft, analytisch und ausdauernd.

• Der Survivor hat das Ziel immer im Blick. Auch durch Rückschläge wird er nicht davon abgebracht. In schwierigen Situationen weiß er das Team zu motivieren und schnelle Entscheidungen zu treffen.

• Der Kreative vermittelt andere Sichtweisen auf Probleme und neuen Lösungen.

• Der Vernetzer kennt die Ansprechpartner im Unternehmen und ist geübt in der projektentscheidenden Kommunikation.

• Der Objektive kann das Kernteam ergänzen und zur Qualitätssicherung beitragen. Er sollte aber nicht behindernd wirken, wie es den Projektauditoren nachgesagt wird. Vielmehr übernimmt er die Rolle eines Coaches, der Sachverhalte hinterfragt und zugleich motivierend wirkt. Dazu braucht er sowohl großes Fach-Knowhow als auch Methodenwissen.

Laufend Tansparenz verschaffen

Während des Projekts ist die Transparenz im Controlling wichtig. Sie wird durch realistisches Reporting geschaffen. Das Steering Board muss mitbekommen, wenn mit dem Projekt etwas im Argen liegt. Die Darstellung des Status durch eine grüne Ampel oder Gantt-Diagramme hat sich vielfach als nicht ausreichend herausgestellt.

Der Projektleiter sollte sich genau überlegen, welche Informationen er benötigt, um klar zu sehen, wie es um kritische Projektlieferungen steht und welche Information an den Auftraggeber kommuniziert wird. Aufgabenpakete sollten dabei funktional abgegrenzt werden und in einem überschaubaren Zeithorizont zu bearbeiten sein. Dieses Vorgehen reduziert die Komplexität und führt zu einem transparenten Reporting über den Fortschritt.

Agile Methoden einführen

Um Risiken im Bereich der Produktqualität zu verringern, ist es in diesem Zusammenhang vor allem nötig, die Nutzer oder deren Vertreter rechtzeitig einzubinden. Dabei sollte das Anwender-Okay Teil des Reporting sein. Dadurch können eventuelle Fehlentwicklungen rechtzeitig erkannt und Änderungen zeitnah eingeleitet werden.

Den Projektbeteiligten sollte ein regelmäßiges Kommunikationsforum gegeben werden, über das sie kritische Informationen austauschen können. Die Wahrnehmung von Fortschritt und Hindernissen sind dabei auch ein wichtiger Faktor.

Wir konnten in unseren Projekten gute Erfahrungen mit der Nutzung agiler Methoden sammeln. Es lassen sich aber durchaus auch nur Teile davon verwenden, beispielsweise eine regelmäßige kurze, morgendliche Abstimmung, die sich am Vorbild des "Daily Scrum" orientiert. (qua/sh)