Agiler Ansatz im Fixpreisprojekt?!

Ist ein Fixpreisprojekt mit einem agilen Ansatz überhaupt durchführbar? Mir wurde diese Frage vor kurzem wiedereinmal gestellt und ich möchte dies als Anlass nehmen, dieses Thema auch in meinem Blog nicht unerwähnt zu lassen, vorallem, weil es einer der häufigsten Kritikpunkte agiler Methoden ist.

Beginnen wir mit der Definition eines Festpreisprojekts. Was sind die Rahmenbedingungen? Was sind die Probleme, die dabei auftreten? Welche Lösungsansätze gibt es?

Das Fixpreisprojekt

Ein typisches Fixpreisprojekt sieht folgendermaßen aus:

  • Das Angebot definiert den Preis, es gibt keine variablen Anteile.
  • Die Spezifikation definiert den Umfang und die Funktionen.
  • Die Termine sind, in den meisten Fällen, ebenfalls genau fixiert.
  • Die Qualität wird mit dem Verweis auf „entspricht dem aktuellen Stand der Technik“ abgehandelt.

Mit diesen Randbedingungen bietet das Festpreisprojekt einen sicheren Eindruck und eine scheinbar gute Grundlage für das Projekt. Sehen wir uns aber typische „Herausforderungen“ bei Festpreisprojekten an:

  • Oft wird der Preis durch den Wettbewerb stark beeinflusst. Schätzungen der Entwicklungsabteilung werden nach unten korrigiert und Risiken nicht ausreichend eingepreist. Der Vertrieb wird oft am Umsatz der abgeschlossenen Verträge gemessen und weniger daran, ob die versprochenen Leistungen auch geliefert wurden.
  • Anforderungen und Spezifkation sind in der Regel weder ausreichend genau noch fehlerfrei formuliert. Dazu kommt noch, dass sich die Anforderungen der Kunden ändern, sobald sie die ersten Testversuche mit dem neuen Produkt machen.
  • Im Allgemeinen ist die Zusammenarbeit mit dem eigentlichen Kunden, im Besonderen bei größeren Ausschreibungen oder bei Agenturaufträgen, nur sehr beschränkt möglich.
  • Termine werden meist auch nur per Daumenregel definiert und können nur, wenn wirkliche keine Probleme auftreten, eingehalten werden.

Leider musste auch ich schon bei Fixpreisprojekten diese Herausforderungen meistern. Wie kann mit solchen Herausforderungen in Festpreisprojekten umgegangen werden?

  • Bei kleinere Punkten wird der einkalkulierte Puffer für die Entwicklung nicht spezifizierter Funktionen oder Behebung von Problemen verwendet. Diese Methode ist nur bedingt zu empfehlen, da der Puffer häufig nicht nur bei der Entwicklung sondern auch an anderen Stellen versteckt ist und dies das Vertrauen des Kunden beschädigen könnte.
  • Es ist unumgänglich, dass bereits bei Vertragsabschluss die Vorgehensweise mit Änderungswünschen exakt definiert wird. Wenn dies nicht der Fall ist, wird es nie zu einer Win-Win Situation kommen.

Im folgenden Abschnitt möchte ich die agile Herangehensweise kurz vorstellen. Ich gehe davon aus, dass die Leser bereits eine Grundahnung dieser Methode haben und nicht die tausend und einste Zusammenfassung lesen möchten.

Der agile Ansatz

Agile Methoden haben sich zur Verbesserung des Projekterfolgs bewährt. Der häufige Einsatz insbesondere von Scrum und XP zeigt, dass die meisten dem Agilen Manifest zu Grunde liegenden Prinzipien sowohl von den Kunden, als auch von den Entwicklern geschätzt werden. Diese Prinzipien sind nachfolgend angeführt:

  • Individualität und Dialog versus Prozesse und Tools
  • Funktionierende Software versus umfassende Dokumentation
  • Anwender-Kollaboration versus Vertragsverhandlungen
  • Offenheit für Änderungen versus Planerfüllung

Die Begriffe auf der rechten Seite haben aber trotzdem ihre Wichtigkeit, auch in agilen Projekten, aber unter agilen Aspekten sind die Begriffe auf der linken Seite wesentlicher.

