Warum 9 von 10 Software-Projekten zu spät kommen

Die Statistik ist düster: nur ~30% aller Software-Projekte werden in time und in budget geliefert (Standish Group, CHAOS Report). Bei Custom-Software ist die Quote noch schlechter. Wir haben uns vorgenommen, dauerhaft auf der „guten" Seite zu sein. Hier ist, wie.

Die drei echten Gründe, warum Projekte kippen

1. Scope wird im Verlauf erfunden, nicht festgelegt

Der Klassiker. Das Projekt startet mit „eine App für Reservierungen" und wird unterwegs zu „eine App für Reservierungen, plus Loyalty, plus Kassenintegration, plus Lieferservice, plus, plus, plus". Jede einzelne Erweiterung klingt sinnvoll. In Summe schlucken sie das Projekt.

Unsere Regel: Scope wird in einem 1-Tages-Workshop festgenagelt. Was danach dazu kommt, ist Phase 2 — schriftlich, mit eigenem Preis und eigenem Datum. Kein Schmuggel.

2. Keine echte Discovery — direkt ins Designen

„Wir machen mal ein Figma" ist verlockend. Es sieht schnell schön aus. Aber Figma kann lügen — Edge Cases, Daten-Modelle, Integrationen, Rechtliches. Das alles taucht erst auf, wenn der Entwickler in Woche 3 plötzlich „wir müssen reden" sagt.

Unsere Regel: Discovery vor Design. Wir bauen erst ein technisches Skelett (Datenmodell, Auth, kritische Integrationen), dann legen wir UI drüber. Dauert 2-3 Tage länger am Anfang, spart 2-3 Wochen am Ende.

3. Zu viele Stakeholder, kein Entscheider

Vier Personen müssen das Logo absegnen. Drei davon haben verschiedene Meinungen. Niemand sagt das Logo final. Eine Woche tot.

Unsere Regel: Im Kick-off einigen wir uns auf genau eine Person als Entscheider. Die hat das letzte Wort. Andere Stimmen werden gehört, aber binden nicht. Wenn wir das nicht hinkriegen, fangen wir nicht an.

Was bei uns funktioniert hat

Beispiel Helia Health (Tele-Health-Plattform, 11 Wochen, on time, on budget):

Workshop am Tag 1, Scope schriftlich am Tag 3.

Technisches Skelett (Patient-Auth, Triage-API, PVS-Schnittstelle) bis Tag 14.

UI obendrauf ab Tag 15, Demo wöchentlich.

Entscheider: der CTO. Andere Stimmen wurden gehört, gebunden hat nur er.

Phase 2 (mehrere Praxen, White-Label) wurde während Phase 1 nicht angefasst — kein einziger Mal.

Was du daraus mitnimmst

Wenn dein nächstes Projekt zu spät kommt, liegt es selten am Code. Es liegt fast immer an einem dieser drei Fehler — die alle vor dem ersten Code passieren. Wenn du sie vermeidest, gehst du in eine andere Liga.

Termine halten ist ein Prozess, kein Glücksspiel. Wer das verinnerlicht hat, liefert ab.