Festpreisprojekte und Scrum

Auf der Mailingliste scrumdevelopment wurde vor einigen Tagen die spannende Frage diskutiert ob/wie Scrum zu Projekten mit Festpreis-Verträgen passt. Eine Frage, die immer wieder diskutiert wird, wie schon ein anderer Thread aus dem Jahr 2006 zeigt.

Im Rahmen der aktuellen Diskussion wurde immer wieder das Festpreis-Modell als sehr problematisch bezeichnet, allerding sind in vielen Bereichen Festpreis-Projekte Standard und dieses wird sich trotz der vielfältigen Nachteile dieser Vertragsform wohl auch in absehbarer Zeit nicht ändern.

Getier unterwegs

Da auch in meinem Umfeld Festpreis-Projekte dominieren, hier ein paar Gedanken zu dem Thema.

Festpreis-Projekte – nicht nur der Preis ist fix

In einem Festpreis-Projekt sind alle wesentlichen Parameter vorgegeben:

  • Das Angebot definiert den Preis, es gibt keine variablen Anteile
  • Die Spezifikation definiert dem Umfang, die Features – in Scrum-Speak den “Scope”
  • Die Termine sind in den meisten Fällen ebenfalls genau fixiert, Strafzahlungen bei Terminverfehlungen sollen häufig die Termintreue verbessern
  • Hinsichtlich Qualität wird meist mit Verweise auf “entspricht dem aktuellen Stand der Technik” etc. gearbeitet; Formulierungen die für Juristen Munition genug abgeben

Auf den ersten Blick vermittelt ein Festpreis-Vertrag damit den Eindruck einer sicheren Grundlage für das Projekt. Der Teufel steckt – wie immer – im Detail.

Typische Herausforderungen bei Festpreis-Projekten

Beispiele für typische Herausforderungen beim Einsatz von Festpreisprojekten sind:

  • Meist wird der Preis stark durch den Wettbewerb beeinflusst. Schätzungen der Entwicklungsabteilungen werden nach unten korrigiert, Risiken nicht ausreichend eingepreist. Der Vertrieb wird oft am Umsatz der abgeschlossenen Verträge gemessen und weniger daran, ob die versprochenen Leistungen auch geliefert werden können.
  • Anforderungen und Spezifikation sind in der Regel weder ausreichend genau noch fehlerfrei. Selbst wenn dies der Fall wäre, dann würde eine Spezifikation die noch vor der ersten echten Projektphase geschrieben wurde, nie die wirklichen Wünsche des Kunden abdecken. Zudem ändern sich diese stetig.
  • Im Allgemeinen hat man bei Ausschreibungen für Festpreis-Projekte nur beschränkt die Möglichkeit eng mit den (potentiellen) Auftraggebern zusammen zu arbeiten. Der Aufwand ist zudem eine erhebliche Investition, die sich nur auszahlt (?), wenn das Angebot attraktiv genug ist, um den Zuschlag für das Projekt zu erhalten. Attraktivität definiert sich hierbei oft über die ausgewiesenen Kosten.
  • Termine werden meist ebenfalls durch Wunschdenken herbeigeführt. Mögliche Risiken werden hierbei ebenfalls ignoriert.
  • Qualitätskriterien sind nicht vereinbart, alle beteiligten Parteien haben eine unterschiedliche Auffassung, was genau unter Qualität zu verstehen ist.

Roy Morien schreibt in seinem Beitrag einen entscheidenden Satz, der wohl irgendwann in jedem Festpreis-Projekt von Auftraggeber gesagt wird:

‘Oh, but surely you understood that {some feature or process} is part of what we asked for’.

In vielen  Fällen war hierbei wohl selbst dem Auftraggeber zum Zeitpunkt der Beauftragung nicht klar, dass die Funktion oder der Prozess zum Leistungsumfang gehört. Sonst hätte er dies nach Erhalt der Spezifikation anmerken müssen. Der Auftraggeber kann sich im Allgemeinen nicht von seinen Mitwirkungspflichten entbinden.

