Wie passen Fixpreis-Projekte und agile Softwareentwicklung zusammen

Sonntag, 30. November 2014 by Rainer Stropek

Image source: https://flic.kr/p/4bjHBj, under Creative Commons License

Haben wir nicht alle in Projektmanagement-Kursen gelernt, dass Fixpreis-Projekte nicht notwendigerweise ein Vorteil für den Käufer sind? Waren nicht diese Probleme genau der Grund warum agile Projektmanagement-Prinzipien erfunden wurden? Trotzdem ist es eine Tatsache, dass viele Kunden noch immer auf Fixpreis-Projekte bestehen. In diesem Blogartikel möchte ich unseren Ansatz mit Ihnen teilen, wie fixe Preise und agile Entwicklung zusammenpassen.

Der Mythos von Risiko-Reduzierung und Fixpreis-Verträgen

Viele Software-Projekte scheitern. Zumindest werden viele von den Kunden aus einer Reihe von Gründen als Misserfolg angesehen:

Das Projektbudget wurde überschritten.
Der Zeitplan hat nicht gehalten.
Versprochene Features wurden nicht geliefert.
Der gewünschte Geschäftsnutzen wurde nicht erreicht.
Die Benutzer haben die Software nicht akzeptiert.

Was machen wir normalerweise, um Risiken zu verringern? Wir kaufen Sicherheit. Wir zahlen ein bisschen mehr, damit jemand anderer unsere Risiken übernimmt. Analog dazu bevorzugen viele Unternehmen Fixpreis-Verträge gegenüber von Verrechnung nach Aufwand. Es ist offensichtlich, dass ein Fixpreis-Vertrag eine wichtige Bedingung hat:

Es muss genau definiert sein was geliefert werden muss, bevor der Vertrag unterzeichnet wird.

Wenn das nicht gegeben ist, müssen Anbieter extrem hohe Risiko-Aufschläge kalkulieren oder mit schmutzigen Tricks arbeiten, wenn es zu kleinen Änderungen kommt ("Change Requests"). Daraus ergibt sich, dass Kunden die bei explorativen Projekten auf vorher fixierte Preise bestehen, nicht unbedingt ihr Risiko reduzieren.

Meiner Erfahrung nach haben vor allem große Organisationen mit großen Projekten noch immer den Grundsatz, vorab fixierte Preise zu verlangen. Allerdings wollen oder können sie nicht die notwendige Zeit und das notwendige Geld für eine ordentliche Startup-Phase investieren (z.B. Anforderungserhebung, Prototypen, Evaluierung von Technologien, Machbarkeitsstudien, Machbarkeitsprojekte, usw.). Solche Kunden vergessen, dass Fixpreis-Projekte auch Hand in Hand gehen mit der Fixierung des Projektumfangs.

Studien haben gezeigt, dass große Projekte öfter scheitern und dazu tendieren, weniger zu bringen [Gartner]. Die iterative und schrittweise Vorgehensweise, für die vor allem agile Projekt-Management-Ansätze plädieren, bietet eine Lösung.

Dennoch leben Kunden in der Angst, dass das Abrechnen nach Aufwand wie das Ausstellen eines Blanko-Schecks an ihre Lieferanten ist. Daher müssen Fixpreise und iterative, agile Entwicklung irgendwie zusammenkommen. Ich möchte drei wichtige Strategien beschreiben, die wir verwenden um diesen Spagat zu schaffen.

Strategie 1: Wissen, dass Ihr Umfeld fixe Preise ermöglicht

