Zu komplex und schlecht geplant

Warum IT-Projekte oft scheitern

22.04.2014 von Christoph Lixenfeld
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.

An einem Punkt unterscheiden sich IT-Projekte nicht von anderen komplexen Großvorhaben: Entscheidend ist die Planung. Das Desaster am Berliner Großflughafen zum Beispiel ist vor allem auf Planungsfehler zurückzuführen. Und schlechte Planung ist auch der Grund für gescheiterte IT-Projekte. Laut einer Studie des Softwareanbieters Alfabet haben über die Hälfte der IT-Entscheider in Deutschland, Österreich und der Schweiz wiederholt erlebt, dass geschäftskritische Maßnahmen scheiterten, weil die Beteiligten Entscheidungen anderer Unternehmensteile mit fatalen Auswirkungen auf das Vorhaben nicht kannten.

Was in diesen Fällen fehlte, war die ganzheitliche Sicht auf das Konzept und Antworten auf Fragen wie zum Beispiel: Wer unterstützt das Vorhaben? Wem nützt es? Wer ignoriert es bestenfalls? Wen zwingt es zu Veränderungen? Wer erleidet dadurch Nachteile, zumindest subjektiv empfunden?

Sabotage von Projekten

Nach Ansicht von Siegfried Stadler, Projekt-Coach bei der Unternehmensberatung Hyperskill, ist sogar die regelrechte Sabotage eines Projekts keineswegs selten: "Scheitert ein Projekt, gibt es oft jemanden, der nicht will, dass es zum Erfolg führt." Besser also, man macht sich vorher Gedanken darüber.

Neben der Information ist auch die Kommunikation im Projekt ein wichtiger Erfolgsfaktor. Für den Projektverantwortlichen genügt es nicht, viele E-Mails zu schreiben und zahlreiche Menschen auf Cc zu setzen. Er muss mit den Beteiligten sprechen und ein Gefühl dafür entwickeln, wie gut diese untereinander vernetzt sind. Sprechen sie nur beim Meeting notgedrungen fünf Sätze miteinander, oder treffen sie sich - zumindest gelegentlich - auch mal auf eine Tasse Kaffee

Von großer Bedeutung, das zeigen die hier ausgewählten Beispiele für gescheiterte Projekte, ist eine realistische Einschätzung der zu erwartenden Komplexität. Ebenso ist die öffentliche Akzeptanz rechtzeitig ins Kalkül zu ziehen, denn ohne sie sind vor allem sensible Projekte in Sachen Datenschutz von vornherein zum Scheitern verurteilt. An diesem Punkt hat es in letzter Zeit eine Reihe von Pannen, ja sogar Desastern gegeben, wo schwer nachvollziehbar ist, warum sich die Macher auf so dünnes Eis vorwagen konnten.

Projektziele klar definieren

Wenn es zum Stopp von IT-Projekte kommt oder diese schiefgehen, haben in der Regel beide Seiten Fehler gemacht. Verringern lässt sich das Risiko dadurch, dass alle Beteiligten im Vorfeld akribisch ihre Hausaufgaben machen. Uwe Groß, Partner bei IBM Global Business Services, rät vor allem dazu, jedes Projekt so klar wie möglich zu definieren: "Es geht ganz banal um Fragen wie: Was sind genau die Ziele? Mit welcher Priorität? Mindestens diese Fragen müssen als Orientierungsrahmen beantwortet sein."

Volle Rückendeckung sichern

Zweitens ist es aus Sicht von Groß wichtig, dem Projekt im Vorfeld intern die notwendige Unterstützung zu sichern. Es genüge nicht, dass der Vorstand ein Projekt nur dulde. Das Motto müsse stattdessen lauten: Wir werden gemeinsam alles tun, damit es erfolgreich wird.

