In den letzten Monaten werde ich wieder häufiger nach dem Pflichtenheft gefragt. Manchmal mit KI-Begründung: die KI arbeitet ja nur so gut wie ihre Spezifikation, also schreiben wir vorher alles auf.

Der erste Teil stimmt. Der Schluss daraus ist aus meiner Sicht falsch. Er war früher falsch, er ist heute falsch.

Ich habe mir dazu die Studienlage angesehen. Drei Muster kommen wieder, und für jedes gibt es belastbare Zahlen.

Geliefert wird, was gewollt war, und nicht, was gebraucht wurde

McKinsey und die Universität Oxford haben 2012 mehr als 5.400 IT-Projekte mit einem Ausgangsbudget über 15 Millionen Dollar ausgewertet. Im Schnitt lagen sie 45 Prozent über Budget und 7 Prozent über der Zeit. Sie lieferten 56 Prozent weniger Wert als vorhergesagt.

Der Wert bricht also stärker ein als das Budget überzogen wird. Das ist die Zahl, die mich an dieser Auswertung am meisten interessiert, und sie steht in der Diskussion um Termine und Kosten fast nie im Mittelpunkt.

Warum das passiert, zeigt Ronny Kohavi. Microsoft hat über Jahre kontrollierte Experimente ausgewertet und dabei gemessen, wie oft eine geplante Verbesserung die Zielmetrik tatsächlich verbessert hat. Es war ungefähr ein Drittel. Bei stark optimierten Produkten wie Bing und Google liegt die Quote nach anderen Messungen bei 10 bis 20 Prozent.

Das sind keine schlechten Teams. Das sind Leute mit Daten, mit Nutzerforschung und mit sehr viel Erfahrung. Sie liegen trotzdem in zwei von drei Fällen daneben. Ein Pflichtenheft ist ein Dokument voller solcher Vermutungen, das durch eine Unterschrift zur Wahrheit erklärt wird.

Es wird teurer, und irgendwann wird nur noch über den Change gestritten

Bent Flyvbjerg und Alexander Budzier haben 1.471 IT-Projekte untersucht. Die durchschnittliche Kostenüberschreitung lag bei 27 Prozent, aber der Durchschnitt verdeckt den Rand der Verteilung: Jedes sechste Projekt überzog im Mittel um 200 Prozent, bei fast 70 Prozent Terminüberschreitung. McKinsey ergänzt, dass jedes zusätzliche Projektjahr die Kostenüberschreitung im Schnitt um 15 Prozent erhöht. Das Pflichtenheft ist genau die Praxis, die Projekte lang macht.

Für den Streit über jeden einzelnen Change gibt es eine ökonomische Erklärung, und ich finde sie besser als jedes agile Argument, weil sie ohne agiles Vokabular auskommt. Patrick Bajari und Steven Tadelis haben 2001 im RAND Journal of Economics gezeigt, dass ein Festpreis starke Anreize setzt und genau diese Anreize den Gewinn bei der späteren Nachverhandlung wieder auffressen, weil beide Seiten unterschiedlich gut informiert sind. Ihre Empfehlung: Festpreis mit hoher Spezifikationstiefe für einfache Vorhaben, Aufwandsverträge mit geringer Spezifikationstiefe für komplexe.

Dieselben Autoren haben die Anpassungskosten später an Bauverträgen geschätzt, wo die Datenlage sauber ist. Sie liegen bei 7,5 bis 14 Prozent des Zuschlagspreises. Der Change-Streit ist im Vertrag also nicht der Ausnahmefall, er ist ein zweistelliger Prozentsatz des Preises.

Dass die Vollständigkeit vorab nicht gelingt, ist inzwischen gut dokumentiert. Die NaPiRE-Erhebung mit 228 Unternehmen aus zehn Ländern findet unvollständige oder versteckte Anforderungen als meistgenanntes Problem der Anforderungsanalyse, und in den deutschen Daten steht es mit Abstand auf Platz eins.

Einer zahlt drauf

