40 % IT-Budget: Was Anforderungsfehler Unternehmen wirklich kosten
Ihr Entwicklungsteam liefert pünktlich, im Budget und baut trotzdem das Falsche. Studien zeigen: 30 bis 50 % jeder Entwicklungsstunde ist Rework. Der Fehler passierte nicht im Sprint. Er passierte sechs Monate früher, im Anforderungsprozess.
Dieser Beitrag erklärt, warum das kein Einzelfall ist, sondern ein strukturelles Problem und was Unternehmen tun, die es gelöst haben.
Der Fehler passiert vor dem Sprint — nicht darin
Wenn ein IT-Projekt Millionen verbrennt oder Monate zu spät fertig wird, wird fast immer die Entwicklung verantwortlich gemacht. Das ist das falsche Bild.
Der eigentliche Fehler passiert sechs Monate früher. Eine Anforderung kommt unklar aus dem Fachbereich. Sie wird unvollständig dokumentiert. Sie geht so ins Refinement. Das Entwicklungsteam baut, was es versteht, nicht was gemeint war. Zwei Wochen später stellt der Fachbereich fest: Das haben wir so nicht gemeint.
Diesen Moment gibt es in jedem Unternehmen, das keine strukturierten Anforderungsprozesse hat. Täglich.
Laut einer Analyse des IBM Systems Sciences Institute entstehen 80 % der Projektnacharbeit durch Fehler, die in der Anforderungsphase gemacht wurden, nicht in der Entwicklung.
Das Budget ist dann längst verbrannt. Der Vorwurf trifft das falsche Team. Und der Anforderungsprozess bleibt unverändert.
Warum Rework so teuer ist: Die versteckte Rechnung
Rework ist kein Randproblem. Es ist der größte versteckte Kostenfaktor in der IT-Entwicklung — und er erscheint in keiner Budgetposition.
Wenn eine User Story im Refinement zurückkommt, weil Akzeptanzkriterien fehlen, entstehen mehrere Kostenpositionen gleichzeitig:
- Der Requirements Engineer überarbeitet die Story: 30–60 Minuten
- Das Entwicklungsteam wartet oder arbeitet an anderem weiter: Kontextwechsel, Verzögerung
- Das Refinement-Meeting wird verlängert oder wiederholt: Mehrere Personen, eine Stunde
- Die Sprint-Planung verschiebt sich: Der nächste Sprint startet mit Unklarheiten
Keine dieser Positionen erscheint als "Anforderungsfehler" im Reporting. Sie verteilen sich als Overhead auf Tickets, Meetings und Stundenbuchungen.
In Enterprise-Unternehmen mit 10 bis 20 Entwicklungsteams läuft dieser Mechanismus parallel in jedem Team — jeden Sprint, jede Woche.
Eine konservative Rechnung: Wenn 5 Teams je 3 Stunden pro Sprint mit Rework verbringen und ein Sprint zwei Wochen dauert, summiert sich das auf über 300 Stunden pro Quartal. Und das nur durch unklar formulierte Anforderungen.
Das eigentliche Problem: Die Rolle ist strukturell überlastet
Irgendwo zwischen Fachbereich, Management und Entwicklungsteam sitzt eine Person — oder ein kleines Team. Requirements Engineer, Business Analyst, Product Owner.
Diese Rolle soll gleichzeitig:
- Den Fachbereich verstehen und übersetzen (Domänenwissen: Versicherungsrecht, Kreditprozesse, Fahrzeugsicherheit)
- Mit der IT kommunizieren (Jira, Systemarchitektur, Sprint-Logik)
- Das Management mit KPIs und Statusberichten versorgen
- Externe Partner steuern (Softwarehäuser, Dienstleister, Berater)
- Compliance sicherstellen (DORA, EU AI Act, ISO 27001 — auditierbar dokumentiert)
- Das Wissen der gesamten Organisation tragen — weil es nirgendwo sonst steht
Diese Rolle ist strukturell nicht skalierbar. Eine Person, sechs gleichzeitige Anforderungen. Jedes neue Projekt erhöht die Last. Neue Teammitglieder müssen mühsam eingearbeitet werden. Wer gut schreibt, hat gute Tickets — wer das Unternehmen verlässt, nimmt das Wissen mit.
Führungskräfte, die dieses Systemproblem als ein solches erkennen, suchen keine besseren Requirements Engineers. Sie suchen ein System, das die Abhängigkeit von einzelnen Personen reduziert.
Was Unternehmen tun, die Rework systematisch reduzieren
Unternehmen, die Rework messbar senken, lösen das Problem an der Wurzel: im Moment der Anforderungsaufnahme, nicht im Refinement.
Qualitätsprüfung vor dem Meeting, nicht danach
Das Refinement-Meeting ist zu spät für Qualitätssicherung. Wenn eine Story dort zurückkommt, ist der Schaden bereits entstanden. Unternehmen, die das erkannt haben, setzen auf einen Quality Gate vor dem Meeting: eine automatisierte Prüfung, ob Akzeptanzkriterien vollständig sind, ob die Definition of Ready erfüllt ist, ob Widersprüche bestehen.
Der Requirements Engineer sieht den Score und die fehlenden Punkte — bevor die Story überhaupt ins Refinement geht. Rework-Runden sinken, weil Fehler früher gefunden werden.
Anforderungsaufnahme aus rohem Input
Der teuerste Moment im Anforderungsprozess ist die Übertragung. Ein 90-Minuten-Meeting mit dem Fachbereich endet mit handschriftlichen Notizen. Danach: 60 Minuten Dokumentation in Jira, 30 Minuten Confluence-Update, 20 Minuten Abstimmung per E-Mail.
Der strukturierte Intake — Meeting-Transkript, PDF, Slack-Nachricht direkt in strukturierte Anforderungen überführen — eliminiert diesen Übertragungsschritt. Was bisher 2 Stunden Dokumentationsarbeit war, dauert Minuten.
Wissen im System, nicht in Köpfen
Wenn eine erfahrene Requirements Managerin das Unternehmen verlässt, ist das Wissen über Prozesse, Entscheidungshistorie und Stakeholder-Kontext weg. Nicht im System, nicht in Confluence — im Kopf der Person.
Unternehmen, die das Problem strukturell lösen, bauen ein institutionelles Organisationsgedächtnis: Jede Anforderung, jede Entscheidung, jede Prozessänderung ist mit Timestamp, Autor und Begründung gespeichert. Ein neues Teammitglied findet den Kontext einer Epic aus dem Vorjahr in Sekunden und nicht nach 30 Minuten Suche in Jira und Confluence.
Was das für Ihre Abteilung bedeutet
Rework ist kein Qualitätsproblem, das sich mit besseren Mitarbeitenden löst. Es ist ein Strukturproblem, das mit besseren Systemen gelöst wird.
Der erste Schritt ist die Diagnose: Wie viel Prozent der Entwicklungsarbeit in Ihrer Organisation ist Rework? Wie viele Stunden verbringt Ihr Requirements-Team wöchentlich mit Dokumentation, die zwei Tage später veraltet ist? Wie hoch ist die Abhängigkeit von einzelnen Personen, die das institutionelle Wissen tragen?
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.