Vorgehensweise bei Angebotslegung und Abwicklung

Im Allgemeinen wird bei Festpreis-Projekten auf zwei Arten auf die Herausforderungen reagiert:

  • Bei kleineren Punkten wird ein im Festpreis vorgesehene “Puffer” genutzt, um unnötige Reibungsverluste durch Verhandlungen von Änderungswünschen zu vermeiden. Eine Methode die nur bedingt zu empfehlen ist, da im Allgemeinen der Puffer in anderen Positionen verstreckt wird und damit das Vertrauen beschädigt werden kann.
  • Im Allgemeinen muss bereits kurz nach Projektbeginn über Änderungswünsche diskutiert werden. Änderungswünsche haben meist Auswirkungen auf Projektbudget und Termine. Teilweise gelingt es aber auch Funktionen zu tauschen, d.h. den Scope des Projektes anzupassen.

Erfolgsfaktoren

Entscheidend bei Festpreis-Projekten sind oft Punkte wie

  • Offenheit und Vertrautheit: Kommunizieren Auftragnehmer und Auftraggeber offen miteinander und besteht grundsätzlich Vertrauen zwischen beiden Parteien?
  • Rahmenvertrag und Einkauf: Ist der Rahmenvertrag fair oder wird eine der beiden Parteien stark benachteiligt? Wann/wie muss bei Konzernen die Abteilung für Einkauf / Projektabwicklung involviert werden. Welche Vorgaben und Prozesse bestehen?
  • Nachvollziehbarkeit: Sind die Änderungswünsche für beide Parteien nachvollziehbar? Sind die Kosten nachvollziehbar?
  • Änderungswesen: Wurde über den Umgang mit Änderungswünschen schon bei den Vertragsverhandlungen gesprochen?
  • Flexibilität: Hält der Auftraggeber einen Teil des Projektbudgets zurück, um Änderungswünsche schnell finanzieren zu können? Ist er flexibel genug, um Anforderungen tauschen zu können?
  • Kapazität: Hat der Auftragnehmer die Kapazität und die Fähigkeiten, um Änderungswünsche zeitnah umsetzen zu können?

Vielfältige Meinungen aus der Agilen Community

Das Thema Festpreis-Projekte hat schon immer vielfältige Reaktionen ausgelöst. Besonders heftig wird in der Agile Community diskutiert.

Scott Ambler beispielsweise bezeichnet Festpreis-Projekte als grundsätzlich unethisch:

Fixed price work is unethical. As wannabe professionals we need to stand up to the bureaucratic treadmill.

Peter Stevens hat zum Thema Festpreis-Projekte und Scrum auf dem Italien Agile Day eine Key Note gehalten. Eine kurze Zusammenfassung über verschiedene Vertragsformen – inkl. Festpreis -  kann man hier nachlesen.

Simon Baker hat vor längerer Zeit schon über Festpreisprojekte etwas geschrieben:

To say how much something will cost, you need to know in great detail exactly what needs to be built so that your estimates for the work can be accurate. But you can’t define everything you want, in detail and up front, and get it exactly right so there will be no changes in the future. And no estimate is ever accurate (it wouldn’t be an estimate if it was). […] Don’t base the contract with your vendor on conformance to a detailed requirements specification. If you do, you’re saying all your good ideas happen at the start of a project and you’re effectively betting all your money on a hole-in-one

Woraufhin einer seiner Leser seine Erfahrungen mit einem Festpreisprojekt schildert:

[…] fixed price contract where the client and contractor fought endlessly over what was included in the price I endorse everything said above. Unless you are exceptionally lucky your fixed price contract will be toxic to the client supplier relationship.

Paul Klipp erläutert in seinem Artikel, warum Festpreis-Projekte letztendlich auch schlecht für den Kunden sind: Why Fixed Bids Are Bad for Clients (Scrum Alliance).