Abhijit Banerjee und Esther Duflo haben 230 Projekte aus 125 indischen Softwarefirmen ausgewertet. Ihr Befund: Der Überlauf entsteht systematisch aus der Komplexität der Sache. Wer ihn bezahlt, hängt von der Reputation und damit von der Verhandlungsposition ab, nicht vom Vertragstext. Firmen mit besserer Reputation tragen in den meisten Fällen einen kleineren Anteil der Mehrkosten. Die beiden halten ausdrücklich fest, dass dieses Muster mit einer vernünftigen Risikoteilung nichts zu tun hat.

Wer glaubt, der Festpreis schiebe das Risiko sauber auf die andere Seite, irrt sich also in beide Richtungen. Und wer glaubt, er zahle nur im Streitfall, irrt sich auch: In den Angebotspreis ist der erwartete Streit längst eingerechnet.

Anforderungen gehören dennoch aufgeschrieben

Natürlich muss ich Anforderungen aufschreiben, aber wie ist die Frage. Der Plan ist bei mir Schritt zwei im Prozess. Gerade mit KI wandert die Denkarbeit nach vorn, weil das Modell alles baut, was ich ihm sage, auch den Unsinn.

Auch die Gegenseite hat eine Studie. Engprax hat 2024 600 Entwicklerinnen und Entwickler befragt und kommt auf 268 Prozent höhere Fehlschlagsraten bei agilen Projekten und deutlich bessere Aussichten für Projekte mit dokumentierten Anforderungen. Die Feldarbeit dauerte fünf Tage, es ist eine Meinungsumfrage mit selbst berichtetem Erfolg, und die auftraggebende Beratung verkauft die Alternative. Ich nehme trotzdem an, was darin steckt: Klar formulierte Anforderungen helfen. Das bestreite ich nicht.

Der Streit geht nicht um Sorgfalt gegen Schlamperei. Er geht um die Haltbarkeitsdauer einer Festlegung.

Ein Issue, das ich heute schreibe und morgen umsetze, ist eine Spezifikation. Ein Pflichtenheft, das im März unterschrieben und im November gebaut wird, ist eine Wette.

Ein Tipp noch: Falls jemand ein Lasten- oder Pflichtenheft vorlegt und du sollst daraus eine Schätzung machen, guck dir an, wie lange an dem Dokument geschrieben worden ist. Oft sind es Jahre, und der Grund ist, dass sich Anforderungen geändert haben. Dann frag den Kunden: „Wieso glaubst du, dass sich die Anforderungen im nächsten Jahr nicht auch ändern werden?“

---

Quellen

Alle Links führen auf frei zugängliche Fassungen, ohne Bezahlschranke und ohne Anmeldung.

• Bloch, Blumberg, Laartz: Delivering large-scale IT projects on time, on budget, and on value. McKinsey mit der Universität Oxford, 2012. Vollständiger Artikel frei lesbar: mckinsey.com
• Kohavi, Crook, Longbotham: Online Experimentation at Microsoft, 2009. PDF auf der Seite von Ronny Kohavi in Stanford: ai.stanford.edu
• Flyvbjerg, Budzier: Why Your IT Project May Be Riskier Than You Think. Harvard Business Review, 2011. Der HBR-Artikel selbst liegt hinter einer Bezahlschranke, die Autorenfassung liegt frei auf arXiv: arxiv.org/abs/1304.0265
• Bajari, Tadelis: Incentives versus Transaction Costs. A Theory of Procurement Contracts. RAND Journal of Economics 32(3), 2001. Die Zeitschriftenfassung liegt bei JSTOR hinter einer Schranke, das Arbeitspapier ist frei: papers.ssrn.com
• Bajari, Houghton, Tadelis: Bidding for Incomplete Contracts. American Economic Review 104(4), 2014. Die AER-Fassung ist kostenpflichtig, das NBER-Arbeitspapier frei: nber.org
• Méndez Fernández und andere: Naming the Pain in Requirements Engineering. Empirical Software Engineering, 2016. Autorenfassung frei auf arXiv: arxiv.org/abs/1611.10288
• Banerjee, Duflo: Reputation Effects and the Limits of Contracting. Quarterly Journal of Economics 115(3), 2000. Die QJE-Fassung ist kostenpflichtig, das Arbeitspapier liegt frei im Repositorium des MIT: dspace.mit.edu
• Ali, J.L. Partners für Engprax: 268% Higher Failure Rates for Agile Software Projects, 2024. Mitteilung samt Datentabellen frei lesbar: engprax.com