Agiler Festpreis, was ist das überhaupt?

Kann für eine Software, die agil entwickelt wird, im Voraus ein fester Preis vorhergesagt werden? Das klingt kontrovers, keine Frage. Während für den Kunden auf den ersten Blick Festpreis-Verträge einen Vorteil bieten, so ist aus Dienstleistersicht wiederum die Abrechnung nach Time & Material verlockend.

Aber haben Sie mit Festpreis-Verträgen in der Vergangenheit nicht auch die Erfahrung gemacht, dass das Budget am Ende doch um ein Vielfaches überschritten wurde? Wissen Sie um wieviel Prozent das Budget bei großen IT-Projekten durchschnittlich überzogen wird? Laut einer Studie von Flyvbjerg und Budzier um 400%!

Und wie oft haben Sie es schon erlebt, dass nach einem Wasserfall-Projekt mit langjähriger Umsetzungszeit bei der Abnahme das Projekt klar sein Ziel verfehlt hat? Warum passiert das so häufig? Bei dieser Art von Projekten wird der Business Value ganz am Anfang fixiert und im Verlauf des Projektes nicht wieder korrigiert. Im Gegensatz dazu stehen agile Projekte: Während beim klassischen Festpreisvertrag von Anfang an eine aufwändige und detaillierte Beschreibung des Projektumfangs Vertragsbestandteil ist, steht zu Beginn des agilen Festpreises zwar eine vollständige, aber nicht detaillierte Beschreibung der Anforderungen. Somit kann jederzeit auf Veränderungen zeitnah reagiert werden. Im Gegensatz zu Wasserfall-Projekten wird bei agilen Projekten außerdem in Iterationen gearbeitet (sogenannte Sprints), an deren Ende ein vollständig getestetes und somit abnahmefähiges Arbeitspaket steht.

Damit bei agilen Projekten die Zusammenarbeit zwischen Dienstleister und Kunde einen vertraglichen Rahmen erhält, wurde das Modell des agilen Festpreises entwickelt. Im Fokus stehen dabei Interessenausgleich zwischen Kunde und Dienstleister im Sinne von Budgetsicherheit und Kostenbeschränkung.

Am Anfang steht die Vision

Zu Beginn eines Projektes müssen Sie sich als Kunde die Frage stellen: Was will ich überhaupt? Was soll am Ende eines Projektabschnitts (Sprint) erreicht werden? Beispielsweise wollen Sie einen Online-Shop aufbauen, der über diverse Produktfilter, eine Warenkorbfunktion und verschiedene Bezahlfunktionen verfügt. Diese Vision wird in einem Workshop gemeinsam mit Kunde und Dienstleister ausgearbeitet. Alle Teammitglieder sind sich über diese Vision einig und haben das gleiche Ziel vor Augen. Der vollständige Rahmen des Projektes (Scope) ist Vertragsgegenstand und wird in sogenannten Epics festgehalten. Im Gegensatz zu einem Lastenheft beschreiben die Epics nur ganz grob Ihre Anforderungen. Das Resultat aus diesem Workshop ist der indikative Festpreisrahmen, der noch nicht bindend ist.

Checkpointphase: Zeit, sich kennenzulernen

Innerhalb eines agilen Vertragsmodells werden erst nach einer initialen Testphase (auch Checkpoint-Phase genannt) Kosten und Termine fixiert. Dabei bleibt der Scope variabel, um auf neue Gegebenheiten flexibel reagieren zu können. Die Checkpoint-Phase dauert üblicherweise zwei bis maximal fünf Sprints und ist verhandelbar. In dieser Phase können sich Kunde und Dienstleister beschnuppern und gegenseitig Vertrauen schaffen. Gerade bei neuen Geschäftsbeziehungen macht es Sinn, diese Checkpoint-Phase auszudehnen, um sich gegenseitig Zeit zu geben, die Arbeitsweise des anderen kennenzulernen. Die Checkpoint-Phase dient als Probezeit für die Zusammenarbeit, an deren Ende jedoch bereits ein auslieferbares Teilprodukt steht, das dem Kunden bereits einen Mehrwert liefert.

Am Ende der Checkpoint-Phase werden die aus der ersten Zusammenarbeit gewonnenen Erfahrungen mit den ursprünglichen Annahmen abgeglichen. Darüber hinaus wird nach der Checkpoint-Phase der indikative Festpreisrahmen in einen Maximalpreisrahmen umgewandelt. So erhält der Kunde weitere Planungssicherheit. Sind sich beide Vertragsseiten einig, müssen die Bedingungen für die weitere Zusammenarbeit vertraglich fixiert werden.

