Was Kosten mangelhafte Anforderungen in Softwareprojekten?

Unabhängig von der Branche deines Unternehmens ist in der Ära der digitalen Transformation maßgeschneiderte Software ein entscheidender Faktor. Die Entwicklung einer nicht trivialen Software, sei es durch ein internes Team oder externe Dienstleister, birgt jedoch erhebliche finanzielle Risiken. Der CHAOS-Report der Standish Gruppe hat über viele Jahre hinweg Tausende von Softwareprojekten untersucht und festgestellt, dass nur etwa 31 % dieser Projekte erfolgreich abgeschlossen wurden. Davon lieferten wiederum nur die Hälfte einen hohen Mehrwert für die Anwender.

In dieser umfassenden Studie wurden unklare Anforderungen und häufige Anforderungsänderungen sowie mangelnde Zusammenarbeit mit den Anwendern als Hauptgründe für unerwartet hohe Kosten identifiziert. Wenn das Budget erschöpft ist, führt dies oft zur Einstellung des Projekts. Das Ergebnis: Das Projekt scheitert, und viel Geld ist unwiederbringlich verloren.

Investition in gute Anforderungen zahlt sich aus

Obwohl die Bedeutung guter Anforderungen seit Langem bekannt ist, wird oft am Anforderungsmanagement gespart. Doch warum eigentlich? Gute Anforderungen sind nicht ohne Kosten zu haben. Die Durchführung mehrtägiger Workshops mit internen und externen Experten für die erste Anforderungsanalyse ist nur der Anfang. In agilen Projekten wird täglich an der Verfeinerung und Ergänzung von Anforderungen gearbeitet.

Auf eine professionelle Anforderungsanalyse zu verzichten spart kurzfristig Geld, allerdings nimmt man damit ein hohes Risiko zu scheitern in Kauf.

Planung vor Umsetzung

Bevor die Entwicklung eines Softwareprodukts beginnt, ist es einfach, Anforderungen anzupassen. Die Anforderungsanalyse ermöglicht es, konkrete Diskussionen mit anderen Projektbeteiligten zu führen und voneinander zu lernen. Ideen werden formuliert, geprüft und ein konkreter Plan entsteht. Während des Projekts ist der Plan die Grundlage für Änderungen. Natürlich hat noch kein Plan den ersten Kontakt mit der Realität überstanden, trotzdem ist eine sorgfältige Planung unverzichtbar.

Je weiter das Projekt, desto teurer die Änderungen

Die Anforderungsanalyse zu Beginn des Projekts stellt die Weichen für Erfolg oder Misserfolg. Wird darauf verzichtet, entstehen später im Projekt hohe Kosten, weil sich Anforderungen drastisch ändern oder viele neue Anforderungen auftauchen. Bestehender Code wird verworfen, neuer Code muss geschrieben werden. Der Auftraggeber zahlt in diesem Fall doppelt.

Ein Modell liefert konkrete Zahlen

Mit einem einfachen Modell lassen sich die konkreten Auswirkungen schlechter Anforderungen in Zahlen fassen.

Der Sprint-Rechner der wobe-systems GmbH ermittelt, basierend auf 9 Eingangswerten, die Kosten für Softwareprojekte. Durch Experimentieren mit den Eingangswerten erhält man ein Gefühl für die Auswirkungen von zum Beispiel schlechten Anforderungen. Das Modell hat sich bereits oft bewährt, weil es die Diskussion von Meinungen auf konkrete Zahlen lenkt.

Eingangsgrößen im Überblick

Das Modell beschreibt das Projekt mit nur neun Eingangsgrößen:

Backlog SP: Die Anzahl der Story Points (SP) im Backlog ist ein Maß für den Umfang des Projekts. Wenn dieser Wert zu abstrakt ist, kann hier auch die Anzahl der geschätzten Personentage (PT) angegeben werden.

Velocity SP/D/D: Dieser Wert legt fest, wie viele Story Points pro Entickler:in pro Tag abgearbeitet werden können. Wenn keine Story Points, sondern PTs verwendet werden, steht hier der Wert 1.

Developers: Dieser Wert gibt die Teamgröße an. Zu berücksichtigen sind hier die Personen, die direkt zur Bearbeitung von SPs beitragen.

Dept to Halt: Hier wird das Konzept der technischen Schulden (Dept) eingeführt. Technische schulden sind Mängel der inneren Qualität eines technischen Produkts. Während der Umsetzung entstehen technische Schulden aus einer Vielzahl von Gründen.

