Festpreisangebote in der Anwendung von agilem Projektmanagement

Geht das überhaupt? Ich denke nicht, dass sich Festpreis und Agilität widersprechen und ich werde hier versuchen zu argumentieren warum. Ganz im Gegenteil, ich glaube sogar, dass Festpreise nur dann zu Zufriedenheit bei Kunden und Lieferanten führen, wenn man agil zusammen arbeitet.

Die Realität in der traditionellen Projektbetrachtung

Das grundsätzliche Problem mit Festpreisprojekten ist, dass in den meisten Fällen eben nicht nur der Preis fest sein soll, sondern auch der Inhalt und der Termin. Dies wird im Projektmanagement gerne auch als “Magisches Dreieck” bezeichnet. Das Management dieser drei Zielgrößen führt in klassischen Festpreisprojekten zu Problemen, in meiner Vergangenheit schon sehr häufig selbst mit erlebt. Der Kunde erhält in diesem Falle genau das, was er im Pflichtenheft aufgeschrieben hat. Jegliche Abweichungen werden über das “Change Management” gesteuert, also entweder abgelehnt oder man lässt sich die Änderungen teuer bezahlen. Viele Kalkulationen von Festpreisen gehen schon beim Angebot davon  aus, dass das Projekt nur über die Änderungen profitabel wird. Nicht nur, dass der Kunden nicht das erhält was er möchte, es geht auch viel Zeit und Energie in Meetings verloren, in denen man diskutiert, ob etwas ein Change ist oder eben nicht (als Bestandteil des Pflichtenheftes).

Qualität und nichtfunktionale Anforderungen werden meistens nur rudimentär oder gar nicht spezifiziert. Dadurch fallen diese fast immer der Zeit und dem Budget zum Opfer. Am Ende stimmt dann die Performance nicht oder das übergebene Produkte ist nur schwer weiter zu pflegen und zu ändern.

Der Geschäftswert und die Kundenzufriedenheit spielen in klassischen Projekten kaum eine Rolle. Anforderungen werden nicht priorisiert, weil sowieso “alles” umgesetzt werden muss. ZB werden die Endanwender meistens am Tag der Einführung mit der neuen Software konfrontiert – "alles andere hätte nur den Zeitplan durcheinander gebracht und zu unnötigen Changes geführt" (Opelt, 2012).

Veränderte Sichtweise

Man kann in einem überschaubaren Aufwand keine Produkte zu 100% spezifizieren! Seit 1992 arbeite ich in Projekten und sehe immer wieder, dass dies aber auch heute noch versucht wird und der Drang nach “Sicherheit” dazu führt, dass Pflichtenhefte mit hunderten Seiten spezifiziert werden. Persönlich habe ich aber noch nie erlebt, dass diese Spezifikationen auch nur nahe an 100% umgesetzt wurden. Warum? Gesetzte und Vorschriften ändern sich, neue Technologien und Produkte werden verfügbar, Menschen haben neue Ideen und Meinungen, Dinge die auf dem Papier gut ausgesehen haben, stellen sich in der laufenden Produktentwicklung als nicht wirklich benutzerfreundlich dar oder man hat schlichtweg etwas falsch verstanden oder vergessen zu dokumentieren.

Zum Beispiel hat die Standish Group in ihrer jährlich wiederkehrenden Studie (CHAOS-Report) herausgefunden, dass 45% der Funktionen einer Software nie benutzt werden! 20% werden sehr selten und 16% manchmal benutzt. Nur 20% der Funktionen einer Software werden laut dieser Studie immer oder oft genutzt. Das ist also das Ergebnis von sogenannten Wasserfallprojekten in der Software-Entwicklung bwz. das Ergebnis von Planung und Umsetzung nach klassischer Festpreisphilosophie (Opelt, 2012).

Agile Festpreisbestimmung

Im agilen Projektmanagement erweitern wir das magische Dreieck also um zwei weitere Kerngrößen: Kundenzufriedenheit und Geschäftswert. Man kann auch sagen, dass in klassischen Ansätzen das Projekt “Plan getrieben" ist, während agile Projekte “Wert getrieben” sind und versuchen in jeder Iteration den maximalen Wert für den Kunden zu erzielen (mittels ständiger Priorisierung).

Es gibt sicherlich viele Ansätze und Varianten einen agilen Festpreis zu vereinbaren. Ich persönlich setze auf einen Ansatz, den ich hier kurz beschreiben werde:

