Festpreis oder Time & Material? In den letzten Jahren habe ich dutzende IT-Projekte begleitet, bei denen diese Frage zum Streitpunkt wurde – oft bevor überhaupt eine Zeile Code geschrieben war. Einkaufsabteilungen bestehen auf Festpreisen, weil Budgetsicherheit nun mal nicht verhandelbar ist. Projektleiter wissen gleichzeitig, dass sich Anforderungen in komplexen Software-Projekten zwangsläufig ändern werden. Das Ergebnis: Verträge, die formal "erfolgreich" erfüllt werden, aber am tatsächlichen Bedarf vorbeigeliefert haben.
Der Agile Festpreis ist ein Vertragsmodell, das dieses Dilemma aufgreift. Die Grundidee: Ein indikativer Preisrahmen, der erst nach einer Testphase bindend wird, kombiniert mit Mechanismen für kostenneutralen Scope-Tausch und vorzeitige Beendigung. Entwickelt wurde das Konzept von Andreas Opelt, Boris Gloger, Wolfgang Pfarl und Ralf Mittermayr – dokumentiert im Standardwerk "Der agile Festpreis" (Hanser Verlag, mittlerweile in der 4. Auflage).
Ob das Modell für euer nächstes Projekt passt, hängt von Faktoren ab, die ich in diesem Artikel offen ansprechen will. Denn der Agile Festpreis ist kein Allheilmittel – aber für viele Situationen der pragmatischere Weg.
📌 Die vier Kernmechanismen
Das Herzstück des Agilen Festpreises sind vier Mechanismen, die zusammenwirken. Zwei davon – Change for Free und Money for Nothing – wurden ursprünglich von Scrum-Miterfinder Jeff Sutherland entwickelt.
🔹 Change for Free: Tauschen statt Nachverhandeln
Dein Kunde will plötzlich Feature X statt Y? Beim klassischen Festpreis beginnt jetzt die Change-Request-Schlacht. Formulare, Nachkalkulationen, zähe Verhandlungen. Am Ende zahlt einer drauf – meistens beide.
Change for Free funktioniert anders: Der Kunde darf Anforderungen an Sprint-Grenzen hinzufügen – unter einer Bedingung. Er muss gleichzeitig Anforderungen mit äquivalentem Aufwand aus dem Backlog entfernen. Will er ein Feature mit 13 Story Points hinzufügen? Dann müssen Features im Wert von mindestens 13 Story Points rausfallen. Der Gesamtscope bleibt konstant, der Inhalt kann sich anpassen.
Das verändert die Dynamik fundamental. Statt "das war so nicht vereinbart" heißt es "was ist dir wichtiger?". Statt Nachverhandlung gibt es einen klaren Prozess. In der Praxis erlebe ich, dass dieser Mechanismus Projekte rettet – nicht weil sich nichts ändert, sondern weil Änderungen kein Drama mehr sind.
Wichtig dabei: Die Äquivalenz muss messbar sein. Story Points, T-Shirt-Sizes, geschätzte Personentage – Hauptsache, beide Seiten haben dieselbe Währung.
🔹 Money for Nothing: Das Exit-Recht
Was wäre, wenn dein Kunde ein Projekt vorzeitig beenden darf – und trotzdem beide Seiten gewinnen? Das klingt paradox, ist aber die Logik hinter Money for Nothing.
Bei agiler Entwicklung werden die wertvollsten Features zuerst umgesetzt. Der Grenznutzen sinkt mit jedem Sprint. Irgendwann kostet die Entwicklung neuer Features mehr, als sie wert sind. Money for Nothing gibt dem Kunden ein Exit-Recht: Er kann nach jedem Sprint sagen "Danke, das reicht."
Das Restbudget wird geteilt – typischerweise 80/20. Der Kunde spart 80%, der Lieferant erhält 20% als Kompensation. Warum macht der Lieferant das mit? Er kann Ressourcen früher für neue Aufträge einsetzen, seine effektive Marge steigt oft deutlich, und es gibt kein frustrierendes Abarbeiten von Features, die niemand braucht.
Ein dokumentiertes Beispiel: Ein Projekt mit 10 Millionen Dollar Volumen wurde vorzeitig beendet. Der Kunde zahlte nur 3,2 Millionen, die Lieferung erfolgte 17 Monate früher als geplant. Der Lieferant erreichte statt 15% geplanter Marge tatsächlich 60% – weil früher Ressourcen für neue Aufträge frei wurden.
Ehrlich gesagt: In der Praxis wird dieser Mechanismus seltener genutzt als die Theorie vermuten lässt. Die meisten Budgetierungsprozesse sehen solche Flexibilität nicht vor. Die Finanzabteilung fragt: "Warum zahlen wir für etwas, das wir nicht bekommen?" Aber allein die Möglichkeit verändert Gespräche. Plötzlich fragt man sich: "Brauchen wir das wirklich noch?"
🔹 Risk Share: Gemeinsam haften
Wer zahlt, wenn die Schätzung daneben liegt? Diese Frage entscheidet über Zusammenarbeit oder Blame Game.
Im klassischen Festpreis trägt der Lieferant das volle Risiko. Das führt zu zwei Reaktionen: Entweder kalkuliert er massive Risikopuffer ein – dann zahlst du zu viel. Oder er kalkuliert knapp und finanziert sich später über Change Requests – dann zahlst du auch zu viel, nur später und mit mehr Ärger.
Risk Share bedeutet: Beide Parteien tragen Mehraufwand gemeinsam, typischerweise 50/50. Das klingt erstmal nach "ich zahle für Fehler des Lieferanten". Aber die Realität ist komplexer: Fehlschätzungen entstehen oft durch unklare Anforderungen – von beiden Seiten. Unvorhergesehene Komplexität ist selten die "Schuld" einer Partei. Und wer allein haftet, versteckt Probleme so lange wie möglich.
Risk Share ändert die Incentives. Wenn beide zahlen, haben beide Interesse an realistischen Schätzungen, früher Kommunikation bei Problemen und effizienter Zusammenarbeit. In der Praxis erlebe ich, dass Projekte mit Risk Share eine andere Gesprächskultur haben. Probleme werden früher angesprochen. Das Blame Game lohnt sich nicht mehr.
🔹 Checkpoint-Phase: Erst testen, dann fixieren
Einen Festpreis vereinbaren für etwas, das niemand genau kennt? Das geht – aber nicht am Tag 1.
Die Checkpoint-Phase löst dieses Dilemma. Zunächst wird ein indikativer Festpreisrahmen vereinbart, noch nicht bindend, typischerweise mit 10-25% Risikopuffer. Dann folgt eine Testphase von zwei bis fünf Sprints, in der die Umsetzung bereits beginnt. In dieser Phase wird die tatsächliche Velocity gemessen (nicht geschätzt), die Zusammenarbeit wird erprobt (nicht erhofft), und Vertrauen wird aufgebaut – oder eben nicht.
Nach der Checkpoint-Phase entscheiden beide Parteien: Wollen wir das Gesamtprojekt umsetzen? Unter welchen Bedingungen? Zu welchem – jetzt bindenden – Preis?
Das ist keine Hinhaltetaktik. Es ist eine Anerkennung der Realität: Niemand weiß zu Beginn genau, was ein komplexes IT-Projekt kostet. Die Checkpoint-Phase liefert empirische Daten statt Wunschdenken. Und ja – beide Seiten können danach auch sagen: "Das passt nicht." Besser früh als nach 18 Monaten.
📌 Besondere Herausforderungen bei ERP-Projekten
ERP-Einführungen sind für agile Festpreise besonders herausfordernd. Sie berühren alle Unternehmensbereiche, erfordern massive Datenmigration, und ändern Prozesse fundamental. Die Statistiken sind ernüchternd: 70-75% der ERP-Projekte erreichen nicht ihre ursprünglichen Ziele, etwa jedes vierte Projekt überschreitet das Budget deutlich.
SAP hat mit SAP Activate eine hybride Methodik entwickelt, die agile Elemente integriert. Der Trend geht zur "Clean Core Strategy" – Customizations werden auf die SAP Business Technology Platform ausgelagert, der Kern bleibt im Standard. Für komplexe S/4HANA-Transformationen wird das Scaled Agile Framework (SAFe) mit drei bis sechs Sprints pro Program Increment eingesetzt.
Das warnende Beispiel ist Lidl: 2011 startete der Discounter eine SAP-Einführung, investierte 500 Millionen Euro über sieben Jahre – und brach 2018 ab. Ursachen waren übermäßiges Customizing, zu schnelles Tempo und fehlende Bereitschaft zur Prozessanpassung. Auch der beste Vertrag hätte daran nichts geändert.
🛠️ Für wen funktioniert der Agile Festpreis?
Das Modell funktioniert, wenn ein Product Owner mit echtem Mandat und Zeit verfügbar ist. Wenn die Projektziele messbar sind – "30% schnellere Durchlaufzeit" statt "ideale Unterstützung". Wenn beide Seiten echte Zusammenarbeit wollen, nicht nur auf dem Papier. Und wenn die Unternehmenskultur Transparenz zulässt.
Es funktioniert nicht, wenn der Einkauf auf klassische Festpreise besteht ohne jede Ausnahme. Wenn das Management das Projekt delegieren will, ohne selbst involviert zu sein. Wenn kein Grundvertrauen zwischen den Parteien existiert. Oder wenn detaillierte Vorab-Dokumentation zwingend erforderlich ist, etwa in stark regulierten Branchen.
Red Flags während des Projekts: Wenn Velocity kontinuierlich sinkt, Sprint Goals regelmäßig verfehlt werden, Stakeholder nicht zu Reviews erscheinen oder der Product Owner nicht erreichbar ist – dann erodiert das Modell. Es fällt auf Time & Material zurück, das Blame Game beginnt. Im Extremfall werden Juristen eingeschaltet, das Gegenteil der angestrebten partnerschaftlichen Zusammenarbeit.
📌 Alternativen für echte Agilität
Der Agile Festpreis ist letztendlich ein Übergangskonstrukt. Für Organisationen, deren Einkauf Festpreise verlangt, aber deren Projekte Flexibilität brauchen. Er löst ein reales Problem – aber er ist nicht die einzige Lösung.
Für Organisationen, die echte Agilität leben, gibt es Alternativen. Festpreis pro Sprint statt pro Projekt. Nutzenorientierte Verträge mit Bezahlung nach Business Value. Managed-Investment Contracts nach SAFe mit MVP-Fokus und Optionsperioden. Praktiker von it-agile kritisieren, dass der Agile Festpreis agiles Vorgehen "immer noch relativ stark einengt" – die Budgetfixierung kann zu weniger Innovation führen, weil der Fokus auf Budgeteinhaltung liegt statt auf Wertmaximierung.
Welches Modell zu dir passt, hängt von deiner Organisation ab. Nicht vom Trend.
📌 Praxis-Checkliste vor Vertragsabschluss
Vor der Unterschrift solltet ihr diese Fragen klären:
- Sind die Projektziele quantifizierbar definiert?
- Ist eine Checkpoint-Phase (2-5 Sprints) vorgesehen?
- Ist das Risk-Share-Modell festgelegt (z.B. 50:50)?
- Ist ein Product Owner mit echtem Mandat benannt?
- Ist die Governance-Struktur dokumentiert?
- Sind "Change for Free"-Äquivalenzregeln definiert?
- Sind "Money for Nothing"-Exit-Klauseln vereinbart?
- Ist die Definition of Done gemeinsam abgestimmt?
📌 Weiterführende Ressourcen
Standardwerk im deutschsprachigen Raum: Der agile Festpreis: Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge von Opelt, Gloger, Pfarl und Mittermayr (Hanser Verlag, 4. Auflage 2023). Enthält Vertragsvorlagen und detaillierte Prozessbeschreibungen.
Grundlagen: Wikipedia: Agiler Festpreis
Agile Vertragsmodelle: it-agile: Agile Verträge
Internationale Perspektiven: UK Government Digital Service – Contracting for Agile und das Scaled Agile Framework (SAFe) für Lean-Agile Contracts.
Rechtliche Vertiefung: BITKOM-Praxishilfe "Ausgewogene Vertragskonzepte" (kostenlos verfügbar) sowie "Agile Verträge" von Pieper/Roock (dpunkt.verlag).
---
Dieser Beitrag dient der allgemeinen Orientierung und stellt keine Rechtsberatung dar. Für die konkrete Vertragsgestaltung sollten Sie einen auf IT-Recht spezialisierten Anwalt hinzuziehen.