Technische Schulden müssen beseitigt (zurückgezahlt) werden, weil sie sich direkt auf die Umsetzungsgeschwindigkeit auswirken. Der Aufwand dafür lässt sich ebenfalls in SPs ausdrücken. Je mehr technische Schulden angehäuft werden, desto langsamer geht das Projekt voran. Im Extremfall kann es sogar komplett zum Erliegen kommen (Halt). Der Wert gibt die technischen Schulden in SPs an, die das Projekt zum Stillstand bringen.

Debt Reduction Rate %: Der Wert gibt an, wie viel Prozent ihrer Zeit Entwickler:innen für die Reduzierung technischer Schulden verwenden.

White Noise %: Störungen und Ablenkungen der Entwickler:innen, die nicht Teil der Projektarbeit sind, können als weißes Rauschen ausgedrückt werden. Der Wert gibt an, wie viel Prozent der Zeit für die Bearbeitung von projektfremden Aufgaben eingesetzt wird.

Quality Level %: Menschen sind nicht perfekt, und gerade in der Softwareentwicklung liefert niemand von Anfang an 100 % perfekten Code. Je komplexer eine Aufgabe ist, desto häufiger wird der Code überarbeitet. Der Wert gibt an, wie viel Prozent der bearbeiteten SPs als technische Schulden (Debt) erneut Aufwand verursachen.

Requirement Quality %: Die Qualität der Anforderungen in Prozent legt fest, wie viele SPs im Verhältnis zu den abgearbeiteten Aufgaben wieder als neue Anforderungen oder als Änderungswünsche im Backlog landen. Bei einer Anforderungsqualität von 70 % landen 30 % der bearbeiteten SPs wieder im Backlog.

Costs (€): Der Wert gibt die Kosten für Personentag (PT) an. Er wird benötigt, um die Gesamtkosten des Projekts zu ermitteln.

Eine Vereinfachung der Realität

„Alle Modelle sind falsch, aber einige von ihnen sind nützlich.“
George Box, britischer Statistiker und Autor des Buches „Empirical Model-Building and Response Surfaces“ (1987)

Natürlich ist die Realität wesentlich komplexer als das Modell. Zum Beispiel werden keine Verzögerungen durch personelle Änderungen im Team berücksichtigt. Die Vereinfachung macht es jedoch leicht nachvollziehbar, was bei Diskussionen über die Ergebnisse hilfreich sein kann.

Als Ergebnis liefert das Modell die Personalkosten für Entwickler:innen und die Dauer des Projekts in Wochen. Die Dauer ergibt sich aus den ermittelten Personentagen, geteilt durch die Anzahl der Entwickler:innen und 5 Arbeitstage.

Auswirkungen auf Anforderungen

In unserem Beispielprojekt wird der Aufwand mit 400 Story Points geschätzt. Die Entwickler:innen liefern 90 % Qualität und verwenden 15 % ihrer Arbeitszeit auf die Reduzierung technischer Schulden. Der Wert von „Dept to Halt“ wird auf 100 PT geschätzt, und ein Personentag kostet 900 €. Wir arbeiten mit einem Team von 4 Personen.

Die Abbildung zeigt, wie sich die Kosten für das Projekt abhängig von der Qualität der Anforderungen ändern.

Das Sprint-Rechner-Modell liefert bei einer Qualitätssteigerung der Anforderungen um nur 10 % von 70 % auf 80 % eine mögliche Einsparung von 72.000,00 €. Außerdem zeigt das Modell einen exponentiellen Anstieg der Kosten, wenn die Anforderungen schlechter sind.

Diese Zahlen sollten die Entscheidung für ein professionelles Anforderungsmanagement erleichtern. Wer sich trotzdem dagegen entscheidet, wettet bezüglich der Qualität von Anforderungen auf eine unbekannte Größe, die sich gravierend auf ein Projekt auswirken kann.

Fazit

Anforderungen sind der Schlüssel zum Projekterfolg. Ein einfaches Modell verdeutlicht, dass selbst eine geringfügige Verbesserung der Anforderungen bei einem Projekt der Größenordnung einer halben Million Euro eine erhebliche Einsparung im oberen fünfstelligen Bereich bedeuten kann. Die Zeit bis zur Markteinführung wird zusätzlich verkürzt, und ein profitabler Einsatz der Software beim Kunden ist früher möglich.