Warum 9 von 10 Software-Projekten zu spät kommen
Eine ehrliche Analyse der Gründe — und unsere drei harten Regeln dagegen.
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.
Wie wir das aufsetzen
Am Beispiel einer Tele-Health-Plattform (Zielrahmen: 11 Wochen bis zur ersten Version) — so sieht der Ablauf konkret aus:
- 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.
- Ein benannter Entscheider, etwa die technische Leitung. Andere Stimmen werden gehört, binden aber nicht.
- Phase 2 (mehrere Standorte, White-Label) bleibt während Phase 1 unangetastet — konsequent, auch wenn es juckt.
Was Sie daraus mitnehmen
Wenn Ihr 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 Sie sie vermeiden, spielen Sie in einer anderen Liga.
Termine halten ist ein Prozess, kein Glücksspiel. Wer das verinnerlicht hat, hält sie auch.
Fachbeiträge per E-Mail
Wie technische Entscheidungen zustande kommen — unregelmäßig und nur dann, wenn es etwas zu berichten gibt. Jederzeit abbestellbar. Sie erhalten zuerst eine Mail mit Bestätigungslink.
Hilft das Ihrem Vorhaben weiter?
Sprechen wir 30 Minuten darüber — konkret zu Ihrem Vorhaben.
Auch lesenswert
Was vor der ersten Zeile Code feststehen muss
Die meisten Projekte scheitern nicht am Code, sondern an sechs Fragen, die niemand vorher beantwortet hat. Hier stehen sie — mit dem Grund, warum jede einzelne teuer wird, wenn sie offen bleibt.
Wie wir aus einem Chat-Widget einen Conversion-Funnel gemacht haben
Ein Floating-Chat-Widget allein konvertiert nicht. Das mussten wir lernen — und sechs Pattern nachbauen, damit aus klick-scroll-schließ ein messbarer Funnel von Open bis Erstgespräch wurde.
Ohne Zwischenstationen. Sie sprechen direkt mit der Geschäftsleitung.
Wir hören Ihnen 30 Minuten zu, stellen ein paar gezielte Fragen und sagen Ihnen am Ende offen, ob — und wie — wir Ihnen helfen können. Wenn nicht, erhalten Sie mindestens zwei Empfehlungen, wer es könnte.
- 30 Minuten, ohne Verkaufsgespräch
- Konkrete Einschätzung Ihres Vorhabens
- Klare Einordnung, welcher Projektrahmen passt