Organization

Warum scheitern so viele IT-Projekte – und was können wir dagegen tun?

Viele IT-Projekte scheitern an schlechter Planung, unklaren Anforderungen und starren Prozessen. Der CHAOS Report zeigt, dass nur 31 % erfolgreich sind, oft wegen unrealistischer Erwartungen, fehlender technischer Expertise und falscher Budgetierung. Dieser Artikel beleuchtet die Hauptgründe für das Scheitern: vorschnelle Technologieentscheidungen, unklare Rollen, mangelnde Einbindung von Stakeholdern und interne Politik. Erfolgreiche Projekte – wie der Mars Rover von NASA oder Netflix’ Cloud-Migration – beweisen, dass iterative, flexible Entwicklung funktioniert. Die Lektion? Weniger starre Planung, mehr Tests kleiner Features und frühzeitige Einbindung der Entwickler. Für den Erfolg müssen Unternehmen auf Agilität, kürzere Budgetzyklen und kontinuierliches Lernen setzen – anstatt nur einem festen Prozess zu folgen. Passen wir uns wirklich an oder arbeiten wir nur nach Schema F?

IT-Projekte haben eine erschreckend hohe Misserfolgsquote. Laut dem CHAOS Report der Standish Group gelten nur 31 % der IT-Projekte als erfolgreich, während 50 % mit erheblichen Herausforderungen zu kämpfen haben und 19 % komplett scheitern. Häufig genannte Gründe sind schlechte Kommunikation, unklare Anforderungen und unrealistische Zeitpläne. Doch viele Lösungsansätze bleiben oberflächlich und gehen nicht auf die tieferen Ursachen ein.

Ein Blick auf andere Branchen hilft, das Problem besser zu verstehen. Großprojekte im Bauwesen, wie der Berliner Flughafen (BER) oder Stuttgart 21, zeigen ähnliche Schwierigkeiten: Planung ist enorm komplex, unerwartete Probleme treten auf, und zu viele Stakeholder treffen Entscheidungen, oft ohne eine klare Gesamtperspektive.

Aber es gibt auch erfolgreiche Projekte. Was machen sie anders? Übertragen auf die IT-Welt ergeben sich mehrere zentrale Herausforderungen.

Softwareentwicklung ist zu abstrakt

Softwareentwicklung ist schwer greifbar. In vielen Branchen treffen Fachexperten die meisten wichtigen Entscheidungen selbst. In der IT hingegen haben oft nicht die Entwickler, sondern andere Abteilungen die Entscheidungsgewalt über Technologien, Budgets und Zeitpläne.

Häufig werden technologische Entscheidungen getroffen, bevor die eigentlichen Anforderungen klar definiert sind.

Praxisbeispiel

Ein Unternehmen beschließt, dass sein neues Projekt eine Oracle-Datenbank, eine Microservices-Architektur und eine Hybrid-App nutzen soll. Die Gründe?

• Das Unternehmen ist seit Jahren Oracle-Partner.

• Microservices gelten derzeit als Best Practice in der Branche.

• Eine einzige Hybrid-App scheint effizienter als separate mobile und Web-Anwendungen.

Auf den ersten Blick mag das logisch erscheinen. Doch aus technischer Sicht könnten sich schnell Probleme ergeben:

• Eine NoSQL-Datenbank könnte für die Anforderungen besser geeignet sein.

• Microservices könnten unnötige Komplexität hinzufügen.

• Wenn 95 % der Nutzer die mobile App verwenden, könnte eine abgespeckte Webversion ausreichen.

Das bedeutet: Das Projekt startet bereits mit erheblichen Nachteilen, bevor die eigentliche Entwicklung beginnt. Ein ähnliches Problem tritt auf, wenn Projekt-Deadlines festgelegt werden, bevor auch nur eine einzige Anforderung klar definiert wurde.

Mangelnde Expertise in Schlüsselrollen

Die IT-Branche ist extrem breit gefächert, mit unzähligen Spezialisierungen. Trotzdem enthalten viele Stellenausschreibungen überzogene und unrealistische Anforderungslisten.

Beispiel einer Stellenanzeige

• Java, JEE, Spring, Spring Boot

• Angular, ULC/Swing

• JNDI, JCA, JPA, SOAP, REST, JSON, JMS, BPMN, DMN

• SQL/PLSQL, JUnit, GIT, Bitbucket, SonarQube, Jenkins, Ant, Maven

• Eigenverantwortung, Innovationsdenken, starke Kommunikationsfähigkeiten

Diese Liste kombiniert völlig unterschiedliche Fachbereiche – Java-Backend, Frontend (Angular), Kryptografie, DevOps, Datenbanken und Geschäftslogikmodelierung. Eine einzelne Person kann kaum in all diesen Bereichen tiefgehende Erfahrung haben. Trotzdem suchen Unternehmen häufig nach solchen “Alleskönnern”, anstatt ein Team aus Spezialisten mit unterschiedlichen Stärken zusammenzustellen.

