Foto: Fotolia/Uwe Ohse
Woran denken Sie beim Begriff "Schwarzer Schwan"? An einen idyllischen Teich? Die Oscar-prämierte Leistung der Schauspielerin Natalie Portman? Oder an die Wuppertaler Dichterin Else Lasker-Schüler, die sich selbst gern so titulierte? Der Finanzmathematiker Nassim Nicholas Taleb bezeichnete als "Black Swan" eine seltenes und unvorhersehbarer Ereignis, das eine unverhältnismäßig große negative Wirkung hervorruft.
McKinsey und die Said Business School der University of Oxford haben sich diesen Begriff ausgeliehen. Mit ihm bezeichnen sie ein Projekt, das sein Budget um mindestens 200 Prozent überzieht und 70 Prozent mehr Zeit verschlingt als geplant. Nach der statistischen Wahrscheinlichkeit - Stichwort: Normalverteilung - sollte das die absolute Ausnahme sein. Die Analysten und Wissenschaftler haben für derart überzogene Projektbudgets eine Eintrittswahrscheinlichkeit von 0,7 Prozent ausgerechnet.
Aber diese Gesetze gelten offenbar nicht für Projekte im Umfeld der Informationstechnik. Dort ist es 30 mal wahrscheinlicher, dass ein Projekt komplett aus dem Ruder läuft: Zwölf bis 18 Prozent der IT-Vorhaben sind "Schwarze Schwäne", so haben die Management-Beratung und die renommierte Hochschule in langjährigen Untersuchung von rund 1500 Projekten herausgefunden.
Seit vier Jahren arbeitet McKinsey jetzt schon mit dem Lehrstuhl von Professor Bent Flyvbjerg zusammen: Der Oxford-Professor hat eine Methode zur Risikovorhersage in Projekten entwickelt, die sich vor allem in Großbritannien und Dänemark durchgesetzt hat: Dort ist sie für alle öffentlichen Projekte im Infrastrukturbereich verbindlich, sagt Jürgen Laartz, Director im Business Technology Office von McKinsey. Mit dieser "Reference Class Forecasting" genannten Methode lässt sich das Risiko für ein Scheitern des Projekts bereits vor dem eigentlichen Start eingrenzen. Flyvbjergs Arbeit gab denn auch den Anstoß zu der Studie.
Der Durchschnitt besagt wenig
Die überwiegende Mehrzahl der untersuchten Projekte bewegt sich kostenmäßig im "Normalbereich", den McKinsey zwischen minus 50 und plus 80 Prozent des veranschlagten Budgets ansiedelt. Der Durchschnitt liegt bei einer Budgetüberschreitung von "nur" 27 Prozent der Kosten. "Da sollte man meinen, dass alles in Ordnung wäre", macht sich Laartz zum Advocatus Diaboli.
Foto: McKinsey, University of Oxford
Erst bei genauerem Hinsehen offenbart sich, dass jedes sechste der untersuchten Projekte kostenmäßig im "Fat Tail" der Statistik landet. So genant, weil sich die Gesamtkosten dieser Vorhaben in vielen Fällen auf das Vier- oder sogar Sechsfache des ursprünglich kalkulierten Budgets beliefen. Wohl gemerkt, von Projekten, die offiziell als erfolgreich abgeschlossen galten. Abgebrochene Vorhaben wurden hier nicht berücksichtigt.
Ein Projekt, das deutlich, sprich: um mehr als die Hälfte, unter den Plankosten bleibt, gilt übrigens auch als Schwarzer Schwan. Unerwartet geringe Kosten sind zwar auf den ersten Blick positiv. Doch schnell werden die negativen betriebswirtschaftlichen Folgen sichtbar. Nicht nur, dass eine solche Diskrepanz auf eine schlechte Planung hinweist. Vielmehr lassen sich die günstigen Kosten, so Laartz, oft darauf zurückführen, dass Abstriche hinsichtlich der "Benefits" gemacht werden. Selbst wenn das nicht der Fall ist, werden so Mittel gebunden, die anderswo wirkungsvoll hätten eingesetzt werden können.
Vier schwarze Schwäne
Schwarze Schwäne tauchen in unterschiedlicher Gestalt auf. Es lassen sich vier Prototypen unterscheiden.
-
Der "frühe" Schwarze Schwan erlebt die Kostenexplosion bereits in der Spezifizierungsphase. Dieser Anstieg kann auch im Projektverlauf nicht mehr aufgefangen werden. Also ist dies der Projekttyp, der am Ende die höchsten Kostenüberschreitungen aufweist. Aus Sicht von McKinsey wäre es sinnvoll, hier sofort die Reißleine zu ziehen: "Aber kaum jemand hat den Mut, diese Projekte in einem derart frühen Stadium zu canceln", weiß Laartz aus Erfahrung. Stattdessen versichere man sich gegenseitig, die Kosten im Projektverlauf schon wieder einsparen zu können: "In den Köpfen der Projekt-Manager ist eben ein unrealistisches Risikoprofil gespeichert."
-
Der "typische" Schwarze Schwan" macht sich erst in der Design-Phase bemerkbar. Dort steigen die Kosten durchschnittlich um das Dreifache des geplanten Budgets an, bleiben aber in der Folge stabil. Das bedeutet am Ende immer noch exorbitante Überschreitungen um die 300 Prozent.
-
Das "umgedrehte hässliche Entlein" heißt so, weil es am Anfang hübsch aussieht und nach Erfolg riecht. Dass es sich um einen Schwarzen Schwan handle, bleibe lange unterhalb der Wahrnehmungsschwelle, sagt Laartz. Erst in der Entwicklungsphase offenbare sich, dass anfangs nicht sauber gearbeitet wurde - beispielsweise dann, wenn sich Randbedingungen ändern oder die Integration in die IT-Umgebung ansteht. Häufig unterschätze das Projektteam auch die Zahl der Use Cases. Werden solche Spezifikationsfehler erst nachträglich evident, kostet ihre Korrektur Zeit und Geld.
-
Der "verhungernde" Schwarze Schwan ist der bereits erwähnte Projekttyp, der unter Budget bleibt - aber nur, weil die angepeilten Ziele kontinuierlich verringert werden. So ergibt sich trotz der günstigen Kostenentwicklung ein ungünstiges Kosten-Nutzen-Verhältnis.
Vage Gründe für das Scheitern
Warum IT-Projekte unberechenbarer sind als andere Vorhaben, mag auch Laartz nicht eindeutig begründen. Möglicherweise kämen hier verstärkt die beiden am weitesten verbreiteten Ursachen für Fehleinschätzungen zum Tragen. Die seien:
-
Übertriebener Optimismus aufgrund einer interessengeleiteten Darstellung des Projekts ("Optimism Bias"); dieser Fehler lässt sich durch die Nutzung einer unabhängigen Risikoeinschätzung korrigieren, wie sie beispielsweise das "Reference Class Forecasting" darstellt.
-
Mangelnder Fokus auf die strategischen Ziele ("Strategic Misrepresentation"); das führt dazu, dass im Projektverlauf Änderungen vorgenommen werden, die den Nutzen des Vorhabens schmälern, wenn nicht verhindern.
Weitere Besonderheiten von IT-Projekten liegen auf der technischen Seite. Dazu gehören beispielsweise Unwägbarkeiten in der Implementierungsphase. Wie Laartz einräumt, ist die Untersuchung in diesem Punkt noch nicht abgeschlossen: "Wir können nur etwa jeden zweiten Fall auf seine Ursachen zurückführen."
Das macht die Suche nach einem Gegengift umso schwieriger. Nicht einmal die Betrachtung der Best-in-class-Projekte hilft hier sehr viel weiter: Auch von den IT-Vorhaben, in denen fast alles richtig gemacht wurde, endete jedes zehnte im "schwarzen" Bereich.
Size doesn't matter that much
Foto: Euroforum/Meyer
Seit den 90er Jahren beschäftigen sich die Berater und Analysten mit der Frage, was signifikante Budgetüberschreitungen verursacht und wie sie sich vermeiden lassen. Zum Ende des vergangenen Jahrhunderts galt die von Capers Jones aufgestellte These, dass die Wahrscheinlichkeit der finanziellen Bruchlandung mit der Größe des Projekts wachse. Zu einem ähnlichen Ergebnis kam die Standish Group später in ihrem "Chaos Report".
McKinsey ist jedoch anderer Ansicht: "Es gibt keine Korrelation von Misserfolg und Projektgröße", konstatiert Laartz - "jedenfalls heute nicht mehr". Die Unternehmen hätten mittlerweile gelernt, umfangreiche Projekte zu modularisieren: "In der Folge haben sich die Risikoprofile von großen und mittleren Projekten angenähert."
Allerdings tun sich Analysten und Wissenschaftler auch schwer, andere Zusammenhänge zu finden. Fest steht allerdings, dass die finanziellen Exzesse auch mit exorbitanten Zeitüberschreitungen einhergehen. Dass Projekte mehr als anderthalb mal so lange dauern wie geplant, ist dabei sogar noch an der Tagesordnung. Die Vorhaben, die ihre Plankosten um mehr als 200 Prozent überschreiten, brauchen noch mehr Zeit: Im Durchschnitt überziehen sie den Zeitplan um 68 Prozent. Das veranlasst Laartz zu der Feststellung: "Je länger ein Projekt dauert, desto höher das Risiko eines Cost Overrun." Also ist nicht der Projektmfang, sondern die benötigte Zeit der Hauptrisikofaktor.
Maßnahmen zur Risikoverminderung
Folglich besteht eine Maßnahme zur Risikoverminderung darin, statt eines "Big-Bang"-Dreijahres-Projekts lieber drei Einjahresprojekte umzusetzen, die jeweils aufeinander aufbauen. Das hat diverse Vorteile:
-
Zum einen gibt es mindestens drei feste Abschlusstermine. Noch besser ist es, pro Jahr mehrere Meilensteine zu vereinbaren, zu denen Teilziele erreicht sein müssen.
-
In einem überschaubaren Projekt ist es zudem einfacher, die Interdependenzen zu überblicken. Hier scheitern viele IT-Vorhaben: Die Implementierung ist gelungen, aber sie lässt sich nicht in das Umfeld einbetten.
-
Ein kurzes Projekt bietet auch bessere Möglichkeiten der Nachsteuerung. Der ständige Strategieabgleich ist die eine Sache, Fehlentwicklungen zurückzuschrauben und in eine andere Richtung zu drehen ist die andere. Diese Maßnahme ist wichtig, weil sich Markt und Unternehmensorientierung heute relativ schnell ändern.
-
Last, but not least schaffen Langzeitprojekte eine eigene Organisation, quasi ein Unternehmen im Unternehmen. Es gibt Mitarbeiter, die ihre gesamte Zeit im Betrieb innerhalb einer Projektstruktur verbringen und sich in dieser Nische einrichten. Auf Jahresbasis ausgeschriebene Projekte hingegen laufen im Idealfall darauf hinaus, dass sich immer wieder andere Teammitglieder zusammenfinden.
Der Business-Plan hat ausgedient
Ein Handikap der meisten Projekt-Management-Strukturen ist das fehlende "Inkasso" des Projektnutzens. Zwar formulieren die Projektverantwortlichen einen Business-Plan, um ihre Vorhaben zu rechtfertigen. Doch wenn diese erst einmal genehmigt sind, gerät der Plan schnell in Vergessenheit. Nur jedes fünfte Unternehmen gleicht Projektergebnis und Business-Plan auch im Verlauf des Vorhabens und hinterher ab. Ein fataler Fehler, wie Laartz bemerkt hat: "Wenn man diesen Punkt aus dem Auge verliert, trifft man leicht die falschen Entscheidungen." Jedes Projekt müsse "gegen den Business Case gemanagt" werden. Sonst entwickle es sich zu einem reinen Technologieprojekt.
Im einem größeren Rahmen betrachtet, hapert es häufig an einer sauberen Governance, also der Verankerung der IT im Business. Nach Auffassung von McKinsey sollte es in jedem Unternehmen einen "Owner" für die Wertbetrachtung der IT geben. Aber da diese Position zwangsläufig an der Schnittstelle zwischen Business und IT angesiedelt ist, fühlt sich häufig keine Seite dafür zuständig. Also gibt es sie fast nirgendwo.
COMPUTERWOCHE-Kommentar
Foto: Karin Quack
Was ist eigentlich ein erfolgreiches IT-Projekt? Die naheliegende Antwort: ein Projekt, das seinen Zeit- und Budgetrahmen einhält. Wirklich? Nein, selbstverständlich nicht. Das ist zwar schon sehr löblich - vor allem, wenn es sich um ein naturgemäß zur Proliferation neigendes IT-Projekt handelt. Aber ein Kongressvortrag ist ja auch nicht schon deshalb gelungen, weil der Redner exakt 45 Minuten gesprochen und in dieser Zeit den Raum nicht verlassen hat.
Wenn der Sprecher das Thema verfehlt oder ständig abschweift, sind die Zuhörer genervt und am Ende unzufrieden. Analog dazu ist ein erfolgreiches Projekt eins, das sich ans Thema hält, sprich: die Spezifikationen einhält. Das ist ja wohl das mindeste, werden Einige jetzt einwenden. Aber sie verkennen, dass sich vor allem in langfristigen Projekten die Anforderungen häufig ändern. Ein Projekt, das hier up to date bleibt, hat zumindest einen Teilerfolg errungen.
Doch es gibt durchaus Projekte, die formal alle Anforderungen erfüllen - auch die nachträglich gestellten - und trotzdem als gescheitert gelten müssen. Warum? Weil ihr Produkt nicht genutzt wird. Erst in der Anwendung des aus dem Projekt entstandenen Systems entscheidet sich, ob das Vorhaben seine Kosten wert gewesen ist. Das macht die "Wertbetrachtung" so schwierig.
McKinsey rät jedem Unternehmen, explizit einen Zuständigen für den Wertbeitrag der IT zu bestimmen. Aber wer sollte das sein? Ein Controller wird nur die messbaren Fakten betrachten. Eine strategische Erörterung à la "Wo stünde das Unternehmen ohne dieses Projekt"? liegt außerhalb seines Zuständigkeitsbereichs. Die Perspektive eines Fachbereichs-Managers ist naturgemäß durch den Abteilungshorizont eingeengt.
Der Wertbeitrags-Manager müsste eine Person sein, die genug technisches Know-how hat, um Projekte beurteilen zu können, aber gleichzeitig so viel vom Business versteht, dass sie die für das Unternehmen relevanten Verbesserungen wahrnehmen kann. Das klingt verdächtig nach der Definition eines guten CIOs. Der kann diese Aufgabe allerdings nur erfüllen, wenn er unbefangen an die Projekte herangeht. Voraussetzung dafür ist also eine strikte Trennung zwischen der Demand- und Supply-Seite der IT. (qua)