KI-Bild. Verschneites Gebirge im Low Poly Style
04.11.2022

Was ist ein agiler Festpreis?

Ein Lastenheft ist zu aufwendig oder nicht praktikabel, aber dennoch soll fĂŒr ein komplexes Softwareprojekt schon frĂŒhzeitig das Budget festgezurrt werden? Hier beschreiben wir mit dem Konzept des agilen Festpreises das passende Vertragsmodell.

Im ersten Moment scheint es so, als ob es sich bei der Kombination der Wörter "agil" und "Festpreis" um einen unĂŒberwindbaren Gegensatz handelt.
Jedoch hat sich das Konzept inzwischen so weit etabliert, dass es einen eigenen Wikipedia-Artikel erhalten hat.

Der Klassiker in der Software-Entwicklung: das Festpreis-Projekt

Um zu verstehen, warum ein agiler Festpreis fĂŒr ein komplexes Software-Projekt ein probates Mittel sein kann, ist es zunĂ€chst notwendig, sich den klassischen Ansatz genauer anzuschauen. Dies wĂ€re ein typisches Festpreis-Projekt, dessen Funktionsumfang exakt in einem Lastenheft dokumentiert werden muss, und bei welchem die ausfĂŒhrende Agentur wiederum ein ebenso exakt spezifiziertes Pflichtenheft erfĂŒllen muss.

Was erst einmal nach einer sicheren Sache klingt, stellt sowohl Kunde als auch Anbieter bei komplexen Software-Projekten oftmals vor Probleme.

Das Festpreismodell richtig angewandt ist aufwendig

Da ist zum einen der enorme Aufwand, der betrieben werden muss, um ein umfassendes Lastenheft zu erstellen. Jede noch so kleine Funktion muss darin exakt beschrieben sein, jeder denkbare Klickweg im System definiert, jede Schnittstelle genau spezifiziert, jede Ausnahmefallbehandlung und jeder denkbare Grenzfall mĂŒsste ebenso antizipiert und festgelegt sein. Es ist nicht unĂŒblich, dass der Dienstleister dann fĂŒr die Erstellung des Pflichtenheftes ebenso viel Aufwand ansetzen muss wie fĂŒr die gesamte technische Implementierung, da in diesem Fall die technische Konzeption Teil dieses Pflichtenheftes werden muss und wĂ€hrend der Analyse der Anforderungen zudem ein hoher und kontinuierlicher Abstimmungsbedarf mit dem Kunden notwendig ist.

In der Praxis ist es zudem in hohem Maße wahrscheinlich, dass das Lastenheft trotz grĂ¶ĂŸtmöglichem Aufwand nicht vollstĂ€ndig ist und entsprechend das Pflichtenheft LĂŒcken aufweist. Das ist der einfachen Tatsache geschuldet, dass es bei komplexen Software-Projekten, die Individual-Entwicklung beinhalten, praktisch unmöglich ist, im Vorfeld alle Details zu berĂŒcksichtigen und einzuplanen.
Da beim klassischen Festpreis das Projektrisiko beim Dienstleister liegt, wird er sich gegen diesen Umstand absichern und entsprechende Sicherheitspuffer auf seine Kalkulation aufschlagen, die es ihm erlauben, unvorhergesehene Probleme wĂ€hrend der Entwicklung abzufangen. Diese Risikopuffer werden umso grĂ¶ĂŸer ausfallen, je unschĂ€rfer die Anforderungsspezifikation zu Beginn ausfĂ€llt.
Sichert der Dienstleister sich nicht ausreichend ĂŒber Puffer ab, wird er andere Wege finden, sein Projektrisiko zu minimieren - etwa indem er an der QualitĂ€t der Umsetzung spart oder sich unweigerlich im Projektverlauf offenbarende DefinitionslĂŒcken dazu nutzt, den Kunden zur Nachbudgetierung zu zwingen. Im schlimmsten Fall droht dem Kunden sogar eine Investitions-Ruine, wenn die Risiken und UnschĂ€rfen im Projekt massiv unterschĂ€tzt worden sind, und keine Kompromissbereitschaft zwischen beiden Parteien besteht, Abstriche entweder am Umfang zu machen oder Änderungen am vereinbarten Budgetrahmen vorzunehmen.

Änderungen am Funktionsumfang? Schwierig 


