Risiko-Management

Wie man Risiken in Projekten verwaltet

03.03.2017 von Frédéric Cuny, Gilbert Riegel und Jan-Peter Schütt
Ein Projekt ist an sich schon ein Risiko. Wenn sich also Projektrisiken nicht komplett vermeiden lassen, wie lassen sie sich dann wenigstens in Griff bekommen?

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.

Zeit, Qualität und Geld spielen gleichermaßen eine Rolle, wenn es ums Risiko-Management innerhalb von Projekten geht.
Foto: Rudie - Fotolia.com

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.

Die Checkliste für den Workshop.
Foto: Kienbaum Business Consultants

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.

Gescheiterte, gestoppte oder in Schieflage befindliche IT-Projekte
Wenn IT-Projekte scheitern, liegt es an den Menschen: Dienstleister versprechen zu viel und überfrachten das Vorhaben, Kunden wollen billig einkaufen, Projektverantwortliche sind intern schlecht informiert oder werden boykottiert. Und manches Projekt war schlicht eine Schnapsidee.
1. Schufa-Zentrale in Wiesbaden: Widerstand gegen Facebook-Pläne
Mutig hatte die Wirtschaftsauskunft Schufa (“Wir schaffen Vertrauen”) angekündigt, soziale Netzwerke wie Facebook auf nutzbare Informationen für die Durchleuchtung von Verbrauchern zu scannen. Es handelte sich um ein Forschungsprojekt in Zusammenarbeit mit dem Hasso-Plattner Institut. Die Idee löste im vergangenen Jahr eine Welle der Empörung aus, Verbraucherschutzministerin Aigner sagte, die Schufa dürfe nicht zum Big Brother des Wirtschaftslebens werden. Die Schufa stoppte den Plan. Die Rechtslage auf diesem Gebiet ist uneindeutig, es gibt Experten, die eine solch zweckfremde Nutzung von Facebook-Postings schlicht für illegal halten. Vielleicht hätte die Schufa vorher entsprechenden Rat einholen sollen...
5. Keine Gesichtserkennung beim KSC
Ein weiteres Beispiel für missratene Kommunikation bietet ein Feldversuch in Karlsruhe. Der Fussballclub KSC wollte mit Hilfe des Karlsruher Instituts für Technologie (KIT) bei drei Heimspielen ein neues Verfahren zur Gesichtserkennung testen. Ziel war es, Testpersonen in einer Menschenmenge durch Kameras automatisch zu identifizieren. Zuschauer fanden die Idee ebenso wenig brilliant wie der Landesdatenschützer Jörg Klingbeil. Der sagte: “Wir haben als Bürger das Recht, unbeobachtet zu sein.” Die Projektpartner hatten vor allem den Fehler gemacht, nicht im Vorfeld über Hintergründe und Details des Projekts detailliert zu informieren.
6. Massive Akzeptanzprobleme bei Funktechnologie NFC
Banken vor allem in Deutschland wünschen sich seit Jahren, dass wir alle häufiger bargeldlos bezahlen. Dazu braucht es vor allem Vertrauen. Die von der Finanzbranche gelobt Funktechnik NFC (Nearfield Communication) ist dem allerdings wenig zuträglich. Thilo Weichert, Datenschutzbeauftragter von Schleswig-Holstein, lässt an den bereits verbreiteten, NFC-fähigen Plastikkarten kein gutes Haar: “Es werden Karten ausgegeben, die problematisch und nicht im Ansatz zukunftssicher sind.” Nach Auskunft von Datenschützern ist es möglich, die Daten der letzten 15 Abbuchungs- und Rückbuchungstransaktionen mit Datum, Zeit, Händlerkartennummer, gezahltem Betrag und vieles andere ganz einfach auszulesen. Ob das die Kunden jemals akzeptieren?
7. Kalifornien: Keine Personalverwaltung durch SAP
Der US-Bundesstaat legte im Februar diesen Jahres sein Kooperation mit SAP auf Eis. Mit dem Projekt sollte die Personalverwaltung für alle festen und freien Mitarbeiter des Staates erneuert werden. Nachdem 254 Millinen Dollar verbrannt waren, trat Kaliforniens Finanzchef John Chiang mit beiden Beinen auf die Bremse. Es habe noch keinen einzigen fehlerfreien Abrechnungslauf gegeben. Chiang bezweifelte in einem Statement, dass das SAP-System die erforderlichen Datenmengen würde bewältigen können. Kalifornien prüft rechtliche Schritte gegen SAP, und für die Personalabrechnung will man zum Legacy-System zurückkehren. “Das ist zwar alt – aber es funktioniert”, so John Chiang.
8. Elena: nicht zuende gedacht
Ursprünglich als JobCard gestartet, sollte das elektronische Entgeltnachweis-Verfahren der Agentur für Arbeit und weiteren Stellen Arbeitnehmerdaten mithilfe von Chipkarte und elektronischer Signatur zur Verfügung stellen. Zunächst wurde die Einführung verschoben, im Sommer 2011 beerdigten die beteiligten Ministerien schließlich die Idee. Begründung: Die flächende Verbreitung von Signaturkarten werden aus Datenschutzgründen noch Jahre auf sich warten lassen.
9. DaZu: Politik der offenen Hände
Anfang Februar 2013 stoppte das Bild (Bafu) das IT-Projekt 'Datenzugang für Umweltdaten'. Die Berner Zeitung berichtete, das Projekt hätte “in den Bereichen Projektführung und Projektmanagement gravierende Mängel” aufgewiesen. Die Zeitung zitierte aus einem vertraulichen Bericht, demzufolge mindestens 14 Firmen an dem Projekt verdient hatten, von denen 13 “direkt oder zumindest indirekt nachweisbar in Geschäftsbeziehungen mit dem Projektleiter” standen.
10. Insieme: Nach sieben Jahren bei zehn Prozent
Auch kein Musterbeispiel für schweizer Gründlichkeit war das IT-Großprojekt INSIEME ('gemeinsam'), mit der die Steuerverwaltung ihre alten Informatiksysteme zusammenführen und erneuern wollte. Nachdem Ende September 2012 nach siehen Jahren lediglich zehn Prozent der notwendigen Programmierarbeiten abgeschlossen waren, dafür aber sowohl der Zeit- als auch der Budgetrahmen gesprengt war, zog das Eidgenössische Finanzdepartement die Notbremse. Eine Weiterführung des Projekts wurde “aufgrund der heute vorliegenden Erkenntnisse und Fakten als zu risikobehaftet” beurteilt. Gekostet hatte der Versuch 124 Millionen Euro an Steuergeldern.

Wie erkennt man Risiken und wie selektiert man sie?

Die Wahrscheinlichkeit der Risiken wächst von der Peripherie zum Zentrum. Die Symbole bezeichnen das Ausmaß des Schadens im Risikofall.
Foto: Kienbaum Business Consultants

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:

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:

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.

Ü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:

Laufend Tansparenz verschaffen

Wichtig ist, dass das Team richtig zusammengestellt ist.
Foto: Syda Productions - Fotolia.com

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.