IT-Projekte scheitern in Deutschland häufiger als den meisten Leuten lieb ist. Und zwar eher an Prozessen und der Planung als an technischen Problemen. Zu viel Vorabaufwand, zu späte Einbindung von Partnern und fehlende Klarheit über das eigentliche Warum sind die häufigsten Ursachen. Studien zeigen dass über die Hälfte aller IT-Großprojekte ihr Budget überschreiten oder nicht die geplanten Ergebnisse liefern.
Ich selbst habe in den letzten 20+ Jahren viele IT-Projekte von innen gesehen. Als Berater, als Umsetzer, manchmal als derjenige der gerufen wurde, wenn es nicht mehr lief.
Und ich kann sagen: die meisten Projekte scheitern nicht weil die Technologie falsch war. Nicht weil das Team inkompetent war. Und auch nicht weil das Budget zu knapp war.
Sie scheitern, weil gerade am Anfang viel zu viel Energie in die falschen Dinge geflossen ist. Noch Lange bevor die erste Zeile Code geschrieben wurde oder Anpassungen an einem Produkt vorgenommen wurden.
Ich habe es wirklich oft so gesehen und denke: das meiste davon ist Einstellungssache. Das Vertrauen in Dienstleister ist super niedrig, jeder will sich absichern, weil man schlechte Erfahrungen in der Vergangenheit gemacht hat. Und genau das führt direkt in den nächsten Fehler.
Woher kommt das überhaupt?
Meine Theorie: Es sind die großen gescheiterten Projekte aus der Vergangenheit. Diese müssen einfach extreme Spuren hinterlassen haben.
Ein Szenario das jeder schon mal gehört hat: 600.000 Euro Budget für eine ERP-Einführung. Am Ende wurden 1,1 Millionen ausgegeben. Das System läuft heute noch hakelig, die Belegschaft hasst es, das Management erklärt das Projekt irgendwann für abgeschlossen weil es keine andere Wahl gibt.
Was passiert danach? Panik. Jemand muss geradestehen. Das Budget ist verbrannt, das Ergebnis ist peinlich, und irgendwo im kollektiven Gedächtnis des Unternehmens brennt sich ein Satz ein: sowas darf nie wieder passieren.
Soweit verständlich, wer will das schon?
Der Fehler passiert dann aber im nächsten Schritt wieder. Die Annahme, warum das passiert ist: wir haben nicht gründlich genug geplant. Beim nächsten Mal genauer planen, noch dickere Verträge aufsetzen, noch mehr Kontrollinstanzen für mehr Sicherheit.
Also sieht das nächste Projekt dann so aus: doppelt so großes Projektteam, ein zusätzliches Audit-Gremium, noch ein externer Berater, ein 400-seitiges Lastenheft, und wöchentliche Status-Meetings in denen über Risiken geredet wird statt Probleme zu lösen. Ohne Witz: wir haben so einige Projekte begleitet, wo es mehr Projektmanager gab, als Leute die die eigentliche Umsetzung gemacht haben.
Und was passiert? Dasselbe. Nur diesmal mit 18 Monaten Laufzeit statt 12, mit noch mehr verbranntem Budget, und im Worst case einem Ergebnis das am Markt vorbeientwickelt wurde, weil die Welt sich in dieser Zeit mal wieder weitergedreht hat.
Das ist aus meiner Sicht auch kein Einzelfall, sondern ein Muster was extrem oft vorkommt.
Die Angst vor dem Scheitern treibt erst die Kosten in die Höhe. Wer Scheitern um jeden Preis verhindern will, bezahlt dafür mit Tempo, Geld und der Fähigkeit sich anzupassen.
Der Versuch alles abzusichern ist das größte Risiko
Ich verstehe den Impuls. Wer ein großes IT-Projekt verantwortet will sich absichern. Also gibt es Pflichtenhefte, Architekturdokumente, Discovery-Phasen, Risikoanalysen, Budget-Freigabeprozesse und Steering Committees. Alles mit dem Ziel, Sicherheit herzustellen.
Was dabei entsteht ist das Gegenteil. Jede zusätzliche Absicherungsstufe kostet Zeit und Budget, bevor auch nur ein einziges Problem gelöst wurde. Der Aufwand für die Absicherung wird so groß, dass das Projekt dadurch unbeweglich, langsam und fehleranfällig wird. Die Absicherung selbst wird zum größten Risiko.
Und das schlimme daran: die Anforderungen die bis ins kleinste Detail ausgearbeitet wurden sind oft bereits veraltet wenn die Umsetzung beginnt. Sechs Monate Planung für eine Welt die es so nicht mehr gibt.
Das Konzept der starren Vorabplanung stammt aus einer Zeit wo Softwareprojekte tatsächlich so komplex waren dass intensive Vorbereitung sinnvoll war. Monolithische Systeme, keine Cloud, kaum Möglichkeit schnell etwas zu testen. Heute gelten diese Prämissen kaum noch. Und trotzdem funktionieren viele Enterprise-Projekte heute noch genauso weiter.
Die Energie fließt in die falsche Richtung
Hier ist eine Sache die ich nie ganz verstehen werde.
Man baut zuerst eine gigantische Infrastruktur für die Planung, statt das eigentliche Problem zu lösen. Monatelange Discovery-Phasen, Architektur-Boards, Budget-Freigaben in drei Eskalationsstufen. In Summe verschlingen diese Prozesse mehr Ressourcen als das eigentliche Vorhaben selbst.
Die Energie die in Abstimmung, Dokumentation und Absicherung fließt fehlt an der einzigen Stelle die wirklich zählt: dem echten Problem.
Was ich stattdessen für sinnvoll halte: die meiste Energie sollte gerade am Anfang in zwei Dinge fließen.
- Erstens die Beschreibung des Problems. Nicht die Lösung, das Problem. Was ist konkret kaputt, zu langsam, zu teuer, zu fehleranfällig?
- Und zweitens das Warum. Warum macht man dieses Projekt überhaupt? Was verändert sich wenn es funktioniert? Und was passiert wenn man es nicht macht? Wer das Warum nicht klar beantworten kann, hat noch nicht verstanden was er eigentlich lösen will.
Lernt scheitern. Ernsthaft.
Scheitern ist nichts negatives. Es ist das schnellste Mittel zur Überprüfung ob man auf dem richtigen Weg ist und man lernt immer was dabei!
Wenn eine Idee, ein Feature oder ein technischer Ansatz nicht funktioniert, will ich das so schnell wie möglich wissen. Nicht nach zwölf Monaten und einer halben Million Euro Budget. Sondern viel lieber nach 20K investment In Woche drei bereits.
Deshalb bin ich ein starker Anhänger davon, früh etwas Greifbares zu bauen und es Schritt für Schritt zu testen. Der Vorteil: man sieht früh Ergebnisse und kann intern darüber reden. Feedback zu etwas das man bereits anfassen und ausprobieren kann ist ehrlicher als Feedback zu einem Anforderungsdokument, welches sich eh niemand durchlesen will (wenn man mal ehrlich ist). Und man stellt sicher, dass die späteren Nutzer sich früh damit auseinandersetzen und nicht erst am Ende des Projekts, wo eh nichts mehr geändert werden kann.
Das ist ein unterschätzter Punkt. Viele Projekte scheitern nicht weil die Lösung technisch falsch war, sondern weil niemand Lust hatte das System zu nutzen. Weil es einfach nicht das tut was die Leute wirklich brauchen. Das merkt man aber nur, wenn man früh zeigt was man baut und ehrliches Feedback bekommt. Wer das erst am Ende des Projekts tut, tut es immer zu spät und ist zwangsläufig immer damit beschäftigt das Team "wieder einzufangen", wie man so schön sagt.
Das größte Risiko eines IT-Projekts ist nicht dass es scheitert. Das größte Risiko ist, dass man es erst nach zwölf Monaten merkt, wenn das Budget aufgebraucht ist.
Ein validierter Ansatz mit 90% Budget übrig ist wertvoller, als ein gescheitertes Jahresprojekt das niemand mehr anfassen will. Und weil bis dahin schon so viel Aufwand investiert wurde, wird trotzdem weiter investiert. Man fühlt sich in einer Situation wo es keine andere Wahl gibt als das Projekt irgendwie zum Abschluss zu bringen.
Den richtigen Partner früh einbinden
Ein Unternehmen leistet monatelang Vorarbeit, entwickelt intern Anforderungen, schreibt ein Lastenheft, erstellt eine Ausschreibung, und sucht dann erst einen Partner, der die Umsetzung machen soll.
Der kommt in ein Projekt das bereits vorgedacht und vordefiniert ist. Er kann kaum noch grundlegende Fragen stellen ohne als störend zu gelten. Er soll liefern was beschrieben ist, nicht hinterfragen ob die Beschreibung richtig ist. Warum ist klar: man hat bis hierhin schon ausreichend Zeit und Energie in die Vorarbeit gesteckt. Jeder ist froh, dass diese Phase abgeschlossen ist. Was aber ist, wenn genau in der anfänglichen Ausarbeitung bereits ein Denkfehler war?
Ein Partner der von Anfang an dabei ist kann helfen das Problem richtig zu beschreiben. Er kann früh sagen wenn Annahmen nicht stimmen. Das ist sein eigentlicher Wert, nicht die Ausführung einer fertigen Spezifikation.
Aber da erst mit einer Toolauswahl auch ein Partner für eine Umsetzung ausgewählt wird, ist das ein Henne und Ei Thema.
Kommunikation ist kein Randthema
IT-Projekte scheitern auch oft an Kommunikation. Und das klingt nach einem weichen Problem, ist aber eines der härtesten.
Wenn Anforderungen zwischen Fachbereich und IT verloren gehen. Wenn niemand dem Auftraggeber sagt dass ein Ansatz nicht funktioniert weil das unangenehm wäre. Wenn Statusberichte grün zeigen bis der Crash kommt. Das sind Kommunikationsprobleme mit strukturellen Ursachen: falsche Anreize, Hierarchien die ehrliches Feedback bestrafen, niemand der den Mut hat unbequeme Wahrheiten auszusprechen.
Ich habe gelernt direkt zu sagen wenn etwas eine schlechte Idee ist. Auch wenn jemand dafür bezahlt. Das ist manchmal unangenehm. Aber es ist der einzige Weg wie ein Projekt wirklich funktionieren kann.
IT-Projekte die scheitern sind keine Katastrophen. Sie sind absolut vorhersehbar und ein Ergebnis von zu viel Komplexität.
Wenn ihr ein IT-Vorhaben plant und wissen wollt ob die Grundannahmen stimmen, redet früh mit jemandem der ehrlich antwortet. Nicht erst wenn das Lastenheft fertig ist.
— Robert