Riskshare: Wie gehen wir mit Risiken um?

Ein wichtiger Vertragsbestandteil ist das große Thema „Umgang mit Risiken“. Denn beim agilen Festpreis trägt niemand die Risiken allein. Die Risiken werden nach einem von beiden Seiten festgelegten Schlüssel auf Kunde und Dienstleister umgelegt. Entscheidend ist beim Modell des agilen Festpreises, dass der Kunde Sprints kauft, die zu einem funktionalen Teilprodukt führen, welches bereits genutzt werden kann. Im Fokus steht stets zuerst die Frage: Ist diese User Story für uns als Kunde essentiell? Liefert die User-Story wirklich einen funktionalen Mehrwert oder ist sie reiner Luxus oder gar sinnlos?

Beim agilen Festpreis gilt das Motto „Geteiltes Leid ist halbes Leid“: Riskshare ist eine Selbstversicherungsmethode für alle Parteien, die in einem Projekt involviert sind, um bei unvorhersehbaren Ereignissen die negativen Auswirkungen zu vertraglich festgelegten Anteilen auf alle Stakeholder gerecht zu verteilen. Zugleich ist Riskshare auch ein Zeichen der Verbundenheit, welches zeigt: „Ja, ich bin bereit und übernehme meinen Teil der Verantwortung und tue alles, um den Erfolg des Projektes sicherzustellen.“ Die sich daraus ergebende Verantwortung eines jeden, steigert die Verbundenheit mit dem Projekt.

Kostenneutrale Änderungen: Exchange for free

Beim agilen Festpreis sind nachträgliche Änderungen im Projektscope kostenneutral möglich. Man spricht hier von „Exchange for free“. Zu beachten ist dabei, dass der Kunde vor einem Sprint neue Anforderungen definiert und diese gegen Anforderungen gleichen Umfangs austauscht. Wird eine Anforderung zusätzlich erwünscht, handelt es sich um Mehraufwand (Change Request), der nicht im vereinbarten Maximalpreis enthalten ist. ### Offene Kommunikation, gleiche Sprache und Entscheidungsbefugnis

Um Missverständnisse zu vermeiden, müssen Kunde und Dienstleister die gleiche Sprache sprechen und das gleiche Verständnis vom agilen Festpreis und den zugrundeliegenden agilen Methoden haben. Ein Workshop vor Start des Projektes ist zwingend notwendig, um alle inhaltlichen und fachlichen Fragen zu klären und gemeinsam die Erwartungen abzustecken.

In der anschließenden Zusammenarbeitsphase muss immer wieder konkretes Feedback eingeholt werden: Ist die Story korrekt umgesetzt? Was fehlt noch? Warum waren die Erwartungen anders? Während die Entwickler lernen, dass die Storys im Kostenrahmen umgesetzt werden müssen, lernt der Kunde, dass er kontinuierlich in den Entwicklungsprozess einbezogen wird und immer wieder wichtige Entscheidungen treffen muss, damit das Projekt am Ende erfolgreich abgeschlossen werden kann. Dringend empfehlenswert ist es deshalb, vertraglich zu regeln, wer wen in welchen Zeiträumen informiert und welche Personen berechtigt sind, Entscheidungen zu treffen. Ist der Product Owner nicht befugt, Entscheidungen zu treffen, kann das weitreichende Konsequenzen haben: Im schlimmsten Fall kann es dadurch zum Sprintabbruch kommen.

Ist das was für uns?

Und für wen eignet sich nun das Modell des agilen Festpreises? So pauschal lässt sich das natürlich nicht beantworten. Klar ist, dass sich der agile Festpreis am besten für größere IT-Projekte eignet, deren Umfang sich nicht konkret eingrenzen lässt und Anforderungen teilweise noch vage in der Zukunft liegen. Für kleine Standardthemen, die nach dem gleichen Schema ablaufen, ist das Modell sicherlich überzogen. Der agile Festpreis steht und fällt allerdings vor allem durch das gemeinsame Verständnis der Vision und dem Einlassen auf den agilen Prozess. Wird die Entscheidung für den agilen Festpreis jedoch bewusst getroffen, so überzeugt er durch seine Flexibilität, stetige Transparenz und minimiertes Kostenrisiko.

Wer sich mit dem Thema „Agiler Festpreis“ näher beschäftigen will, dem empfehlen wir das Buch „Der agile Festpreis“ von Andreas Opelt, Boris Gloger, Wolfgang Pfarl und Ralf Mittermayr, welches hier auch als Quelle diente