"Alles ist einfach, solange man nicht darüber nachdenkt" (Niffenegger: The Time Traveler's Wife). Dieses Zitat trifft auch auf viele Software-Projekte zu. Fixpreis-Projekte werden eher funktionieren, wenn Kunde und Anbieter profundes Wissen der Domäne und der involvierten Technologie haben. Hier sind einige Gründe dafür:

Der Kunde kann seine Bedürfnisse exakter ausdrücken.
Der Anbieter kann fehlende Teile in Spezifikationen besser feststellen und Fragen stellen wie "Sie haben nicht nach X gefragt. Unserer Erfahrung nach brauchen Kunden in Ihrer Domäne X. Sind Sie sicher, dass Sie es nicht brauchen?"
Der Anbieter kann Wissen aus ähnlichen, vergangenen Projekten heranziehen (ich habe über dieses Thema den Blogartikel Sechs Gründe für Zeiterfassung in agilen Projekten geschrieben).
Typische Probleme können vorhergesehen oder zumindest in einem frühen Stadium identifiziert werden, wenn Kunde und Anbieter Domäne und Technologie kennen.
Anbieter und Kunde haben vielleicht erfahrene Teams auf beiden Seiten, die gewohnt sind zusammen zu arbeiten.

Schätzen Sie als Kunde die Erfahrung der Domäne und der verwendeten Technologien von möglichen Anbietern, wenn Sie ein Fixpreis-Projekt anstreben. Als Anbieter, versuchen Sie zumindest Teile Ihrer Angebote zu standardisieren und verwenden Sie Economy of Scopes Effekte, um Fix-Preise in einen gewissen Umfang zu ermöglichen.

Unser Ansatz

Immer wenn wir unser Produkt time cockpit einem Kunden anbieten, versuchen wir sehr klar in der Kommunikation zu sein:

Was ist Teil des Standards bzw. wird zu einem fixen Preis angeboten.
Was ist Bestandteil unseres täglichen Geschäfts und kann im Voraus kalkuliert werden auch wenn die Anforderungen ein bisschen unklar sein können oder Artefakte existieren, die eine projektspezifische Anpassung erfordern? Hier können wir einen fixen Preis anbieten, wenn wir für den Kunden transparent eine kleine "Pufferzeit" einkalkulieren, die unvorhergesehene Probleme abdecken kann.
Was ist komplett projektspezifisch und/oder unbekannt für uns (z.B. keine oder unklare Anforderungen, unbekannte Domäne, unbekannte Technologie)? Hier sagen wir "nein" zu Fixpreis-Verträgen und schlagen vor, agile Methoden zu nutzen (in unserem Fall Kanban).

Strategie 2: Starten Sie Projekten nach Aufwand und wechseln Sie erst später zu Fixpreis-Projekten

Den Preis am Beginn eines einigermaßen großen Projekts zu fixieren ist eine gewaltige Herausforderung. Gründe dafür sind:

Die Anforderungen sind noch nicht vollständig bekannt.
Das Projekt steht unter Zeitdruck und es ist keine Zeit für eine gründliche Vorab-Planung.
Kunde und Anbieter kennen sich nicht. Daher mangelt es an einem existierenden Vertrauensverhältnis.
Das Projekt verlangt den Einsatz unbekannter Technologien.
Fixpreis-Angebote verschiedener Anbieter sind zu unterschiedlich, sodass sie nicht wirklich verglichen werden können.

Kunden sollten in Erwägung ziehen, klein zu beginnen (siehe auch Konzept Minimum Viable Product) mit einem Time & Material Vertrag. Die Erfahrung aus Projekten mit limitierten Umfängen kann ungemein behilflich bei der Planung des großen Nachfolge-Projektes und der Evaluierung eines Anbieters sein.

Es ist wichtig festzuhalten, dass dieser Ansatz nur funktioniert wenn die Teams auf beiden Seiten mehr oder weniger gleich bleiben. Wenn Personen ständig wechseln, werden der Lerneffekt und das Vertrauensverhältnis weit weniger sein oder gar eliminiert.

Unser Ansatz

Wenn wir time cockpit in größeren Organisationen anbieten, versuchen wir nicht das ganze Projekt auf einmal abzuschließen. Wir strukturieren die Produkt-Preisgestaltung (z.B. keine Mindest-Vertragsdauer, keine Minimum-Benutzeranzahl, usw.) und unsere Consulting-Angebote so, dass Kunden schrittweise Vertrauen in unsere Angebote gewinnen und wir ihre Bedürfnisse verstehen lernen. Hier sind einige Beispiele:

Starten Sie mit der Implementierung der Software in einer bestimmten Abteilung oder Zweigstelle und sehen Sie, ob die Software Nutzen bringt.
Fokussieren Sie sich zu Beginn auf die absoluten Must-Have-Anforderungen. Verschieben Sie Nice-to-have-Features auf spätere Optimierungsprojekte, die dann fixe Preise haben werden.
Bieten Sie großzügige Evaluierungsoptionen an (z.B. erweiterte kostenfreie Probezeit wenn notwendig, voller Support während der Evaluierungsphase, kleine kostenlose Anpassungen während der Evaluierungsperiode, usw.).

Strategie 3: Gedeckelte Kosten mit Anreizen anstelle von Fixpreis-Verträgen

Die Idee ist, eine Kostendeckelung zu vereinbaren, um die Risiken des Kunden zu reduzieren und ihn zum gleichen Zeitpunkt profitieren zu lassen von nicht verbrauchten Budgets. Zugegeben, als Anbieter werden Sie mit dieser Strategie auf kurze Sicht eher nicht superreich werden. Sie werden jedoch langfristig loyale Kunden bekommen.

Unserer Erfahrung nach braucht dieser Ansatz ein paar Regeln, damit er funktioniert:

Kleine Umfangsänderungen sind in Ordnung und ändern nichts an der Kostendeckelung.
Wenn sich der Umfang massiv ändert, müssen sich Kunde und Anbieter zusammensetzen und nach einer fairen Lösung für beide Seiten suchen.
Es liegt in der Verantwortung des Anbieters laut und klar zu sagen, wenn das Verhalten des Kunden den Erfolg des Projektes gefährdet (z.B. massive Umfangsänderungen, spärlich ausgearbeitete Anforderungen, fehlendes Engagement kundenseitig, usw.). Wenn der Anbieter davor nicht gewarnt hat, ist die Budget-Überschreitung sein Problem.
Der Anbieter muss Anreize bekommen (z.B. höhere Stundensätze, zusätzliche Bestellungen, usw.) wenn er es schafft effizienter zu sein als erwartet.

Beachten Sie, dass ehrliches Projekt-Reporting eine Voraussetzung dafür ist. Der effektive Aufwand muss für Käufer und Anbieter transparent sein (ich habe dazu den Blogartikel Projektreporting in agilen Projekten verfasst).

Unser Ansatz

Wann immer wir Consulting-Projekte anbieten, bieten wir beim Aufwand eine Unter- und eine Obergrenze an:

Untergrenze: Wir glauben nicht, dass wir es schneller als das schaffen.
Obergrenze: Sie müssen damit rechnen, dass das Projekt bis zu diesem Betrag kosten kann. Wir werden versuchen die Kosten niedriger zu halten, aber es könnte passieren, dass wir Ihnen so viel in Rechnung stellen.

Wir stellen unseren Kunden detaillierte Reports über unsere Aufwände zur Verfügung - auch bei Fixpreis-Projekten. Wir dokumentieren auch die Aufwände für Fehlerbehebung oder Aufwände für die der Kunde nicht zahlen muss, weil das Budget bereits überschritten ist. Unser Ziel ist immer eine offene und ehrliche Diskussion über Preise und Schätzungen.

Weitere Informationen