Risiko-Management
Wie man Risiken in Projekten verwaltet
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.
Foto: Rudie - Fotolia.com
Aber ProjekteProjekte 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? Alles zu Projektmanagement auf CIO.de
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.
Foto: Kienbaum Business Consultants
Ein Teil des Problems bilden sicher fehlendes Wissen, Kommunikationsfehler und falsches Verständnis vom ReportingReporting. 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. Alles zu Reporting auf CIO.de
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.