Agiler Festpreis

Der agile Festpreis ist ein Vertragsmodell für Lieferanten und Kunden in IT-Projekten, die mit agilen Methoden durchgeführt werden. Das Vertragsmodell sieht vor, dass nach einer initialen Testphase Kosten und Termin festgesetzt werden und ein Vorgehen zur Steuerung des Umfangs („Scope“) innerhalb eines festen Rahmens vereinbart wird.

Klassische Festpreisprojekte streben schon zum Projektstart eine genaue, detaillierte Beschreibung des Vertragsgegenstandes an. Das Risiko nachträglicher Änderungen soll dadurch möglichst gering gehalten werden. Dagegen strebt der agile Festpreis zum Projektstart eine zwar vollständige, aber noch nicht detaillierte Beschreibung des Vertragsgegenstandes an.

Lieferant und Kunde treffen stattdessen gemeinsam Annahmen bezüglich Geschäftswert, Umsetzungsrisiko, Aufwand und Kosten. Auf Grundlage dieser Annahmen wird ein indikativer Festpreisrahmen vereinbart, der noch nicht bindend ist. Darauf folgt eine Testphase (Checkpoint-Phase), in der die Umsetzung bereits beginnt. Am Ende dieser Phase gleichen beide Seiten ihre gewonnenen Erfahrungen mit den initial getroffenen Annahmen ab. Sie entscheiden über die Umsetzung des Gesamtprojektes und fixieren die Bedingungen, unter denen Änderungen stattfinden dürfen. Weitere Bestandteile des agilen Festpreises sind das Teilen der Risiken, d.h. beide Parteien tragen den Mehraufwand für ungeplante Änderungen mit, und die Möglichkeit für beide Parteien, jederzeit auszusteigen (Ausstiegspunkte).

Prozessschritte beim agilen Festpreis

• Im ersten Schritt wird der Vertragsgegenstand auf einer groben Ebene beschrieben. Dazu gehören die wesentlichen Projektziele, Themen und Epics. Ebenfalls wird der rechtliche Rahmen hier verhandelt und vereinbart.
• Anschließend wird ein für das Projekt repräsentative Epic ausgewählt und bis zur Ebene von User Stories spezifiziert. Bei einem geeigneten Epic entsteht so eine ausreichende Anzahl an User Stories unterschiedlicher Art und mit unterschiedlichem Funktionsumfang, die als Referenz-User Stories gelten dürfen.
• Im Workshop bestimmen Lieferant und Kunde dann anhand der Referenz-User-Stories, der anderen Epics und mit Hilfe von Storypoints die Aufwände für das gesamte Projekt. Ebenso werden Annahmen bezüglich Implementierungsrisiko und Business-Value geschätzt. Hieraus ergibt sich ein indikativer Festpreisrahmen, der noch nicht vertraglich bindend ist und erst in einem späteren Schritt (nämlich am Ende der Checkpoint-Phase) fixiert wird.
• Im vierten Schritt wird die Checkpoint-Phase festgelegt, die als Testphase für die Zusammenarbeit gilt, da dort bereits mit der Umsetzung begonnen wird und erste empirische Erkenntnisse gewonnen werden. Empfohlen wird eine Länge zwischen zwei und fünf Sprints (bei einer Sprintlänge von zwei Wochen). Am Ende der Checkpoint-Phase überprüfen Kunde und Lieferant die anfangs gemachten Annahmen und entscheiden, ob sie das Gesamtprojekt umsetzen möchten. Ebenfalls wird dann der zunächst indikative Festpreisrahmen vertraglich bindend festgelegt. In der Checkpoint-Phase wird ebenso die Verteilung der Risiken vereinbart, die festlegt, in welchem Umfang entstandene Kosten bei Überschreitung des Maximalpreisrahmens an den Kunden verrechnet werden.
• Darüber hinaus sind die Rollen zu benennen und zu besetzen, die für die Steuerung des Projektes verantwortlich sind. Hierzu gehören auf Kundenseite der Projektmanager und auf Lieferantenseite der Product Owner. Außerdem wird empfohlen, einen unabhängigen IT-Gutachter von beiden Parteien einvernehmlich auswählen zu lassen. Aus diesen Rollen bildet sich ein Lenkungskreis (Scope-Governance) als Entscheidungsinstanz heraus, der sich regelmäßig trifft und dafür Sorge trägt, dass der kontinuierliche Spezifikationsprozess funktioniert und die jeweils am höchsten priorisierten Anforderungen als User Stories festgelegt sind.
• Anders als bei klassischen Festpreisprojekten ist beim agilen Festpreis das Projekt dann beendet, wenn der Kunde den erwarteten Nutzen durch die bereits erfolgten Lieferungen als erfüllt ansieht. Das kann durchaus eintreten, bevor alle vereinbarten Funktionalitäten geliefert wurden. Damit diese Flexibilität für Kunden und Lieferanten von Vorteil ist, sind Vereinbarungen zu treffen. Beispielsweise kann der Lieferant einen Prozentsatz vom Preis des Restumfanges erhalten oder einen neuen Auftrag im Wert des Restumfangs zugesichert bekommen.

Kritik

Der agile Festpreis eignet sich als Vertragsmodell vor allem für komplexe IT-Projekte, in denen Umfang, Verlauf und Kosten schwer vorherzusagen sind. Geht es um standardisierte Projekte, die sich in gleicher oder ähnlicher Form bereits ereignet haben, können die im agilen Festpreis übliche Testphase und die gemeinsame Überprüfung des Projektfortschritts überflüssig sein. Der Erfolg des hier vorgestellten Vertragsmodells setzt zudem voraus, dass Lieferant und Kunde zur engen Kooperation über die gesamte Projektdauer hinweg bereit sind. Ein gewisses Maß an gegenseitigem Vertrauen ist ebenfalls unerlässlich, damit Einigung zu Kosten, Aufwand und Funktionsumfang möglich ist. Ebenso ist darauf zu achten, dass die sehr groben Anforderungen (Epics), mit denen zu Beginn gearbeitet wird, möglichst bald in kleinere, überschaubare Anforderungen (User Stories) herunter gebrochen werden. Ansonsten besteht die Gefahr zu großer Ungewissheit und den damit verbundenen Risiken.

Literatur

• Andreas Opelt, Boris Gloger, Wolfgang Pfarl und Ralf Mittermayr: Der agile Festpreis. Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge. 1. Auflage. Hanser Verlag, 2012, ISBN 978-3-446-43226-0.
• Michael Overly, James R. Kalyvas: Software Agreements Line by Line. How to Understand & Change Software Licenses & Contracts to Fit Your Needs. Aspatore Books, 2004, ISBN 978-1-58762-369-1.
• Eckhart Hanser: Agile Prozesse. Von XP über Scrum bis MAP. Springer-Verlag, 2010, ISBN 978-3-642-12313-9.