Ein weiteres Problem beim klassischen Festpreis-Projekt ist seine InflexibilitĂ€t. Wenn alle Anforderungen zu Beginn exakt spezifiziert sein mĂŒssen und darauf auch die Kalkulation beruht, ist es sehr aufwendig und kostenintensiv, die Projektparameter wĂ€hrend der Umsetzung zu Ă€ndern. ErfahrungsgemĂ€ĂŸ ist es aber bei komplexen Software-Projekten mit hohem Individual-Entwicklungsanteil essenziell, dynamisch auf Vorkommnisse reagieren zu können, wie beispielsweise, dass

  • bestimmte Funktionen in der Praxis nicht so umsetzbar sind oder so funktionieren wie in der Planung angenommen
  • bestimmte Funktionen zwar anwendbar sind, aber deren Bedienkonzept von den Nutzern nicht angenommen wird
  • bestimmte Funktionen, die geplant worden sind, keinen Mehrwert bieten
  • bestimmte Funktionen, die initial nicht eingeplant waren, zusĂ€tzlich in das Projekt integriert werden sollen

Alle diese Aspekte: hohe Zusatzkosten fĂŒr die Projektspezifikation, große Sicherheitspuffer zur Risikominimierung und InflexibilitĂ€t bei der dynamischen Projektanpassung bedeuten, dass das klassische Festprojekt in vielen Bereichen der Software-Entwicklung nicht der optimale Projekt-Ansatz ist.

Was steckt nun hinter der Idee des agilen Festpreises?

Aus diesem Grund wurde das Konzept des agilen Festpreises entwickelt. Die Idee dahinter ist, dass die Höhe des Budgets fĂŒr den Kunden zunĂ€chst die wichtigste Konstante im Projekt ist. GrĂ¶ĂŸtmögliche Budget-Sicherheit und Kostenkontrolle zu haben, ist fĂŒr den Kunden im Regelfall obligatorisch, denn Projekt-Budgets mĂŒssen im Vorfeld beantragt, verargumentiert und bewilligt werden - lange bevor die Entwickler zu Werke gehen. Damit steht das Budget in einem typischen Software-Projekt relativ frĂŒh als Konstante fest.

Magisches Projektmanagement-Dreieck

Ein Projekt bewegt sich grundsÀtzlich immer innerhalb der FlÀche eines Dreiecks, dessen Eckpunkte wie folgt aussehen:

  • Budget
  • Funktionsumfang / Projektdauer
  • QualitĂ€t
Magisches Dreieck

 

Jede Änderung an einem der drei Parameter beeinflusst mindestens einen der anderen beiden. Stellt sich beispielsweise bei der Umsetzung heraus, dass der Funktionsumfang umfangreicher oder komplexer umzusetzen ist als antizipiert, ist dies nur möglich, wenn dies entweder zu Lasten der QualitĂ€t geht oder das Budget angepasst wird. Wenn jedoch beide anderen Parameter nicht verĂ€ndert werden dĂŒrfen, muss folgerichtig der Funktionsumfang reduziert werden.

Wenn nun das Ziel ist, das Budget konstant zu halten, muss das Projekt, entweder im Bereich der QualitĂ€t oder beim Funktionsumfang variabel sein können, wenn es zu Projektstart kein vollumfĂ€nglich spezifiziertes Pflichtenheft gibt. Der Parameter QualitĂ€t sollte nach dem SelbstverstĂ€ndnis von Kunde und Dienstleister ĂŒber die Umsetzung eines qualitativ hochwertigen, sicheren, skalierbaren und erweiterbaren Software-Produkts ebenfalls nicht zur Disposition stehen. Schließlich handelt es sich hierbei um eine große Investition, die im Idealfall fĂŒnf oder sogar zehn Jahre in Betrieb sein wird und dabei stĂ€ndig weiterentwickelt wird. Hier an der QualitĂ€t zu sparen verursacht auf Kurz oder Lang nur erhebliche technische Schulden, die im schlimmsten Falle dazu fĂŒhren können, dass das Projekt nur einen Bruchteil der ursprĂŒnglich angedachten Laufzeit betrieben werden kann oder ErweiterungswĂŒnsche oder sogar einfache Systemwartung entweder gar nicht oder nur unter hohen Mehrkosten durchfĂŒhrbar sind.

Budget - fix. QualitÀt - fix. Bleibt der Funktionsumfang

