Warum IT-Projekte scheitern und was Klarheit und Organisationsstruktur gemeinsam haben

Das unterschätzte Problem – Scheitern, obwohl alles da ist

Es gibt ein Phänomen, das ich in meiner Arbeit immer wieder beobachte: IT-Projekte geraten ins Stocken, obwohl Kompetenz, Motivation und Ressourcen vorhanden sind. Die Gründe scheinen oft nicht dramatisch, zumindest auf den ersten Blick – und wenn man es nicht anders kennt.

Beispiel 1: Der Fachbereich liefert keine Grundlage

Ein Fachbereich beauftragt die IT mit einer Lösung. Keine Beschreibung der Ausgangslage, keine konkreten Anforderungen, keine Vorstellung davon, wie das Projekt angegangen werden soll. Es folgen wochenlange Vorklärungsrunden. Die IT fragt, der Fachbereich antwortet vage. Niemand kann klären, wie man ressourcenseitig einplanen soll. Schließlich einigt man sich auf eine Vorstudie – ein Kompromiss, der eigentlich keiner ist.

Der Fachbereich ist unzufrieden. Er wollte sofortige Umsetzung, nicht noch eine Analyse. Er beteiligt sich während der Vorstudie kaum. Die IT liefert die Konzeptbausteine am Ende allein. Und dann, beim nächsten Schritt, beginnt das Spiel von vorne: Wieder sind Klärungen nötig, weil unklar bleibt, was im Detail gebraucht wird. Der Fachbereich eskaliert massiv. Die IT liefert nicht, heißt es. Dabei hat die IT genau das getan, was möglich war – ohne Grundlage.

Beispiel 2: Die IT hält die Klärung für überflüssig

Eine IT-Organisation soll im Rahmen einer Akquisition mehrere Organisationseinheit auf ihr bestehendes zentrales IT-System integrieren. Nach monatelanger Vorab-Diskussion, welche Organisation zuerst integriert wird, soll es nun endlich losgehen. Die vorgeschlagene, intensive gemeinsame Betrachtung der Organisation, ihrer Produkte, Prozesse und Systeme wird abgelehnt. Zu aufwändig, zu langsam.

Die IT ist überzeugt: Man muss sich die neue Organisation nicht genauer anschauen. Man betreibt das System schon lange, man weiß, was gebraucht wird. Mehrere IT-Teams sprinten einzeln los. Sie stellen oft dieselben Fragen. Manche gewinnen kritische Erkenntnisse erst Monate später – Erkenntnisse, die andere längst hatten. Das Projekt eskaliert mehrfach. Kritische Dinge werden zu spät erkannt. Die Projektlaufzeit verlängert sich um ein Vielfaches.

Das gemeinsame Muster

Diese beiden Fälle sind keine Gegenpole. Es sind zwei Varianten derselben Grundstörung: fehlende oder unzureichende Anforderungs- und Prozessklärung vor oder während des Projektstarts. Im ersten Fall liefert der Fachbereich keine Grundlage. Im zweiten Fall hält die IT die gemeinsame Klärung für überflüssig. Egal wer die Klärung versäumt – das Ergebnis ist dasselbe: verzögerte, eskalierende Projekte mit schlechten Resultaten.

Es gibt einen verbreiteten Gedanken, dass zu viel Analyse Projekte bremst. Das ist wahr – wenn man sich in endloser, unsystematischer und unstrukturierter Diskussion verliert. Aber das eigentliche, weit häufigere Problem ist zu wenig Klärung, nicht zu viel.

Zwischenfazit: Projekte scheitern nicht, weil zu viel geklärt wird. Sie scheitern, weil die notwendige Klärung nicht stattfindet – oder weil eine Seite sie für überflüssig hält. Klarheit am Anfang kostet Zeit. Fehlende Klarheit kostet Monate.

Zwei Arten, den Start ineffizient anzugehen

In vielen mittelständischen IT-Projekten sehe ich ein wiederkehrendes Muster: Zeit und Kapazität sind knapp, ein weiteres Projekt kommt obendrauf, und man beginnt direkt mit der Umsetzung. Der Einstieg gelingt scheinbar mühelos, das vermeintlich agile Vorgehen wird gefeiert – bis mittendrin auffällt, dass grundlegende Fragen nie beantwortet wurden. Damit sind wir im Kern wieder beim Muster aus dem vorherigen Kapitel: Für die Klärung fehlt die Zeit, sie wird übersprungen, und die Rechnung dafür kommt später.

Bei größeren Konzernen habe ich häufig das Gegenteil beobachtet. Dort wird vor dem eigentlichen Projektstart so ausführlich analysiert und abgesichert, dass sich der Beginn der eigentlichen Arbeit spürbar nach hinten verschiebt. Auch diese Erfahrung kenne ich aus eigenen Projekten – und sie ist nicht weniger problematisch als das hastige Loslegen im Mittelstand, nur mit umgekehrten Vorzeichen.

