Unterschiedliche Studien der vergangenen Jahre zeigen auf, dass eine Vielzahl von IT-Projekten scheitert oder nur teilweise erfolgreich abgeschlossen wird. Warum ist das so? Es gibt eine überschaubare Anzahl an Gründen, die IT-Projekte scheitern lassen.
Um IT-Projekte erfolgreich abwickeln zu können, sollte man sich mit den nachfolgenden Faktoren intensiv beschäftigen. Die Tatsache, dass man die Risikofaktoren für das Scheitern von Projekten kennt und sich mit ihnen auseinandersetzt, ist der erste Schritt, um das Risiko des Scheiterns zu reduzieren.
Inhaltsverzeichnis
Zahlen, Daten, Fakten, Studien
- 52% der IT-Vorhaben haben zumindest teilweise nicht die Wünsche und Anforderungen der Auftraggeber erfüllt. 19% der Projekte sind ein Totalausfall und wurden abgebrochen. Nur 29% der untersuchten Projekte waren total erfolgreich.
(„Chaos Report“ der Standish Group, USA, 2015) - 17% der untersuchten IT-Projekte haben massiv ausufernde Kosten, extreme terminliche Verzögerungen – es läuft vieles aus dem Ruder und bringt Unternehmen oft in bedrohliche Schwierigkeiten. Untersucht wurden 1.500 Projekte mit einem durchnittlichen Kostenvolumen i.d.H.v. 170 Millionen US-Dollar.
(Studie der Universität Oxford und des Beratungsunternehmens McKinsey 2011) - Nur knapp die Hälfte aller IT-Vorhaben der vergangenen drei Jahre war erfolgreich. Sie dauerten entweder länger als geplant, kosteten wesentlich mehr oder es kam am Ende ein anderes Ergebnis heraus. Andere Projekte mussten sogar abgebrochen werden, wobei in der Regel viel Geld in den Sand gesetzt wird.
(Studie der Technischen Universität München) - Die meisten IT-Projekte scheitern an unklaren Zielen, unrealistischen Zeitvorgaben und fehlender Abstimmung aller am Projekt Beteiligter.
(Assure Consulting, 2007) - 20% aller IT-Projekte werden abgebrochen; jedes zweite dauert länger oder wird teurer als geplant. Die Wahrscheinlichkeit des Scheiterns steigt mit der Dauer und Komplexität von Projekten.
(Studie „Projekte mit Launch Management auf Kurs halten. Warum IT-Großprojekte häufig kentern und Projekterfolg kein Glücksspiel ist“, Roland Berger Strategy Consultants, 2008) - Die Erfolgsrate bei Projekten in den USA werden auf 34% geschätzt. Die Fehlschläge werden für die USA mit Kosten in der Höhe von 150 Milliarden Dollar pro Jahr beziffert. In der EU wird der Schaden mit 140 Milliarden jährlich in etwa gleichen Größenordnungen angenommen.
(Standish Group)
Wenn IT-Projekte scheitern bewegt sich der Schaden oft in mehrstelliger Millionenhöhe
Warum IT-Projekte scheitern
Unklare Ziele, unterschiedliche Erwartungen
Es geschieht häufiger als man denkt, dass Projekte ohne klar erkennbares Ziel vor sich hinplätschern. Wenn Geschäfts- und IT-Leitung das Kernziel eines Projektes – aus welchen Gründen auch immer – nicht gemeinsam festgelegt haben, arbeiten sie aneinander vorbei. Die Konsequenzen sind ausufernde Budgets, verschobene Termine und allgemeine Unzufriedenheit.
In vielen gescheiterten IT-Projekten bestand keine Einigkeit darüber, welchen Umfang das Vorhaben annehmen sollte. Schon im eigenen Unternehmen sind unterschiedliche Interpretationen kritisch. Noch schwieriger wird es aber wenn Ausschreibungen unklar formuliert sind und unterschiedliche Erwartungshaltungen zulassen.
Um einen Auftrag zu erhalten, versuchen Anbieter ihre Schwachstellen zu verbergen. Oft wird aber die eigene Leistungsfähigkeit auch überschätzt. Präsentationen und Verhandlungen finden oft auf der Ebene des Top-Managements statt. Da kann es leicht passieren, dass schnell einmal die Projektdauer verkürzt wird, ohne sich vorher mit den Spezialisten über die Machbarkeit auszutauschen.
Mangelndes Anforderungsmanagement
Ständige Veränderungen der Anforderungen (so genannte „moving targets“) und deren mangelhafte Dokumentation sind deutliche Risikotreiber in IT-Großprojekten. Die wichtigste Quelle für Anforderungen – die Stakeholder – wird nicht systematisch erschlossen. Es erfolgt oft keine Stakeholderauswahl bzw. wird dafür zu wenig Zeit aufgewendet. Anwender über den fachlichen Verantwortlichen hinaus werden oft nicht oder nur sehr selten in die Anforderungsanalyse einbezogen. Durch gezielte Stakeholder-Auswahl kann vertieftes Prozesswissen generiert werden.
Sprachliche Unzulänglichkeit ist eine der größten Fehlerquellen, noch vor logischen und inhaltlichen Fehlern. Missverständnisse in der Kommunikation sind einer der Hauptgründe für die nachträglich notwendige Änderung von Anforderungen. Diese nachträglichen Änderungen finden ohne Abstimmung und Rücksprache statt und werden nirgendwo oder nur unzureichend dokumentiert. Als Ergebnis explodieren die Kosten und der vorgesehene Zeitplan ist nicht mehr einhaltbar.
Teamgröße und Projektdauer
Je größer das Projektteam und je länger das Projekt dauert, umso höher die Wahrscheinlichkeit des Scheiterns. Ab einer Teamgröße von 40 Personen sowie einer Projektlaufzeit von 2 Jahren steigt das Risiko, Schiffbruch zu erleiden, deutlich an. Wenn die Projektlaufzeit 3 Jahre übersteigt, liegt die Erfolgschance laut Statistik schon unter 20% (Quelle: Standish Group).
Einsatz von unausgereiften Technologien
Im Rahmen von IT-Großprojekten werden oft neue Technologien eingesetzt, die erst im Projekt entwickelt bzw. ausgereift werden. Diese Innovationen werden eingesetzt, um First-Mover-Vorteile zu nutzen. Sind diese Technologien oder auch nur Teile davon jedoch noch nicht ausreichend durchdacht, erhöhen sie die Komplexität des Projektes immer mehr und bereiten zusätzliche Probleme. Dadurch entstehen Zusatzaufwände für die Entwicklung und Integration.
In der Softwareentwicklung bestehen 70% einer Applikation heute schon aus Standardkomponenten. Die zwingenden Gründe für eine Neuentwicklung sind nur noch in den wenigsten Fällen vorhanden. Solange Neuentwicklungen nicht unbedingt nötig sind, sollte auf ausgereifte Technologien und bewährte Standards gesetzt werden. Falls Sie neue Technologien zum Einsatz bringen, gilt es diese sorgfältig zu bewerten und zu planen. Des größeren Aufwandes muss man sich voll und ganz bewusst sein.
Komplexität des Projektes wird unterschätzt
Mit der Anzahl der Projektmitarbeiter und -beteiligten steigt die Zahl der Kommunikationsschnittstellen exponentiell. Dazu kommt noch das Spannungsfeld zwischen den prozessualen fachlichen Anforderungen (Fachbereichsseite) und der technischen Sicht (IT Seite). Verstärkt wird die Komplexität auch noch durch widersprüchliche Zielsetzungen, als Ergebnis unklarer Erwartungen an das Projekt. Überproportional zur Komplexität steigen aber auch die Erfolgsrisiken.
Oft wird auch der technische Aufwand unterschätzt. Viele Projektteams planen nach Best-Case-Szenarien. Wenn die Realität das Projekt einholt, fallen erhebliche Mehrkosten an und die Projektlaufzeit verlängert sich.
Mit der Größe eines Projektes verkompliziert sich auch das zu steuernde Projektumfeld mit all seinen Stakeholdern und Interessensgruppen, die versuchen, Einfluss auf das Projekt zu nehmen. Meist kommt dann noch der politische Faktor ins Spiel. Bei Großprojekten bewegt man sich rasch auf der Ebene von Ministerien und Konzernen.
Mit zunehmender Projektgröße steigt der Stellenwert der Erfahrung des Projektleiters. Die Praxis zeigt, dass Projektleiter, die den Umgang mit vielen Stakeholdern erfolgreich beherrschen, ein wichtiger Erfolgsfaktor sind. Der erste Schritt, um Komplexität zu reduzieren und beherrschbar zu machen, ist klare Ziele zu entwickeln und vorzugeben. In weiterer Folge muss das Projekt in kleine überschaubare Einheiten herunter gebrochen werden. Wenn notwendig ist das Projekt in mehrere autonome Projekte aufzusplitten.
Unzureichende Projektplanung und -steuerung
Viele Projekte, die scheiterten, besaßen keine aktuelle oder – noch schlimmer – überhaupt keine Gesamtprojektplanung. Dabei ist eine Gesamtprojektplanung, die einzige Möglichkeit, ein Projekt detailliert zu durchleuchten und zu steuern. Die Abhängigkeiten, Risiken, benötigten Ressourcen können nur dadurch sichtbar gemacht werden. Meist wird erst durch die Gesamtprojektplanung die Komplexität bewusst. Der erste Schritt, um die Komplexität zu reduzieren und dadurch beherrschbar zu machen.
Bei fast 50% der Projekte fehlt ein Projektstab, der sich angemessen um Planung, Risikomanagement und operative Steuerung des Projektes kümmert. Ein Projektleiter alleine kann dies bei Großprojekten nicht mehr schaffen.
Regelmäßige, offene und vollständige Information über den aktuellen Projektstatus sichert dem Projekt Aufmerksamkeit des Top-Managements und baut Vertrauen auf. Dadurch kann auch eventuell notwendige Unterstützung leicht angefordert werden. Fehlt diese Information oder sind die Berichte auch nur unverständlich aufbereitet, kann ein verunsichertes Top-Management durch „Verbesserungsvorschläge“ und Sonderprüfungen dem Projekt wertvolle Zeit und Energie kosten.
FAZIT
Es ist selbstverständlich möglich, große Projekte erfolgreich ins Ziel zu bringen. Es muss aber sichergestellt werden, dass eine Vielzahl an Rahmenbedingungen stimmt. Für den Projekterfolg gibt es kein Geheimnis oder standardisiertes „Kochrezept“, sondern er beruht auf strukturiertem und durchdachtem Vorgehen, dem Nutzen von leidvollen Erfahrungen und Erkenntnissen aus anderen Großprojekten (die hoffentlich andere gemacht haben) und grundsolidem Projektmanagement-Handwerk.
Die eindeutige Klärung der Projektinhalte und deren Reduzierung auf das Wesentliche sowie das Erkennen und Vermeiden von unnötigen Risiken sind dabei – wie auch im Alltagsleben – einfache, aber sehr effektive und zielführende Maßnahmen.
Beispiele für Desaster-Projekte
Flughafen Berlin Brandenburg („Willy Brandt“ Flughafen)
Der Flughafen Berlin Brandenburg kann als Paradebeispiel für ein außer Kontrolle geratenes gescheitertes Projekt herhalten. Der Spatenstich zur Flughafenbaustelle erfolgte am 5. September 2006. Die Betriebsaufnahme hätte im November 2011 erfolgen sollen. Dieser Termin – und auch alle nachfolgenden Eröffnungstermine – wurden jedoch u. a. wegen technischer Mängel verschoben. Der Bau des Flughafens wurde im Oktober 2020 abgeschlossen und der Flughafen konnte nach 14-jähriger Bauzeit eröffnet werden.
Beim Spatenstich im Jahr 2006 war von Kosten von ca. 2 Milliarden Euro die Rede gewesen, mittlerweile werden die Kosten auf ca. 7,3 Milliraden Euro geschätzt. Die medialen Schlagzeilen des Flughafenprojekts sind mittlerweile relativ einheitlich:
- Chronik eines Desasters (ZDF)
- Eine Chronik des Scheiterns (FAZ)
- Chronik eines Bau-Desasters (Spiegel)
- Chronik einer Blamage (Der Tagesspiegel)
Toll-Collect
Der ursprünglich zum 31. August 2003 geplante Starttermin von Toll Collect – dem LKW-Maut System in Deutschland – konnte aufgrund diverser technischer Schwierigkeiten erst mit 16 Monaten Verspätung Anfang 2005 – in technisch reduzierter Form – in Betrieb genommen werden.
Am 29. Juli 2005 ließ das deutsche Bundesministerium Klage gegen das Maut-Konsortium einreichen. 1,6 Milliarden Euro Vertragsstrafen sowie 3,5 Milliarden Euro Einnahmeausfälle werden geltend gemacht. Im Mai 2018 – nach einem 14-jährigen Rechtsstreit – einigte sich der Bund mit den Hauptgesellschaftern des Betreiberkonsortiums Toll-Collect auf eine Zahlung in der Höhe von 3,2 Milliarden Euro an die Bundesrepublik.
Adonis (Austrian Digital Operating Network for Integrated Services)
2002 startete die Firma Mastertalk das Projekt zum Aufbau eines bundesweites Behördenfunknetzes für alle Blaulicht- und Sicherheitsorganisationen in Österreich (Auftragsvolumen ca. 310 Millionen Euro).
Im Juni 2003 löste das BMI (BUndesministerium für Inneres) den Vertrag zur Errichtung von ADONIS aus folgenden Gründen auf: mangellhaftes Projektmanagement, Verzug von Leistungen, deutliche technische Mängel. Mastertalk klagte die Republik Österreich auf Zahlung von 181 Mio. Euro Schadenersatz. 2006 einigten sich die Republik und Mastertalk „gütlich“. Über die Zahlung wurde Stillschweigen vereinbart. Das Projekt wurde 2004 neu ausgeschrieben.
FISCUS (Föderales Integriertes Standardisiertes Computer-Unterstütztes Steuersystem)
FISCUS war als einheitliche Software für die ca. 650 Finanzämter der Länder der Bundesrepublik Deutschland angedacht. Die Entwicklung von FISCUS startete 1993 mit strukturierten Entwicklungsmethodiken. Mitte der 1990er Jahre erfolgte ein Wechsel von der strukturierten Entwicklung hin zur objektorientierten Entwicklung. Man entschied sich das Framework „San Francisco“ von der Firma IBM einzusetzen.
Als IBM die Weiterentwicklung des Frameworks „San Francisco“ einstellte, ging dem Projekt eine essenzielle technologische Basis verloren. Nach einer Entwicklungszeit von 13 Jahren und geschätzten Entwicklungskosten von rund 400 Millionen Euro gab es 2006 kein brauchbares Ergebnis. Das Projekt wurde 2006 eingestellt und es wurde ein Nachfolgeprojekt namens KONSENS aufgesetzt.
DIA-Gepäcksystem
Die Eröffnung des neu gebauten Denver International Airport – geplant für Oktober 1993 – verzögerte sich um fast 15 Monate, da die Software zur Steuerung der automatischen Gepäcksortieranlage, nicht rechtzeitig fertig gestellt wurde und es keine Alternativplanung gab. Dadurch entstanden Mehrkosten von 500 Millionen Dollar, die die Stadt Denver tragen musste.