1. Ich empfehle, gemeinsam mit dem Kunden ein Backlog zu erstellen oder nutze ein vorhandenes Backlogs des Kunden (das kann auch ein klassisches Pflichentheft sein, das bereits erstellt wurde).
2. Dann schätzt man die relative Größe der Funktionen auf Basis von Story Points, so dass am Ende eine Anzahl für die Storypoints des gesamten Projekts (initialer Backlog) vorhanden ist. Das Schätzen erfolgt am Besten mit den Schätzmethoden Estimation Game oder Magic Estimation Method weil es am schnellsten und effektivsten ist – ggf. kann aber auch Planning Poker verwendet werden. Das Einbinden des Kunden bei dieser initialen Schätzung hat sich bewährt, weil dies auf beiden Seiten für ein besseres Verständnis der Funktionen sorgt und viele Missverständnisse schon früh ausgeräumt werden können.
3. Dann stimmt man mit dem Kunden eine "Definition of Done" (DoD) ab, die insbesondere auch Qualitätskriterien definiert und festlegt, ob die Anwendung beispielsweise von uns, oder auch mittels automatisierter Fachtests gesichert werden soll.
4. Dann werden unterschiedliche Stories exemplarisch in einzelne Tasks "zerlegt" und es werden Design Ideen für die Umsetzung entwickelt. Auf Basis der DoD wird eine Expertenschätzung für diese exemplarischen Tasks erstellt. Man erhält so einen Aufwand für diese Stories in Personentagen. Wir mitteln dann den Aufwand auf Basis der Schätzungen für unterschiedlichen Stories und erhalten so einen Umrechnungsfaktor von Story Points auf Personentage. Am Besten validiert man diesen Wert noch einmal, in dem man ein anderes Team noch einmal diesen Umrechnungsfaktor bestimmen lässt – ggf. auch mit anderen Stories.
5. Auf Basis der initialen Schätzung des Backlogs in Storypoints und des Umrechnungsfaktors wird der Aufwand für das initiale Backlog ermittelt.
6. Der Aufwand multipliziert mit dem durchschnittlichen Tagessatz des Umsetzungsteams ergibt den Festpreis.
7. Dieser Festpreis gilt jetzt aber nicht für den Umfang des initialen Backlogs, sondern nur für die Anzahl der initial berechneten Story Points. D.h. der Kunden kann den initialen Backlog damit umsetzen, muss es aber nicht. Er kann auch jederzeit Stories austauschen, neue hinzufügen und andere streichen – solange er den Gesamtumfang der Storypoints nicht überschreitet.

Varianten von agilen Festpreisangeboten

Es gibt natürlich noch Varianten zu diesem Vorgehen. Beispielsweise kann man den Aufwand für Storypoints auch durch ein paar wenige Sprints auf Basis von Zeit und Material ermitteln. So kann man den Umrechnungsfaktor sehr präzise empirisch bestimmen und hat auf beiden Seiten höhere Planungssicherheit. I.d.R. arbeiten Dienstleister ohne diese Sicherheit mit einem “Risikoaufschlag” bei der initialen Schätzung, um das Risiko von Mehraufwänden im Festpreis zu berücksichtigen. 30% Aufschlag sind dafür ein realistischer Erfahrungswert. Eine weitere Variante ist Money for nothing – change for free, die Jeff Sutherland vorgeschlagen hat. Bei dieser Variante kann der Kunde jederzeit sagen, dass er das Projekt beendet, weil die gelieferte Funktionalität ausreichend ist. Die Differenz des Aufwandes wird geteilt, d.h. der Dienstleister erhält die Hälfte des Geldes für den nicht geleisteten Aufwand und der Kunde spart die andere Hälfte ein.

Fazit

Agilität und Festpreis müssen demnach nicht im Widerspruch stehen. Ganz im Gegenteil, führt die Aufnahme von Geschäftswert und Kundenzufriedenheit zu einer Win-Win Situation, die bei einem klassischen Verfahren zur Ermittlung  Festpreis meistens nicht erreicht wird. Das agile Verfahren zur Ermittlung eines Festpreisangebotes kann demnach als "ein reifes Verhandlungssystem für reife Geschäftspartner" bezeichnet werden.

Weiterführende Literatur

Beck, K. et al. (2001): The Agile Maifesto, http://www.agilemanifesto.org, (Abfrage: 18.03.2009).

Bockmann, S. (2008): Team Estimation Game http://agileworks.blogspot.co.at/2008/01/team-estimation-game-by-steve-bockman.html. (Abfrage 14.04.2013).

Boehm, B.W.(1981): Software Engineering Economics, Boston.

Cohn, M. (2004): User Stories Applied. For Agile Software Development, Boston.

Derby, E./Larsen, D. (2006): Agile Retrospectives. Making Good Teams Great, Boston.
Grenning, J. (2002): Planning Poker. Renaissance Software Consulting. http://renaissancesoftware.net/papers/14-papers/44-planing-poker.html. (Abfrage 14.04.2013).

Gloger, B. (2008): Scrum. Produkte zuverlässig und schnell entwickeln, München.
Kaner et al. (1996): Facilitator´s Guide to participatory Decision Making. New York.

Oesterreich, B./Weiss, C. (2008): APM - Agiles Projektmanagement. Erfolgreiches Timeboxing für IT-Projekte, Heidelberg.

Opelt et al. (2012): Der agile Festpreis, München.

Pichler, R. (2008): Scrum. Agiles Projektmanagement erfolgreich einsetzen, Heidelberg.

Schwaber, K./Beedle, M. (2001): Agile Software Development with Scrum, New York.

Schwaber, K. (2004): Agile Project Management with Scrum, Redmond.

Schwaber, K. (2007): The Enterprise and Scrum, Redmond.