Bemerkenswert finde ich, dass beide Seiten ihr jeweiliges Vorgehen für das effektivere halten. Im Mittelstand gilt Tempo als Tugend, weil schlicht keine Kapazität für ausführliche Vorarbeit übrig ist. Im Konzern gilt Absicherung als Tugend, weil Fehler dort teurer und öffentlicher werden. Beide Haltungen sind nachvollziehbar, ziehen aber enorme Ineffizienzen nach sich.

Der eigentliche Unterschied liegt aus meiner Sicht nicht in der Menge der Analyse, sondern in ihrem Gegenstand – dem Wert aus Kundensicht. Zu schnelles Loslegen und zu langes Absichern laufen letztlich an derselben Stelle vorbei: an der Frage, was vor dem Start tatsächlich geklärt sein muss. Wer diese Frage präzise beantwortet, braucht weder das eine noch das andere Extrem.

Zwischenfazit: Zu schnell starten und zu lange absichern sind zwei Varianten desselben Problems. Die Menge an Analyse ist nicht das Problem – die fehlende Klarheit darüber, was der Kunde benötigt (Wert) und was wirklich geklärt sein muss, schon.

Wenn viel passiert und trotzdem wenig Wert entsteht

Ein kurzer Abstecher in die Welt des Lean Managements. Lean kennen die meisten aus der Produktion – Lean Manufacturing. Aber der Blick lohnt sich auch für Projektteams, denn im Kern geht es um zwei Fragen: Liefern wir, was unsere Kunden (intern wie extern) wirklich brauchen? Und tun wir das ohne unnötige Arbeit? Beides klingt selbstverständlich. Ist in der Praxis aber schwieriger als gedacht.

Wer einen Blick in die vollen Kalender vieler Projektbeteiligter wirft, stellt fest: An Informationsaustausch mangelt es selten. Status-Meetings, Abstimmungen, Eskalationen, Problemlösungsrunden – der Austausch findet statt, und zwar reichlich. Die eigentliche Frage ist eine andere: ob dieser Austausch das Richtige erreicht.

Das ist der Punkt, an dem viele Projekte sich selbst täuschen. Volle Kalender fühlen sich nach Fortschritt an. Man ist beschäftigt, man tauscht sich aus, man löst Probleme – und trotzdem bewegt sich das eigentliche Ziel kaum. Aktivität und Wertschöpfung sind zwei unterschiedliche Dinge, und in der Praxis werden sie zu selten auseinandergehalten.

Unnötige Arbeit entsteht dabei nicht zwangsläufig nur, weil am Anfang etwas versäumt wurde. Sie entsteht auch, wenn während der Umsetzung nicht laufend geprüft wird, ob die aktuelle Arbeit noch zu dem beiträgt, was tatsächlich gebraucht wird. Ein Projekt kann sauber gestartet sein und trotzdem im Verlauf an Wert verlieren, wenn diese Prüfung ausbleibt. Umgekehrt kann ein holpriger Start noch korrigiert werden, wenn im weiteren Verlauf konsequent nach dem tatsächlichen Bedarf gefragt wird. Die Lean-Frage ist also keine Frage, die man einmal am Anfang stellt und dann abhakt. Sie begleitet ein Projekt bis zum Ende.

Zwischenfazit: Viel Aktivität ist kein Beleg für Wertschöpfung. Entscheidend ist, ob laufend geprüft wird, ob die Arbeit noch dem tatsächlichen Bedarf dient – nicht nur, ob am Anfang alles geklärt war.

Integriertes Projektmanagement als roter Faden

Klarheit hält sich nicht von allein. Sobald das Projekt läuft, verschieben sich Prioritäten, neue Anforderungen tauchen auf, Beteiligte interpretieren den ursprünglichen Rahmen unterschiedlich – und wenn niemand aktiv gegensteuert, verliert das Projekt Stück für Stück den Bezug zu dem, was einmal vereinbart wurde. Das passiert selten spektakulär. Es ist der Normalzustand, sobald diese Steuerung fehlt.

Aus den geklärten Anforderungen wird dann meist zügig eine Roadmap mit Meilensteinen, Arbeitspaketen und Terminen. Das ist naheliegend und auch richtig – nur reicht ein guter Plan allein nicht aus. Ich habe Projekte gesehen, deren Zeitplanung nahezu lehrbuchhaft aussah und die trotzdem ins Straucheln gerieten, weil die Organisation dahinter nicht zum Projekt passte.

Was also tun? Meine Grundüberzeugung dazu ist einfach: Wer im täglichen Prozess Hand in Hand arbeitet, sollte das auch im Projekt tun. Die Prozessanalyse vom Projektstart ist damit mehr als nur Grundlage für Anforderungen – sie liefert zugleich die Blaupause dafür, wie das Projektteam aufgestellt sein sollte. Nehmen Sie ein Beispiel aus der Praxis: Wenn Vertrieb, Auftragsabwicklung und Logistik im Tagesgeschäft denselben Prozess durchlaufen, aber im Projekt getrennt in eigenen Arbeitspaketen sitzen und sich nur über Statusberichte austauschen, geht genau das verloren, was den Prozess im Alltag funktionieren lässt: das direkte Verständnis dafür, wie die eigene Arbeit auf die der anderen wirkt.