Wann läuft ein Projekt schief
Die Reißleine ziehen - wann und woran lässt sich erkennen, dass ein Projekt aus dem Ruder läuft?
Ist für das Projekt eine Zeitdauer von mehr als eineinhalb Jahren vorgesehen?
Dann ist es besser, das Projekt in kleinere Teilschritte zu gliedern und Geschäftsprozesse nacheinander umsetzen. Der Grund: Ein Unternehmen entwickelt sich in zwei Jahren weiter, Geschäftsprozesse verändern sich und die ursprünglich geplanten Projektumfänge sind nicht mehr dieselben. Selbst ein sauber aufgesetztes Change-Management greift immer in die laufende und noch nicht vollständige Implementierung ein.
Werden Meilensteintermine überschritten?
Spätestens wenn der erste Termin überschritten wird, muss die Projektleitung dem sofort Rechnung tragen und gemeinsam mit dem Lenkungsausschuss die geplanten Maßnahmen kritisch prüfen.
Gibt es viele Änderungen während des Projektes?
Tauchen während der Projektlaufzeit permanent Änderungen auf, war die Planung schlecht oder die Realität überholt die Einführung. In diesen Fällen sollten alle Beteiligten offen über die absehbaren Risiken sprechen und realistische Gegenmaßnahmen entwickeln, die den Projekterfolg sicherstellen. Oder gemeinsam entscheiden, Termin- und Budgetanpassungen vorzunehmen.
Stimmen die zwischenmenschlichen Beziehungen noch?
Kommt es zwischen Beratern, Projektleitung und Key Usern vermehrt zu Spannungen, funktioniert die Kommunikation nicht (mehr) richtig. Motivationsprobleme treten auf und es werden oft Schuldige gesucht statt Lösungen. In solchen Fällen sollte umgehend gehandelt werden - dies ist eine der Hauptursachen für scheiternde Projekte!
Ist die vereinbarte Dokumentation ...
... im Projekt aktuell und sind Änderungen sauber dokumentiert? Wenn nicht, ist dies ein sicherer Indikator dafür, dass das Projekt aus dem Ruder zu laufen droht.
Stimmt die Qualität ...
... der Implementierungspartner und wie lässt sich mangelndes Wissen der Consultants erkennen? Implementierungsziele, die gerissen werden und Teilschritte, die qualitativ nicht der Planung entsprechen, sind eindeutige Anzeichen der Schwäche. Prüft man Teilschritte in regelmäßigen Abnahmen per Testkatalog, sind Abweichungen leicht festzustellen.
Ein Implementierungspartner ...
... und Verantwortlicher ist immer einfacher zu steuern als mehrere. Vor allem dann, wenn diese in einer Wettbewerbssituation zueinander stehen.

Nur so viel Komplexität wie nötig

Der wichtigste Punkt ist jedoch, wo immer möglich die Komplexität zu verringern. Laut Groß bewährt es sich, nach folgendem Prinzip zu verfahren: So viel Komplexität wie nötig, aber nicht mehr. Entscheider, die so planen, würden, so der Projektplaner, in der Regel eine Lösung erzielen, die 80 Prozent der Wünsche an die neue Lösung erfüllt. "80 Prozent sind ein sehr guter Wert", meint Groß und rät dazu, die Spezifikationen gemeinsam mit dem Kunden zu erarbeiten, auch weil so unrealistische Erwartungen früh sichtbar würden.

Wer dagegen auf eigene Faust ein 500-seitiges Pflichtenheft entwirft und den Servicepartner anschließend über den Preis auswählt, darf sich nicht wundern, wenn das Projekt schon nach kurzer Zeit in Schieflage gerät, wie in den folgenden Beispielen geschehen.

Gescheiterte, gestoppte oder in Schieflage befindliche IT-Projekte

1. Schufa: Kein Freibrief für Big Brother

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 eine Welle der Empörung aus. Ilse Aigner, Bundesministerin für Verbraucherschutz, sagte, die Schufa dürfe nicht zum Big Brother des Wirtschaftslebens werden. Die Schufa stoppte den Plan. Die Rechtslage auf diesem Gebiet ist nicht eindeutig, es gibt Experten, die eine solche zweckfremde Nutzung von Facebook-Postings schlicht für illegal halten. Vielleicht hätte die Schufa vorher entsprechenden Rat einholen sollen.

2. Otto und SAP: zu komplex

Das "größte IT-Projekt in der Geschichte" des Versandhändlers Otto wurde im September 2012 gestoppt. 2009 hatte der Konzern aus Hamburg das Vorhaben mit dem Ziel gestartet, die große und vielschichtige Anwendungslandschaft des Multi-Marken- und Multi-Plattform-Händlers mit Hilfe von SAP-Standardsoftware zu zentralisieren. Doch "Passion for Performance" wurde vor allem zur Leidensgeschichte und sorgte bereits im Frühjahr 2011 für den Abschied von CIO Thomas Tribius. Die Komplexität wuchs den Beteiligten schlicht über den Kopf. Den finanziellen Schaden beziffert das Unternehmen auf einen zweistelligen Millionenbetrag. Mittlerweile sortiert Christoph Möltgen als Chief Transformation Officer die Otto-IT neu. Eine einzelne, zentrale Plattform wird es dabei nicht geben.

3. Elektronische Gesundheitskarte: Ein Millionengrab

Eine elektronische Versichertenkarte, auf der alle relevanten Informationen zur Gesundheit des Patienten gespeichert sind, sollte die Behandlung effizienter und billiger machen und außerdem die Arbeit der Ärzte erleichtern. Der Beschluss dazu ist zehn Jahre alt. Das Vorhaben hat bisher über 700 Millionen Euro an Beitragsgeldern gekostet. Einzig erkennbares Ergebnis: Die Versichertenkarten tragen neuerdings ein Foto. Die Schuld für das Desaster schieben sich Krankenkassen und Ärzteverbände gegenseitig zu. Die Zukunft des Projekts ist mehr als ungewiss.

4. Berlin: Keine elektronische Akte für die Strafjustiz

Modesta lautete der Projektname der geplanten elektronischen Akte für die Strafjustiz in Berlin. Nach sieben Jahren musste das Ganze ohne angemessenes Ergebnis gestoppt werden. Der Landesrechnungshof hatte in seinem Bericht von "grundlegenden Fehlern" der beteiligten Behörden gesprochen. Gar nicht modest waren die Kosten des Desasters. Die finanziell ohnehin klamme Hauptstadt hat mit dem Projekt 8,5 Millionen Euro versenkt.