Grundsätzlich kann man bei einem agilen Ansatz immer an einer der drei Dimensionen:

  • Zeit
  • Kosten
  • Umfang

Änderungen vornehmen und das System wird flexibel darauf reagieren.

Wie die agilen Grundsätze mit einem Fixpreisprojekt zusammenspielen wird im nächsten Abschnitt behandelt.

Agilität im Fixpreisprojekt ?!

Beim agilen Entwicklungsmodell ist es schwiereig bis unmöglich einen Festpreis für das gesamte Projekt von Beginn an zu definieren.

Klar ist, dass das Wasserfallmodell zu Projektbeginn „kundenfreundlicher“ ist, da die Kosten für den Projektabschluss dem Kunde bekannt sind. Allerdings kann dieses Modell für das Entwicklerteam zum Nachteil werden, wenn Anforderungen des Kunden nicht exakt definiert werden und Features auf Grund von Mißverständnissen in der Planung ausgelassen oder auf Kosten der Entwickler zusätzlich ergänzt werden müssen.

Natürlich gibt es Teams, die jetzt aufschreien werden und sagen „Das ist nicht ganz richtig! Wir folgen einem agilen Ansatz in Fixpreisprojekten!“ aber ich denke nicht, dass diese Teams wirklich agil Handeln und erkläre auch gleich warum. Im Grunde ist die Antwort recht simpel: Fixpreisprojekte implizieren einen fixen Funktionsumfang, einen fixen Preis und eine fixe Projektdauer. Das gesamte Projekt basiert auf Vorhersehbarkeit. Ein agiler Ansatz hingegen basiert auf einem variablen Funktionsumfang, das Management dieses Umfangs und die Möglichkeit der Funktionsänderungen. Fixpreisprojekte sind also der Gegensatz von agilen Projekten.

Wenn man davon spricht dass ein Fixpreisprojekt mit agilen Methoden umgesetzt wird, führt man eigentlich Annahmen ein, die nicht mit der agilen Denkweise vereinbar sind, wie zum Beispiel das Durchführen einer Schätzung der benötigten Funktionen im Voraus und das Einfrieren dieses Funktionsumfangs. Durch diese Einschränkungen beraubt man sich der Vorteile eines agilen Ansatzes.

Wie kann man nun mit einer agilen Methode ein Fixpreisprojekt durchführen?

Als erstes müssen die Rahmenbedingungen des Fixpreisprojekts als gegeben angenommen werden. Man hat seine Deadline, man hat den Fixpreis und man hat die Anforderungen. Diese drei Punkte können nicht verändert werden.

Daher bleibt nur eine Alternative, dass trotzdem eine agile Methode wie Scrum verwendet wird um schneller und effizienter ein lauffähiges Programm liefern und Feedback vom Kunden einfordern zu können. Jedesmal, wenn der Kunde nach einem neuen Feature fragt, muss daher klar definiert werden, dass dieses nicht Teil der Spezifikation ist, die Umsetzung gerne durchgeführt wird aber diese Umsetzung eine Auswirkung auf die Projektdauer bzw. auf die Projektkosten nachsich zieht.

Durch den „Lean“-Ansatz von Scrum werden bessere Ergebnisse erzielt, entweder durch Reduzierung des Verlusts bei einem Fixpreisprojekt oder durch Fertigstellung von mehr Software vor der Deadline.

Fazit

Die Verwendung eines agilen Ansatzes, wie zum Beispiel Scrum, macht aus einem Fixpreisprojekt kein agiles Projekt aber es ermöglicht dem Auftragnehmer schneller Ergebnisse zu liefern und produktiver zu agieren.

Für mich ist klar, dass auch der Vertrieb und das Management erkennen muss, dass agile Methoden auch ihre Tätigkeit, im Speziellen die Gestaltung von Verträgen, beeinflusst und nicht nur etwas für die Entwicklung ist. Erst dann werden die Agilen Methoden die ganze Stärke entfalten können, die hinter der Idee steckt.

Zum Abschluss möchte ich noch ein Zitat von Simon Baker anführen:

„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.“