Einen Überblick über verschiedene Vertragsformen in agilen Organisationen gibt ein älterer Artikel hier auf Armerkater.de.

Fazit

Mein Fazit zu Festpreis-Projekte ist, das es sich um eine in der Industrie immer noch sehr beliebte Vertragsform handelt, die mit vielen Herausforderungen verbunden ist. Gründe hierfür sind die scheinbare Sicherheit für den Auftraggeber.

Auch bei Festpreis-Projekten kann man (relativ) gut und flexibel auf Änderungen reagieren – wenn Auftraggeber und Auftragnehmer dieses Thema offen angehen und an einer Win-Win-Situation interessiert sind.

Gibt es jedoch kein Grundvertrauen, so kann jedoch schnell eine Lose-Lose-Situation entstehen:

Der Auftraggeber wird im besten Fall bekommen, was er spezifiziert hat – nicht was er wirklich braucht. Ein zunächst preisgünstig erscheinender Anbieter kann sich im Rahmen von Änderungswünschen als vergleichsweise teuer herausstellen.

Für Anbieter stellen Festpreis-Projekte stets eine große Herausforderung da, vor allem wenn im Angebot keine große Marge zu erwarten ist bzw. kein großer Sicherheitspuffer eingepreist werden kann. Im Grunde müssen Festpreis-Projekte deshalb immer teurer verkauft werden, als Projekte die nach Aufwand abgerechnet werden. Hier spielen Risikorückstellungen, Verhandlungsmasse, Puffer und zusätzliche Verhandlungs- und Analysekosten eine Rolle.

Verträge für agile Softwareentwicklung

Als angestellter Projektleiter und Product Owner hatte ich es bisher in den meisten Projekten mit Festpreis-Verträgen zu tun: Fester Lieferumfang, fester Funktionsumfang und meist recht fixe Qualitätsanforderungen.

Dies hat stets verhindert, dass die agilen Methoden ihre voll Wirkung entfalten konnten. In vielen Fällen ist es im Projektverlauf zu heftigen Diskussionen über (kostenpflichtige) Änderungswünsche gekommen. Das übliche Problem bei Festpreisverträgen in Projekten mit einem gewissen Innovationsgrad.

Wenn man sich nun die “agilen Werte” bzw. die “Scrum Values” in Erinnerung ruft, so wird klar, dass Festverträge ein erhebliches Konfliktpotential zu diesen Werten aktivierten können. Vor diesem Hintergrund gehen viele Vordenker der agilen Bewegung in prinzipielle Opposition zu Festpreiskontrakten. Scott Ambler bezeichnet solche Verträge beispielsweise als unethisch.

Trotzdem sind Festpreisverträge die Norm, Verträge nach Aufwand selten und Mischformen kommen kaum vor.

Peter Stevens hat sich vor diesem Hintergrund mit der Problematik der Vertragsgestaltung näher beschäftigt:

In seinem Artikel Contracting for Agile Software Projects, Part 1 beschreibt er zunächst die Zielsetzung eines Vertrages, was ein Vertrag enthalten sollte und wie Vertragsformen verglichen werden können. In seinem lesenswerten Beitrag 10 Contracts for your next Agile Software Project vergleicht er schließlich die verschiedenen Vertragsformen und ihre “Kompatibilität” mit Scrum:

This week, let’s look at a number of possible contracts, and see how they work with agile and Scrum development projects:

  1. the “Sprint Contract”
  2. Fixed Price / Fixed Scope
  3. Time and Materials
  4. Time and Materials with Fixed Scope and a Cost Ceiling
  5. Time and Materials with Variable Scope and Cost Ceiling
  6. Phased Development
  7. Bonus / Penalty Clauses
  8. Fixed Profit
  9. “Money for Nothing, Changes for Free”
  10. Joint Ventures

Quelle

Ein wirklich wichtiger Beitrag, auch wenn man nicht jedem Argument zustimmen möchte.

UPDATE:

