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, Softwareanforderungen und Epics. Ebenfalls wird der rechtliche Rahmen hier verhandelt und vereinbart.
  • Anschließend wird ein für das Projekt repräsentativer 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 Product Owner und auf Lieferantenseite der Projektmanager, bzw. Scrum Master. 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 Erfolg dieses Vertragsmodells steht und fällt mit dem ersten und letzten Prozessschritt:

  • Die "Beschreibung der wesentlichen Projektziele" und
  • die "Beendigung des Projekts, wenn der Kunde den erwarteten Nutzen durch die bereits erfolgten Lieferungen als erfüllt ansieht".

Meist wird der Fehler begangen, das Projektziel nicht durch quantifizierbare Qualitätsmerkmale zu definieren (wie z. B. „Reduktion von Kosten eines bestimmten Arbeitsablaufs um einen bestimmten Wert“ wäre ein quantifizierbares Ziel). Stattdessen werden vage Definitionen für das Ziel verwendet (z. B. „ideale und umfassende Unterstützung eines Arbeitsablaufs“), die nicht objektivierbar sind. Oder die im ersten Schritt definierten Ziele wiederholen überhaupt nur den funktional angenommenen Lösungsumfang (z. B. „alle Funktionen müssen umfassend implementiert werden“). Das verursacht vor allem im letzten Prozessschritt große Probleme, wenn der "erwartete Nutzen" als Kriterium für das Projektende evaluiert werden soll. Nachdem das Ziel nicht quantifizierbar ist, können nur subjektive ad-hoc Beurteilungen stattfinden, die fast immer zu Streitigkeiten zwischen Auftraggeber und Lieferanten führen. Oft wird auch vergessen zu definieren was passiert, wenn sich das angestrebte Ziel als gar nicht erreichbar herausstellt, was bei komplexen IT-Projekten durchaus möglich ist.

Vage definierte Projektziele führen auch schon vor dem angestrebten Projektende zu Problemen: Sie verhindern die laufende Priorisierung der Funktionen nach erwarteten Nutzen, da dessen Erreichung (=das Projektziel) ja nicht quantifiziert werden kann. Ebenso erfordert die Umsetzung komplexer IT-Projekte sogenannte „safe-to-fail Experimente“ (z. B. Spikes oder Releases von Teilfunktionalitäten), für die ebenfalls quantifizierbare Ziele als Bewertungskriterium benötigt werden.

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 Storys) 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. 3. Auflage. Hanser Verlag, 2017, ISBN 978-3-446-45436-1.
  • 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 3-446-45436-5.
  • Eckhart Hanser: Agile Prozesse. Von XP über Scrum bis MAP. Springer-Verlag, 2010, ISBN 978-3-642-12313-9.
  • Tom Gilb: Competitive Engineering. 1. Auflage. 2005, ISBN 0-7506-6507-6.
  • Fritz-Ulli Pieper, Stefan Roock: Agile Verträge: Vertragsgestaltung bei agiler Entwicklung für Projektverantwortliche. dpunkt.verlag GmbH, 2017, ISBN 978-3-86490-400-4 (200 S.).

Einzelnachweise

  1. ↑ Andreas Opelt u. a.: Der agile Festpreis. Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge. Hanser Verlag, München. 43–46
  2. ↑ Mike Cohn: User Stories, Epics, and Themes. Abgerufen am 19. Juli 2013
  3. ↑ Andreas Opelt u. a.: Der agile Festpreis. Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge. Hanser Verlag, München. 63–90.
  4. ↑ Andreas Opelt u. a.: Der agile Festpreis. Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge. Hanser Verlag, München. 48–51.
  5. ↑ Andreas Opelt u. a.: Der agile Festpreis. Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge. Hanser Verlag, München. 54–55.
  6. ↑ Andreas Opelt u. a.: Der agile Festpreis. Leitfaden für wirklich erfolgreiche IT-Projekt-Verträge. Hanser Verlag, München. 57–60
  7. ↑ Eckhart Hanser: Agile Prozesse. Von XP über Scrum bis MAP. Springer-Verlag, Berlin und Heidelberg 42.
  8. ↑ Tom Gilb Competitive Engineering Butterworth-Heinemann, Oxford. 4–5
  9. ↑ Michael Overly, James R. Kalyvas: Software Agreements Line by Line. How to Understand and Change Software Licenses and Contracts to Fit Your Needs. Aspatore Books. 278–279.
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.