Andere Branchen machen das besser. Ein Chirurg operiert nicht allein – er hat einen Anästhesisten, Assistenten und Pflegekräfte. Warum wird in der IT erwartet, dass eine Person alles abdecken kann?

Unklare Anforderungen und unzureichende Vorbereitung

Während von Entwicklern oft tiefgehendes technisches Wissen erwartet wird, sind klare und gut definierte Anforderungen nicht immer gegeben.

• Zentrale Rollen in IT-Projekten sind nicht immer mit Personen besetzt, die über tiefgreifende technische oder fachliche Expertise verfügen.

• Anforderungen sind häufig ungenau oder lückenhaft dokumentiert.

• Kritische Fragen bleiben offen, was zu Missverständnissen und Nachbesserungen führt.

Warum ist das problematisch?

Wenn Entwickler unklare User Stories erhalten, müssen sie Annahmen treffen und Lücken selbst füllen. Dies kann zu Missverständnissen, Verzögerungen und zusätzlichen Kosten führen. In gut geführten Projekten sorgt eine klare Dokumentation dafür, dass Entwickler effizient arbeiten können.

Mangelndes Feedback von Fachabteilungen

Fachabteilungen sind oft nur minimal in den Softwareentwicklungsprozess eingebunden. Viele Fachexperten haben bereits eine volle Arbeitswoche und können sich nicht intensiv um IT-Projekte kümmern.

Dadurch wird Software oft ohne ausreichendes Feedback aus der Praxis entwickelt. In vielen Unternehmen testen die Fachabteilungen die Software erst kurz vor dem Rollout – zu diesem Zeitpunkt sind Änderungen jedoch teuer und schwer umsetzbar.

Die politische Dimension von IT-Projekten

IT-Projekte sind teuer. Ein einziges Entwicklungsprojekt kann Millionen kosten, und niemand gibt dieses Budget gerne aus der Hand.

Die Verteilung von Budgets wird oft mehr durch interne Machtstrukturen und Unternehmenspolitik als durch tatsächliche technische oder geschäftliche Anforderungen bestimmt.

Häufige Fehler in der Budgetvergabe:

• Budgets werden nach interner Machtverteilung und nicht nach tatsächlichem Bedarf vergeben.

• Der günstigste Anbieter wird gewählt, auch wenn die Gesamtkosten später höher sind.

• Unrealistische Budgets führen zu billigeren Anfangsangeboten, die durch teure Change Requests später stark steigen.

In vielen Fällen erhalten nicht die besten Experten den Auftrag, sondern diejenigen mit den richtigen Verbindungen.

Erfolgreiche IT-Projekte – Was können wir daraus lernen?

Nicht alle IT-Projekte scheitern. Einige Unternehmen haben Wege gefunden, um Komplexität zu meistern und erfolgreich Software bereitzustellen.

1. Die Mars Rover Software (NASA)

NASA entwickelte die Mars Rover Software mit einem agilen Ansatz, der kontinuierliche Tests, iterative Updates und ein striktes Risikomanagement umfasste. Statt an starren Deadlines festzuhalten, setzte die NASA auf Flexibilität und schnelle Anpassungen.

2. Netflix’ Migration in die Cloud

Netflix verlagerte seine gesamte Infrastruktur in die Cloud – ein massives IT-Projekt. Doch statt einem festen Plan folgte Netflix einer schrittweisen, iterativen Migration, bei der ständig getestet und optimiert wurde. So wurde das Risiko minimiert und das System kontinuierlich verbessert.

Praktische Maßnahmen für erfolgreichere IT-Projekte

1. Entwickler frühzeitig einbinden – aber gezielt. Entwickler sollten nicht erst in der Umsetzungsphase dazugeholt werden, sondern bereits in der Konzeptionsphase mitwirken, um Fehlentscheidungen zu vermeiden.

2. Kleine, testbare Feature-Sets priorisieren. Anstatt alles auf einmal zu planen, sollten kleine Releases mit echtem Nutzen und frühzeitigem Feedback realisiert werden.

3. Budgets in kürzeren Zyklen bereitstellen. Statt langfristige Finanzierungspläne zu erstellen, sollte das Budget regelmäßig geprüft und an die Projektentwicklung angepasst werden.

4. Das Unplanbare nicht zu detailliert planen. Softwareentwicklung ist kein Bauprojekt – sie ist eher wie Forschung. Teams sollten sich iterativ und schrittweise einer Lösung nähern.

Fazit: Agil – aber mit gesundem Menschenverstand

IT-Projekte sollten flexibel, nutzerzentriert und technisch fundiert entwickelt werden, anstatt sich an starre Prozesse zu klammern.

Die wichtigste Frage lautet: Haben wir einen echten Lernprozess etabliert – oder folgen wir nur einem starren Plan?

Wer sich von der Illusion verabschiedet, dass Software vollständig planbar ist, hat den ersten Schritt zu erfolgreichen IT-Projekten bereits getan.

Blog

Aktuelle Beiträge