Dein IT-Projekt wird statistisch gesehen scheitern

Die Szene, die niemand will

Du hast gerade 2 Millionen für ein neues System bewilligt. Das Projekt sollte in 18 Monaten live gehen. Beste Leute, klarer Plan, alle motiviert.

14 Monate später: 800.000 über Budget. Sechs Monate Verzögerung. Der CEO fragt, warum niemand das früher gesehen hat.

Das ist nicht deine Schuld. Das ist die Norm.

Die Standish Group analysiert seit 30 Jahren IT-Projekte. Die Ergebnisse? Bemerkenswert konsistent - und bemerkenswert deprimierend. 70% scheitern oder verfehlen ihre Ziele massiv.

Das sind keine Einzelfälle. Das ist ein systematisches Problem.

(Die gute Nachricht: Es ist lösbar.)

Warum Projekte sterben

Nach Hunderten von Projekten, die wir begleitet haben, sehen wir immer wieder die gleichen Muster.

Chaotische Anforderungen

Das Projekt startet. Der Business-Besitzer kennt sein Problem, aber kann es nicht präzise beschreiben. Die IT versucht, Gedanken zu lesen.

Sechs Wochen später verstehen beide völlig verschiedene Dinge.

Dann kommt Scope Creep: "Moment, das brauchten wir auch noch." "Ach ja, das auch." Am Ende baust du etwas anderes - grösser, komplexer, teurer.

Unklare Anforderungen verursachen 40% der Projektverspätungen. Die grösste Einzelursache.

Fehlende Executive-Unterstützung

Das Projekt braucht Entscheidungen. Schnell. Der Sponsor ist beschäftigt. In fünf anderen Projekten. Niemand gibt das Go für kritische Entscheidungen.

Das Projekt bremst auf 30% Geschwindigkeit.

Bei Projekten mit aktivem Sponsor: 70% Erfolgsrate. Ohne: 30%.

Unrealistische Zeitpläne

"Für den grossen Kunden brauchen wir das in 6 Monaten."

Das Projekt ist eigentlich ein 12-Monats-Projekt. Aber der Druck ist enorm. Die Schätzung wird "angepasst". Jeder weiss, dass sie unrealistisch ist. Niemand sagt es laut.

Sechs Monate später: 60% fertig. Panic-Mode. Überstunden. Bugs, die nicht getestet sind.

Projekte mit "accelerated timelines" haben 3x höhere Fehlerquote.

Das falsche Team

Du hast Java-Entwickler. Das Projekt ist eine Cloud-Migration zu AWS mit Kubernetes. Keiner hat das je gemacht.

Oder: Du hast Entwickler, aber keinen Product Owner, der Zeit für Fragen hat. Der Designer ist für fünf Projekte verantwortlich.

Unzureichende Skills kosten 1-3 Wochen pro Quartal an Rework.

Kommunikation, die nicht funktioniert

Das Team sitzt nicht zusammen. Business und IT sprechen verschiedene Sprachen. Der Status-Report kommt freitags - aber keiner weiss wirklich, was "gelb" bedeutet.

Ein grosses Problem wird bemerkt. Die Info geht zum Tech Lead. Dann zum Projektmanager. Dann zum Sponsor. Sechs Tage später wird ein Notfall-Call angesetzt.

Kommunikationsprobleme verursachen 30% der Verspätungen.

Was die erfolgreichen 30% anders machen

Die Projekte, die funktionieren, sind nicht von schlaueren Leuten. Sie haben bessere Systeme.

Anforderungen vor dem Start klären

8-10% des Budgets in die Requirements-Phase. Das ist keine Verschwendung - das ist Versicherung.

Workshops mit allen Stakeholdern. Dokumentation in einem System, nicht in Emails. Scope-Freeze-Punkt definieren. Danach: Change Request mit expliziten Kosten.

Einen echten Sponsor haben

Nicht jemand, der das Projekt startet und dann verschwindet. Jemand, der monatlich Zeit investiert. Der Blockaden entfernt. Der Entscheidungen trifft.

Das ist nicht optional. Das ist Voraussetzung.

Realistisch planen

Drei-Punkt-Schätzungen: optimistisch, wahrscheinlich, pessimistisch. 30-40% Kontingenz bei komplexen Projekten.

"Nein" zu unrealistischen Deadlines sagen. Oder den Scope verhandeln. "6 Monate? Klar - aber dann MVP mit Phase 2."

Das richtige Team zusammenstellen

Nicht zusammengepuzzelt. Für ein AWS-Projekt: Ein AWS-zertifizierter Architect. Mindestens ein erfahrener Cloud-Engineer.

Product Owner mit mindestens 30% Zeit. Nicht 5%.

Täglich kommunizieren

15-Minuten-Standups. Was machst du heute? Worin steckst du fest?

Wöchentliche Syncs zwischen Business und Tech. Was haben wir erreicht? Wo sind Überraschungen?

Klare Eskalationspfade. Wenn ein Blocker länger als zwei Tage dauert, geht es nach oben.

Der häufigste Fehler

Der grösste Fehler, den wir sehen: Hoffen, dass es schon gut geht.

Kein Risk Register. Keine Kontingenz. Keine Plan-B-Szenarien.

"Was, wenn die Datenbank nicht performt?" - Keine Planung.

"Was, wenn der Vendor verschwindet?" - Keine Backup-Lösung.

"Was, wenn der Senior-Developer geht?" - Kein Plan.

Projekte ohne Risikomanagement haben 45% mehr "Überraschungen".

Die erfolgreichen Projekte listen ihre Risiken auf. Bewerten sie. Haben einen Plan für den Fall, dass sie eintreten. Reviewen das monatlich.

Das ist nicht paranoid. Das ist professionell.

Wenn es schon schiefläuft

Manchmal merkst du es zu spät. Monat 8 von 18. 30% über Budget. Anforderungen chaotisch.

Ist es vorbei? Nicht unbedingt.

Ehrlich sein. Setz dich mit dem Sponsor zusammen. "Das Projekt ist in Schwierigkeiten." Klar benennen: Budget, Timeline oder Scope?

Scope-Triage. Was brauchst du wirklich? Was ist Nice-to-have? Was kann Phase 2 sein? 20-30% der Nice-to-haves streichen kann das Projekt retten.

Neu planen. Nicht mit den ursprünglichen unrealistischen Schätzungen. Sondern: Wo sind wir jetzt? Von hier, wie lange brauchen wir noch?

Das neue Baseline kann 24 Monate sein statt 18. Das ist okay. Besser vorausplanen als am Ende in Panik geraten.

Fazit

70% der IT-Projekte scheitern. Das ist eine Tatsache.

Aber sie scheitern nicht, weil die Menschen dumm sind. Sie scheitern, weil Prozesse fehlen. Weil Kommunikation kaputt ist. Weil Anforderungen chaotisch sind. Weil Risiken ignoriert werden.

Das sind alles Dinge, die du kontrollieren kannst.

Die erfolgreichen 30% sind nicht intelligenter. Sie haben bessere Systeme. Bessere Kommunikation. Klare Anforderungen. Risikobewusstsein. Echte Executive-Unterstützung.

Das kannst du auch haben. Es braucht nicht viel - aber es braucht Disziplin.

Und Ehrlichkeit. Die Bereitschaft zu sagen: "Das wird nicht funktionieren, wenn wir nicht X machen."

Wenn du dazu bereit bist, gehörst du zu den 30%.