Deshalb sollte sich die Projektorganisation am Prozess orientieren – Ende-zu-Ende – und nicht am Organigramm. Relevante Bereiche gehören von Beginn an eingebunden, nicht erst, wenn ihr Teilbereich an der Reihe ist. Und Fachbereich und IT sollten parallel und gemeinsam arbeiten, nicht nacheinander – erst die Fachlichkeit, dann die technische Umsetzung als getrennte Phasen funktioniert in der Praxis selten reibungslos. Dazu gehört auch ein ehrlicher Vertrauensvorschuss auf beiden Seiten. Die IT blockt in der Anforderungsklärung oft früh ab – meist aus Sorge, sich auf schlechte oder stark vom Standard abweichende Lösungen festzulegen. Hilfreicher ist es aus meiner Sicht, zunächst offen zuzuhören, was gebraucht wird, und Prioritäten und Leitplanken erst im zweiten Schritt gemeinsam zu klären. Ist auch der Fachbereich dafür offen, gewinnen beide: Der Bedarf wird verstanden, bevor er konstruktiv begrenzt wird.

Wenn die Ende-zu-Ende-Logik greift, zeigt sich ein Effekt, den viele unterschätzen: Die Ausrichtung im Projekt bleibt über die gesamte Prozesskette hinweg konsistent, nicht nur innerhalb einzelner Teams. Bereiche, die vorher im Prozess liefern, mittendrin arbeiten oder das Ergebnis später übernehmen, sind gleichermaßen eingebunden – mit der Folge, dass Übergaben sauberer laufen und Missverständnisse seltener werden. Abstimmung wird damit zu etwas, das im Projektalltag mitläuft, statt nur bei Bedarf einberufen zu werden.

Meine Schlussfolgerung: Eine systematische Klärung vor Projektbeginn birgt ein enormes Potenzial zur Steigerung der Ressourceneffizienz. Aber ein guter Start allein trägt ein IT-Projekt nicht bis zum Ende, wenn die Struktur dahinter nicht mitzieht. IT-Projekte scheitern selten an einem einzelnen großen Fehler. Sie scheitern eher an mehreren kleinen Unklarheiten, die zu lange unbeachtet bleiben – bei der Klärung zu Beginn, bei der laufenden Prüfung des Wertbeitrags und bei der Organisation, die darüber entscheidet, ob die anfängliche Klarheit im weiteren Verlauf überhaupt Bestand hat. Die Klarheit für den Projekterfolg erfordert daher eine stabile Projektorganisation – ein System basierend auf den Projektanforderungen.

Bonus: 4 Leitfragen für Klarheit in Ihrem IT-Projekt

Dieser Abschnitt lässt sich unabhängig vom restlichen Artikel nutzen – als Ausgangspunkt für ein Gespräch im eigenen Projektteam.

1. Was muss vor dem Start wirklich geklärt sein?
Nicht die Anzahl der Abstimmungstermine entscheidet, sondern der Inhalt: Ist die Ausgangslage beschrieben? Wie lässt sich die Ausgangslage messen (zur Wirksamkeitsprüfung nach Implementierung)? Sind Anforderungen zumindest in Grundzügen greifbar? Wenn diese Fragen offen sind, hilft weder schnelles Loslegen noch endloses Vorab-Analysieren – beides ersetzt die eigentliche Klärung nicht.

2. Woran erkennen Sie, dass sich Umfang, Ziel oder Anforderungen im laufenden Projekt verschoben haben?
Drift passiert leise. Ein Signal dafür ist, wenn Entscheidungen getroffen werden, die vom ursprünglichen Rahmen abweichen, ohne dass diese Abweichung im Team offen benannt wird.

3. Welche laufende Arbeit trägt tatsächlich zum benötigten Ergebnis bei – und welche nicht?
Volle Kalender und viele Abstimmungen sind kein verlässliches Zeichen für Fortschritt. Die Frage ist, ob der jeweilige Austausch dem eigentlichen Ziel dient oder ob er sich verselbstständigt hat.

4. Arbeiten die relevanten Bereiche entlang der relevanten Prozesse (Ende-zu-Ende) zusammen – oder noch entlang des Organigramms?
Wer im Tagesgeschäft im selben Prozess zusammenarbeitet, sollte das auch im Projekt tun. Wenn vorgelagerte, ausführende und nachgelagerte Bereiche getrennt voneinander eingebunden werden, geht genau die Abstimmung verloren, die Übergaben und Ergebnisse später stabil macht.

Klarheit entsteht nicht an einer einzigen Stelle im Projekt. Sie muss zu Beginn geschaffen, während der Umsetzung geprüft und durch die richtige Organisation über die Zeit gehalten werden. Wo genau Ihr Projekt gerade steht, entscheidet oft darüber, ob es am Ende First Time Right läuft – oder mehrere Male nachgebessert werden muss.