Was ist ein agiler Festpreis?

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

 

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.