Warum Softwareprojekte monatelang bei 90 % festhängen

„90 % fertig“ klingt so nah am Ziel, dass Nachfragen fast unhöflich wirkt, als würde man einem Team misstrauen, das beinahe durch ist. Genau deshalb ist es die gefährlichste Zahl in einem Statusbericht. Ein Projekt, das seit drei Statusberichten in Folge bei 90 % steht, beschreibt nicht mehr seinen Fortschritt. Es beschreibt eine Zahl, die niemand korrigiert hat, weil eine Korrektur bedeuten würde, etwas zuzugeben, das noch niemand laut aussprechen will.

Softwareentwickler kennen dieses Muster seit Jahrzehnten unter einem eigenen Namen: die 90-90-Regel (Ninety-Ninety Rule), geprägt von Tom Cargill von den Bell Labs. Die ersten 90 Prozent des Codes beanspruchen die ersten 90 Prozent der Entwicklungszeit, die restlichen 10 Prozent die anderen 90 Prozent.

Was steckt wirklich in den fehlenden 10 Prozent?

Die Arbeit, die in einer frühen Schätzung von „90 % fertig“ fehlt, verteilt sich immer wieder auf dieselben fünf Bereiche. Denn genau diese Bereiche sind am schwersten zu erkennen, solange die Feature-Entwicklung nicht weitgehend abgeschlossen ist.

• Integration. Einzelne Features funktionieren isoliert oft einwandfrei und scheitern im Zusammenspiel, weil die Wechselwirkungen zwischen Modulen, Services und Drittsystemen bei der ersten Schätzung nie vollständig erfasst wurden.
• Qualität. Testabdeckung, Regressionstests und Fehlerbehebung fallen dem Termindruck oft als Erstes zum Opfer. Ein Feature, das ohne ausreichende Testabdeckung als „fertig“ markiert ist, sieht im Statusbericht genauso aus wie eines, das tatsächlich geprüft wurde.
• Deployment. Ein System zuverlässig in Produktion zu bringen (mit Monitoring, Rollback-Verfahren und ausreichender Lastfähigkeit), ist eine eigene Aufgabe, unabhängig von der Entwicklung der Features.
• Sicherheit. Security Reviews, die Prüfung der Zugriffsrechte und die Compliance im Umgang mit Daten werden überdurchschnittlich oft auf „später“ verschoben, weil sie selten eine Feature-Demo blockieren.
• Abnahme. Der formale Nachweis, dass das System leistet, was das Geschäft braucht (User Acceptance Tests, Freigabe durch die Stakeholder, Betriebsdokumentation), wird oft als Erstes gekürzt, wenn eine Deadline ins Rutschen gerät.

Warum führt eine schwache Definition of Done systematisch dazu?

Wo eine Definition of Done nur als stillschweigendes gemeinsames Verständnis existiert, schrumpft sie unter Druck: leise, schrittweise und ohne dass jemand ausdrücklich beschließt, die Latte tiefer zu legen. Ein Feature, zu dem bei Projektstart noch Testabdeckung, Security Review und Dokumentation gehörten, kann am Ende ohne all das als „fertig“ gelten, weil der informelle Maßstab für „fertig“ Deadline für Deadline abgebröckelt ist.

Wie prüfen Sie, ob ein Dienstleister oder Team wirklich zu 90 % fertig ist?

Der verlässlichste Einzeltest ist zugleich der einfachste: Lassen Sie sich die konkreten restlichen 10 % heute live und lauffähig vorführen, statt sich beschreiben zu lassen, was im nächsten Sprint vorführbar sein soll. Ein Projekt, das wirklich kurz vor dem Abschluss steht, schafft das meist innerhalb von ein, zwei Tagen. Fragen Sie außerdem, in welchen der fünf Bereiche die restlichen 10 % fallen, ob sich die Schätzung der Restarbeit über die letzten Berichtszyklen verändert hat und ob es eine schriftliche Definition of Done gibt, an der die Restarbeit gemessen wird.

Ein Projekt, das monatelang bei 90 % feststeckt, befindet sich oft schon in der Risikozone, in der Projekte das Geschäft gefährden, und wird trotzdem bis zum letzten Moment als fast fertig gemeldet.