Scheitern von IT-Projekten

Unterschiedliche Studien der vergangenen Jahre zeigen auf, dass eine Vielzahl von IT-Projekten scheitert oder nur teilweise erfolgreich abgeschlossen wird. Warum ist das so? Wir haben diese Studien analysiert. Dabei hat sich eine überschaubare Anzahl an Gründen herauskristallisiert, die IT-Projekte scheitern lassen.

Bei der erfolgreichen Abwicklung von IT-Projekten muss man sich mit den nachfolgenden Faktoren intensiv beschäftigen. Die Tatsache, dass man die Risikofaktoren kennt und sich mit ihnen auseinandersetzt, ist der erste Schritt, um das Risiko des Scheiterns zu reduzieren.


Zahlen, Fakten, Daten, Studien

  • 46% der IT-Vorhaben haben zumindest teilweise nicht die Wünsche und Anforderungen der Auftraggeber erfüllt. Jedes fünfte Projekt ist ein Totalausfall.
    („Chaos Report“ der Standish Group 2006)
  • 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)
  • Nur 16% der untersuchten IT-Projekte können als erfolgreich eingestuft werden.
    (Studie der Universität Oxford 2003)

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.

Grandios gescheitert: Misslungene Projekte der Menschheitsgeschichte
  • Bernd Ingmar Gutberlet
  • Lübbe
  • Auflage Nr. 1. (16.03.2012)
  • Gebundene Ausgabe: 333 Seiten

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

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.

Toll-Collect:
Der ursprünglich zum 31. August 2003 geplante Starttermin von Toll Collect – dem LKW-Maut System – 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 Vetragsstrafen sowie 3,5 Milliarden Euro Einnahmeausfälle werden geltend gemacht.

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 (Auftragsvolumen ca. 310 Millionen Euro). Im Juni 2003 löste das BMI 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.


Anzeige

Literaturhinweise