Softwareprojekte: Warum pünktliche Lieferung kein Erfolgskriterium mehr ist
Es ist ein Montag im März. Das Projekt läuft seit 14 Monaten. Das Team hat geliefert: pünktlich, im Budget, mit dem vereinbarten Funktionsumfang. Das Rollout-Meeting war gut. Der Applaus höflich.
Drei Monate später liegt die Nutzungsrate bei 23 %.
Das ist kein Einzelfall. Es ist das häufigste Muster in der Softwareentwicklung und gleichzeitig das am wenigsten diskutierte. Weil es unbequem ist. Weil es bedeutet, dass das Erfolgskriterium falsch war. Nicht die Ausführung.
Das Pünktlichkeits-Paradox: Warum Delivery nicht gleich Erfolg ist
Die Softwareentwicklung hat sich ein Jahrzehnt lang auf Delivery-Metriken konzentriert. On-time. On-budget. In-scope. Das sind die drei Kriterien, an denen Projekte gemessen wurden — in Lenkungsausschüssen, in Vorstandsberichten, in Management-Dashboards.
Das Problem: Keines dieser drei Kriterien misst, ob das richtige Produkt gebaut wurde.
Pünktlich geliefert bedeutet: Das Team hat den vereinbarten Termin eingehalten. Es sagt nichts darüber aus, ob die Nutzer das System annehmen. Im Budget bedeutet: Die genehmigten Mittel wurden nicht überschritten. Es sagt nichts darüber aus, ob der Business-Wert das Investment rechtfertigt. In-scope bedeutet: Die definierten Features wurden gebaut. Es sagt nichts darüber aus, ob diese Features die richtigen waren.
Das Ergebnis ist eine systematische Fehlmessung. Projekte gelten als erfolgreich, die faktisch scheitern, weil Nutzung, ROI und strategische Wirkung in keiner Projektmetrik auftauchen.
Was wirklich zählt: Outcome vs. Output in der Softwareentwicklung
Der Unterschied zwischen Output und Outcome ist in der Theorie bekannt. In der Praxis wird er konsequent ignoriert.
Output ist das, was geliefert wird: Features, Module, Deployments, Tickets. Output ist messbar, planbar, kontrollierbar. Deshalb wird er gemessen.
Outcome ist das, was dadurch passiert: Nutzer verhalten sich anders. Prozesse werden schneller. Kosten sinken. Umsatz steigt. Outcome ist schwerer zu messen, verzögert sichtbar und oft nicht eindeutig einem Projekt zuzuordnen. Deshalb wird er nicht gemessen.
Die Konsequenz: Entwicklungsteams werden für Output belohnt und für Outcome nicht verantwortlich gemacht. Das optimiert das System für das Falsche.
Ein Beispiel aus der Praxis: Ein Versicherungskonzern baut ein neues mobiles Kundenportal. 18 Monate. 4,2 Millionen Euro. Pünktlich geliefert. Sechs Monate nach Launch nutzen 31 % der Kunden das Portal für genau eine Transaktion: die Adressänderung. Alle anderen Prozesse laufen weiterhin über Web oder dem Callcenter.
Aus Sicht der Delivery-Metriken: erfolgreich. Aus Sicht des Business-Outcomes: ein teures Feature, das das eigentliche Problem nicht löst.
Drei Warnsignale, dass Ihr Projekt in die falsche Richtung liefert
Projekte, die auf den falschen Erfolgskriterien aufbauen, zeigen früh erkennbare Muster. Die meisten Verantwortlichen sehen sie, ohne sie korrekt zu interpretieren.
Warnsignal 1: Die Fachabteilung ist nach dem Go-live leise.
Wenn eine Fachabteilung, die monatelang auf ein System gewartet hat, nach dem Launch kaum Feedback gibt — weder positives noch negatives — ist das kein gutes Zeichen. Enthusiastische Nutzer melden sich. Frustrierte Nutzer melden sich. Gleichgültige Nutzer schweigen.
Warnsignal 2: Das System wurde gebaut, aber die alten Prozesse laufen weiter.
Parallelnutzung ist das zuverlässigste Signal für einen fehlgeleiteten Launch. Wenn das neue System da ist, aber die Excel-Tabellen trotzdem noch gepflegt werden, wurde das falsche Problem gelöst. Oder das richtige Problem falsch gelöst.
Warnsignal 3: Der ROI wird in Annahmen gemessen, nicht in Zahlen.
"Das System spart dem Team schätzungsweise 20 % Arbeitszeit" ist eine Annahme, kein Nachweis. Wenn sechs Monate nach einem Launch niemand sagen kann, was das Projekt konkret bewirkt hat — gemessen, nicht geschätzt — dann fehlt die Outcome-Verbindung von Anfang an.
Wo das Problem entsteht: Der Anforderungsprozess als strategischer Hebel
Hier wird es unbequem. Denn der Grund, warum Projekte das Falsche liefern, liegt selten in der Entwicklung. Er liegt im Anforderungsprozess, in dem Moment, in dem festgelegt wird, was gebaut werden soll.
Studien zum Thema Rework in der Softwareentwicklung zeigen ein konsistentes Bild: 30 bis 50 % der Entwicklungsarbeit in komplexen Projekten ist Rework. Also Arbeit, die gemacht wurde und dann wieder gemacht werden musste, weil die ursprüngliche Anforderung unklar, unvollständig oder falsch priorisiert war. Das Budget ist dann längst verbrannt. Das Team ist frustriert. Und der Vorstand fragt, warum das Projekt schon wieder über Zeit und über Budget läuft.
Der Prozess, in dem diese Fehler entstehen, ist erschreckend alltäglich:
Eine Fachabteilung formuliert einen Wunsch - informell, in einem Meeting, in einer E-Mail, manchmal als Randnotiz in einem PowerPoint. Ein Business Analyst oder Requirements Engineer übersetzt diesen Wunsch in Anforderungen. Nach bestem Wissen und Gewissen, aber oft ohne ausreichende Rückfragen. Diese Anforderungen werden in Jira-Tickets übertragen, verfeinert, priorisiert und dann gebaut.
Niemand in dieser Kette hat absichtlich das Falsche gebaut. Aber jede Übersetzung hat Rauschen eingebaut. Und jedes Rauschen kostet später Zeit, Geld und Akzeptanz.
Das Anforderungsmanagement ist der teuerste, unsichtbarste Engpass in der gesamten Softwareentwicklung. Weil er sechs Monate vor dem Scheitern liegt und damit weit außerhalb des Sichtfelds der meisten Projektsteuerungen.
Wie Sie als CEO die richtigen Erfolgskriterien setzen
Erfolgskriterien für Softwareprojekte sind keine technische Frage. Sie sind eine Führungsfrage. Und sie müssen beantwortet werden, bevor die erste Zeile Code geschrieben wird.
Vier Fragen, die jedes Projekt beantworten können muss, bevor es startet:
Was ist die messbare Verhaltensänderung, die wir mit diesem System anstreben? Nicht: "bessere Datenverfügbarkeit". Sondern: "Die durchschnittliche Bearbeitungszeit eines Kreditantrags sinkt von 4,5 auf 2,2 Tage." Outcome muss spezifisch, messbar und einem Zeitpunkt zugeordnet sein.
Wer sind die fünf Nutzer, die dieses System täglich verwenden werden und was verändert sich konkret in ihrem Arbeitsalltag? Systeme, die im abstrakten Raum gebaut werden, scheitern im konkreten Alltag. Die Person, die das System um 9:15 Uhr benutzt, muss vor dem Projektstart besser verstanden sein als die Architektur.
Was ist der Maximalschaden, wenn die Annahmen in den Anforderungen falsch sind? Jedes Softwareprojekt baut auf Annahmen über Nutzerverhalten, Prozessketten und Systemumgebungen. Diese Annahmen sind Risiken. Wer sie nicht explizit benennt, kann sie nicht managen.
Wie validieren wir Anforderungen, bevor sie gebaut werden? Low-Fidelity-Prototyping, Nutzer-Interviews, strukturierte Feedback-Runden — es gibt Methoden, die das Risiko falscher Anforderungen drastisch reduzieren. Wenn ein Projekt keine Validierungsschleife vor dem Build hat, ist Rework keine Möglichkeit, sondern eine Gewissheit.
Diese vier Fragen werden in den meisten Projekten nicht systematisch beantwortet weil der Druck auf schnellen Start größer ist als der Druck auf richtige Anforderungen.
Was führende Unternehmen messen, das andere ignorieren
Unternehmen, die konsistent Softwareprojekte mit echtem Business-Outcome liefern, teilen ein Muster: Sie messen den Anforderungsprozess selbst und nicht nur die Delivery.
Das bedeutet konkret: Wie hoch ist die Rework-Rate pro Sprint? Wie viele Tickets gehen aus dem Refinement zurück in die Überarbeitung? Wie lange dauert es vom ersten Fachbereichs-Input bis zur Definition of Ready? Wie viele Anforderungen werden nach Go-live als "nicht wie erwartet" zurückgemeldet?
Diese Kennzahlen sind keine Entwicklungs-KPIs. Sie sind Frühwarnsignale für Anforderungsqualität und damit für Projektoutcome.
Das Muster der führenden Unternehmen: Sie haben den Anforderungsprozess aus der informellen Zone herausgeführt. Anforderungen entstehen nicht mehr in Meetings, die niemand dokumentiert, oder in E-Mails, die niemand findet. Sie entstehen in einem strukturierten Prozess, mit klaren Qualitätsgates, mit nachvollziehbarer Herkunft, mit messbaren Kriterien für "fertig".
Der ROI eines strukturierten Anforderungsprozesses
Die unbequeme Wahrheit: Wenn Ihre Softwareprojekte das Falsche liefern, liegt die Ursache höchstwahrscheinlich nicht in der Entwicklung. Sie liegt in dem Prozess, der sechs Monate früher festlegt, was gebaut werden soll.
Pünktliche Lieferung ist kein Erfolgskriterium. Es ist eine Mindestanforderung an die Professionalität des Projektmanagements. Der eigentliche Maßstab ist: Verhält sich das System so, wie die Nutzer es brauchen? Entsteht der Business-Outcome, der dem Investment zugrunde lag? Ist das Wissen über Anforderungen, Entscheidungen und Hintergründe im System erhalten oder in den Köpfen einzelner Personen, die vielleicht längst das Unternehmen verlassen haben?
Wer diese Fragen beantworten kann, hat nicht nur ein besseres Projektmanagement. Er hat eine Abteilung, die systematisch das Richtige baut.
In vielen Unternehmen entsteht Rework nicht in der Entwicklung, sondern durch fehlende Struktur im Prozess. In einer Demo zeigen wir Ihnen, wie Sie Anforderungen, Entscheidungen und Projektwissen so strukturieren, dass weniger Rework entsteht und Ihre Projekte planbarer werden.