5. Keine Gesichtserkennung beim KSC

Ein weiteres Beispiel für missglückte Kommunikation liefert ein Feldversuch in Karlsruhe. Der Fußballverein 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, im Vorfeld nicht über Hintergründe und Details des Projekts zu informieren.

6. Fehlende Akzeptanz für Funktechnik NFC

Banken wünschen sich seit Jahren, dass Kunden häufiger bargeldlos bezahlen. Dazu braucht es vor allem Vertrauen. Die von der Finanzbranche gelobte Funktechnik NFC (Near Field 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 Informationen der letzten 15 Abbuchungs- und Rückbuchungstransaktionen mit Datum, Zeit, Händlerkartennummer, gezahltem Betrag und vielem mehr ganz einfach auszulesen.

7. Kalifornien: Keine Personalverwaltung durch SAP

Der US-Bundesstaat Kalifornien legte die Kooperation mit SAP auf Eis. Mit dem Projekt sollte die Personalverwaltung für alle festen und freien Mitarbeiter des Staates erneuert werden. Nachdem 254 Millionen Dollar verbrannt waren, trat Kaliforniens Finanzchef John Chiang auf die Bremse. Er bemängelte, dass es keinen einzigen fehlerfreien Abrechnungslauf gegeben habe. 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 zu Ende gedacht

Ursprünglich als JobCard gestartet, sollte das elektronische Entgeltnachweis-Verfahren der Agentur für Arbeit und weiterer Einrichtungen Arbeitnehmerdaten mit Hilfe 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ächendeckende Verbreitung von Signaturkarten würde aus Datenschutzgründen noch Jahre auf sich warten lassen.

9. DaZu: Politik der offenen Hände

Anfang Februar 2013 stoppte das schweizerische Bundesamt für Umwelt (Bafu) das IT-Projekt "Datenzugang für Umweltdaten" (DaZu). Die Berner Zeitung berichtete, das Projekt habe "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 schweizerische 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 sieben 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. (pg)

Hürde 1: Unternehmensstrategie fehlt
Das wichtigste Hindernis für die erfolgreiche Einführung einer ERP-Software liegt in der unternehmerischen Denkweise selbst, genauer gesagt in einer nicht vorhandenen oder nicht genügend durchdachten Unternehmensstrategie.
Hürde 2: ERP-Strategie fehlt
Nur eine langfristige ERP-Strategie erlaubt es, die Software optimal zu nutzen und deren Erfolg für die nächsten Jahre sicher zu stellen.
Hürde 3: IT Strategie passt nicht zur Unternehmensstrategie
Ein weiterer Fehler ist die fehlende Anpassung der IT-Strategie an die sich verändernde Unternehmensstrategie.
Hürde 4: Analysephase wird unterschätzt
Ein potentieller Schwachpunkt ist auch die Analyse eines ERP-Projekts. Diese Phase setzt voraus, dass sich ein Unternehmen der eigenen Geschäfts- und IT-Strategie bewusst ist. Doch häufig ist den Verantwortlichen nicht klar, warum sie die ERP-Lösung im tieferen Sinne einsetzen und welche Schritte dazu notwendig sind.
Hürde 5: Zeitbedarf des ERP-Projekts wird zu gering angesetzt
Ein weiterer möglicher Schwachpunkt ist der Zeitbedarf des ERP-Projekts. Er wird nicht selten zu gering angesetzt. In der Folge entfallen zum Beispiel unbedingt notwendige Testphasen, da der zu diesem Zeitpunkt bereits entstandene Termindruck zu groß geworden ist.
Hürde 6: Controlling wird vernachlässigt
Viele Mittelständler haben keine Vorstellung von dem zeitlichen und finanziellen Aufwand, der für das Controlling, die Überwachung und das Management eines ERP-Projektes nötig ist. Zwischen 10 und 20 Prozent eines Projektvolumens entfallen auf diese Dienstleistungen.
Hürde 7: Fehlende Unterstützung der Geschäftsführung
Die Geschäftsführung sollte die Projektverantwortlichen während der Projektlaufzeit von ihrer eigentlichen Tätigkeit ganz oder teilweise freistellen und unterstützen. Werden Mitarbeiter zu wenig entlastet und müssen sie die zusätzliche Arbeit im Zuge der ERP-Einführung neben dem Tagesgeschäft erfüllen, führt dies zwangsläufig zu Überforderung und Unmut.
Hürde 8: Datenmigration schlecht vorbereitet
Ein Thema, das bei der Neueinführung von ERP-Software gerne unterschätzt wird, ist die Datenmigration. Denn sie beschränkt sich nicht allein auf die Übertragung der Altdaten vom bisherigen IT-System auf die neue Lösung. Zuvor müssen die alten Daten gezielt aufbereitet werden.
Hürde 9: ERP-Projekt wird nicht methodisch angegangen
Jedes Projekt sollte methodisch abgewickelt werden – von der Analyse über das Angebot, den Vertrag, der die Leistung beschreibt, bis hin zum Projekt selbst.