Somit bleibt als einzige Variable, die sich Ă€ndern kann, der Funktionsumfang - womit das Projekt ein „agiles“ Projekt wird. Ein agiles Software-Projekt zeichnet sich dadurch aus, dass die Entwurfs- bzw. Spezifikations- und Konzeptionsphase vor der Implementierung möglichst kurz gehalten und stattdessen der Fokus darauf gelegt wird, schnell ausfĂŒhrbaren Code zu erhalten - etwa durch „Rapid Prototyping“, der Umsetzung eines Proof of Concept oder der iterativen Umsetzung einer bestimmten Menge an Aufgaben im Rahmen von Software-Sprints. Das Ziel bei der agilen Software-Entwicklung ist dabei immer, so schnell wie möglich funktionierende Business-Logik zu entwickeln und entsprechend frĂŒh im Projektverlauf mögliche Probleme oder konzeptionelle Schwierigkeiten zu finden und zu adressieren.
Damit dieser Ansatz erfolgreich ist, mĂŒssen jedoch auch einige Voraussetzungen erfĂŒllt sein:

Diese Regeln muss man beherzigen

  1. Priorisierung. Sowohl zu Beginn des Projekts als auch iterativ wÀhrend der Umsetzung muss immer wieder streng darauf geachtet werden, dass die Funktionen in der Reihenfolge ihrer PrioritÀt umgesetzt werden - und auch innerhalb eines Funktionspakets liegt wiederum die erste PrioritÀt darauf, dass die Business-Logik funktioniert und das Feature somit grundsÀtzlich nutzbar ist, selbst wenn ggf. noch Details im Hinblick auf Optik und Styling fehlen sollten.
  2. Interaktion. Agile Software-Entwicklung funktioniert nur dann, wenn Kunde und Dienstleister in stĂ€ndigem Austausch miteinander stehen und regelmĂ€ĂŸige Abstimmung miteinander stattfindet. Entsprechend ist auch vonseiten des Kunden ĂŒber die gesamte Projektlaufzeit hinweg ein erheblicher und kontinuierlicher zeitlicher Investment erforderlich.
  3. FlexibilitĂ€t. Sowohl Kunde als auch Dienstleister mĂŒssen sich darauf einstellen und damit umgehen können, dass im Projektverlauf neue und ggf. auch völlig unerwartete Wege eingeschlagen werden, weil sich diese als am aussichtsreichsten fĂŒr das Projekt herausstellen. Hier mĂŒssen beide Seiten immer bereit sein, den Projektverlauf auf den PrĂŒfstand zu stellen und Teile des Projekts neu auszuhandeln
  4. VerlĂ€sslichkeit. Werden Termine oder Fristen vereinbart – etwa fĂŒr die Bereitstellung einer Funktion von Seiten des Dienstleisters oder das Test-Feedback zu einer solchen vonseiten des Kunden, so werden diese Fristen von beiden Seiten eingehalten. Sind vereinbarte Termine oder Fristen aufgrund vorab nicht absehbarer Probleme gefĂ€hrdet, kommunizieren die Vertragspartner dies unmittelbar nach Kenntniserlangung aneinander, evaluieren den Impact auf das Projekt und streben eine Minimierung des daraus ggf. entstehenden Zeitverzugs an.
  5. Vertrauen. Die wichtigste Komponente von allen. Der Dienstleister muss immer in der Lage sein, dem Kunden das GefĂŒhl zu geben, dass sein Projekt in guten HĂ€nden ist und er am Ende des Projekts - oder vielmehr „am Ende des Budgets“ - in jedem Fall ein Ergebnis erhalten wird, mit dem er seine elementaren GeschĂ€ftsprozesse wird abbilden können. Auf der anderen Seite muss der Dienstleister auch darauf vertrauen können, dass der Kunde, falls notwendig, gegenĂŒber seinen Stakeholdern durchsetzt, dass bestimmte Features nur vereinfacht realisiert werden, in einer spĂ€teren Ausbaustufe kommen oder ganz aus dem Scope fliegen, weil sie sich als zu umfangreich erweisen oder ihre relative Wichtigkeit gegenĂŒber anderen Funktionen, die zwingend umgesetzt werden mĂŒssen, nicht groß genug ist.

Fazit

Der agile Festpreis ist ein interessanter Ansatz, um auch bei komplexen Projekten, die zu Beginn nur eine ĂŒberschaubare Menge an Spezifikationen aufweisen, mit einem frĂŒh vorab festgelegten Budget gute Ergebnisse zu erzielen. Voraussetzung fĂŒr den Projekterfolg ist, dass sich sowohl Kunde als auch Dienstleister auf einen agilen Implementierungs-Ansatz fĂŒr das Projekt einlassen und sich wechselseitig an die dafĂŒr notwendigen Regeln halten.

Schlagworte

agil