Der Vollständigkeit halber noch der Hinweis auf einen Artikel von Bernd Oestereich: “Der agile Festpreis und andere Preis- und Vertragsmodelle, Objekt-Spektrum, 01/2006, 4 Seiten, Seite 30“. Bernd beschreibt dort Preismodelle wie:

  • Festpreis
  • Aufwandspreis
  • Aufwand mit Obergrenze
  • Mehrstufiger Festpreis
  • Anforderungseinheitspreis
  • Agiler Festpreis

und vergleich diese unter Berücksichtgung verschiedener Aspekte (z.B. Budgetsicherheit, Kalkulationstransparenz, Verhandlungsaufwand, etc.). Obwohl der Artikel mittlerweile einige Jahre alt ist (2006) immer noch lesenswert.

SUGK: Zusammenfassung Treffen April

So, gestern war das zweite Treffen der Karlsruher Scrum User Group (Wiki-Seite). Wieder waren mehr als 20 Interessenten dabei.

Das Treffen fand diesmal im Wolfsbräu statt. Ein Gag der ein Foto verdient- Pizza Calzone mit Augen:

calzone-watching

Zurück zu den Themen und der Diskussion:

Agile Verträge

Jürgen Hoffmann hat unter der Überschrift “Agile Verträge” das Vorgehen der Firma CodeSprinters vorgestellt, deren Vortrag er auf dem Scrum Gathering in Stockholm gehört hat.

Letztendlich basiert der vorgeschlagene Ansatz auf einer Art Dienstvertrag, d.h. es wird im Sprint-Rhythmus nach Aufwand (Stunden) bzw. Entwickler abgerechnet. Um den Kunden die Entscheidung für einen solchen Vertrag zu erleichtern, gibt es ein paar Rahmenbedingungen, die eingehalten werden sollten. So sollten die eingesetzten Team-Mitglieder nur an einem Projekt arbeiten und der Kunde soll zu jedem Zeitpunkt Zugriff auf den aktuellen Arbeitsstand (SVN) inkl. aller Artefakte (z.B. auch interne Dokumentation) haben. Der Kunde sollte eng eingebunden werden, im besten Fall wie es Scrum vorsieht: Direkt als Product Owner. Die enge Zusammenarbeit mit dem Kunden führt jedoch dazu, dass elektronische Helferlein eingesetzt werden müssen: Scrum Planning Tools statt dem guten alten Task-Bord mit PostIts. Dies ist zumindest der Fall, wenn Kunde und Team nicht im gleichen Gebäude arbeiten:

  • Project repository – it’s client’s code after all.
  • Test system – they should see what changes.
  • Scrum tool – backlogs, tasks, burndowns, etc.
  • Bug tracking – they must go somewhere.
  • Project Wiki or other documentation.

Quelle: Selling agile Scrum based Services

INHO sicherlich ein guter Weg, falls der Kunde wirklich dazu gebracht werden kann einen Vertrag nach Aufwand zu unterschreiben. Leider ist oft nicht möglich, da der Kunde auf Festpreisangebote besteht und nicht Dienstleistungen erwerben möchte sondern eine “fertige Lösung”. Die Probleme von Festpreisprojekten wurden kurz andiskutiert.

Weitere interessante Informationsquellen für den Themenkomplex “agile Vertragsgestaltung” sind beispielsweise:

Leider kenne ich keinen Vertriebler, der sich ernsthaft mit diesen Themen beschäftigt. Festpreis und bei Problemen dann Bashing Richtung Projektleitung / Entwicklungsteam ist ja schließlich ein Pattern, welches schon immer funktioniert hat ;-)

Product Owner als Nebelschwade

Nach dem kurzen Vortrag gab es dann Diskussionen an jedem Tisch. Letztendlich bin ich wieder beim Thema “Product Owner” gelanden, schließlich ist dieses auch sehr ergiebig. Schönes Bild: Der Product Owner als Nebelschwade, hinter der sich die Komplexität der Organisation verbirgt.

Naja, das Thema Product Owner scheint ja langsam wichtiger zu werden.