Festpreis und agil zusammen geht nicht – das hört man immer wieder. Einen Gegenentwurf liefert das Konzept „Agiler Festpreis“ in dem iteratives und inkrementelles Vorgehen berücksichtigt wird. Ich gehe noch einen Schritt weiter und behaupte: Ein fester Preis wird überhaupt erst mit agilen Methoden möglich. Wie kann das sein? Hä?
Festpreis? Sind wir doch mal ehrlich: Klassisch organisierte (komplexe) Projekte, in denen ein großer Umfang schon zu Beginn der langen Projektphase festgelegt wird und dafür bestimmte Kosten aufgerufen werden, endet in politischen Change Management Schlachten. Als Sieger vom Platz geht derjenige, der die besseren Kämpfer (Verkäufer, Projektmanager…) hat.
Die Realität ist: Aufwände und damit Kosten sind in komplexen Projekten nicht verlässlich zu schätzen. Gute Beispiele liefern zum Beispiel der Bau des Berliner Flughafens (geplante Kosten 1,7 Milliarden Euro, wahrscheinliche Kosten über 7,3 Milliarden Euro – die aktuellen Kosten bekommt man hier angezeigt) oder der Bau der Elbphilharmonie (77 Millionen Euro veranschlagt, 117 Millionen vereinbart, endgültige Kosten knapp 800 Millionen Euro). Dabei enden solche aus dem Ruder gelaufenen Projekte in der Regel mit Kompromissen, die damit auch selten ausschließlich zu Lasten des Lieferanten gehen, der die Aufwände für den Festpreis geschätzt hat. Aber nur das würde tatsächlich aus den vielen angeblichen Festpreis-Projekten ein wirkliches Festpreis-Projekt für den Auftraggeber machen. Die Diskussionen zwischen Lieferant und Auftraggeber versuchen in der Regel rückwirkend heraus zu bekommen, wer verantwortlich für welche Mehraufwände ist. Jeder verkauft sich irgendwie. Am Ende zahlt der eine hier und der andere da mehr als geplant. Der angebotene feste Preis steigt, weil komplexe Projekte nicht verlässlich geschätzt werden können.
Angebote mit Festpreis gehen in der Regel davon aus, dass verlässliche Schätzungen möglich sind, dass die PM-Triangel „Fester Termin“, „Fester Umfang“ und „“Feste Qualität“ funktioniert. Schlaue Köpfe wissen, dass das nicht der Realität entspricht. Sie ergänzen schon Festpreis-Verträgen durch einen Change-Management-Prozess, der den Umgang und die Kosten mit geänderten Anforderungen regelt. In einem Festpreis-Vertrag steht also bereits, wie Mehraufwände geregelt und Mehrkosten abgegolten werden. Ist das ein verlässlicher Festpreis? Sind wir doch mal ehrlich!
Wenn man also ehrlich ist, dann kann ein wirklicher Festpreis verlässlich ohne Zusatzkosten für Veränderungen der Anforderungen und Rahmenbedingungen nur gewährleistet werden, wenn der Umfang für den Festpreis variabel ist. Agile Methoden bieten also ein Change Management schon während der Projektentwicklung. Sie reichern die Sicherheit eines festen Preises zusätzlich durch die Möglichkeit des Kunden an, Anforderungen innerhalb des festen Preises so zu ändern, dass nicht nur irgendein Produkt dabei heraus kommt, sondern das Bestmögliche für die klar definierten Kosten. Unter diesen Rahmenbedingungen ist auch ein fester Termin zu halten.
Der immer noch bestehende Wunsch vieler Unternehmen, eine Projektmanagement-Triangel angeboten zu bekommen, kommt mir wie ein trotziges Kind vor, das auf den Boden stampft und mit hochrotem Kopf sagt: Ich will aber!
Warum also nicht anfangen, der Realität komplexer Projekte ins Auge zu blicken und sich die Frage zu stellen: Ist es der feste Preis, der feste Termin oder der Umfang der mir wirklich wichtig ist? Bin ich bereit, für einen festen Umfang inklusive meiner Änderungswünsche mehr Geld zu bezahlen oder habe ich ein beschränktes Budget und einen festen Termin, der unbedingt gehalten werden muss? Die Erwartung an die hellseherischen Fähigkeiten des Lieferanten im Blick auf die Aufwände für komplexe Projekte ist nicht nur so absurd, wie sie klingt, es ist auch tausendfach belegt, dass ein solches Vorgehen schädlich ist.
Ein Projekt mit komplexen Anforderungen braucht zum Projekterfolg eine Kooperation zwischen Auftraggeber und Auftragnehmer und so lange ich als Auftraggeber trotz Einigung auf einen Festpreis auf einen festen Umfang beharre, wird der vermeintliche Festpreis Illusion bleiben.
Von einem anderen Vorgehen profitieren beide – Auftraggeber wie Auftragnehmer – durch verlässliche Kosten und planbare Aufwände. Was also spricht eigentlich dagegen, endlich mit Festpreisen zu arbeiten und sie durch agile Verträge und Vorgehensweise auch wirklich zu bekommen.
Ein paar Vorschläge zu Verträgen, die den Rahmenbedingungen komplexer Projekte gerecht werden, finden sich unter anderem in den Beiträgen von Peter Stevens zum Thema “Contracting for Agile Software Projects“.
5 Comments
Leave a CommentVielen Dank für die spannenden Gedankenanstöße. Bei einigen Punkten gehe ich mit, bei anderen teile deine Auffassung nicht ganz.
Unter T&M verstehe ich erst mal eine vertragliche Regelung, wie bezahlt werden soll und T&M bedeutet dabei für mich, dass jede für den Auftraggeber geleistete Zeit auch berechnet wird. Wenn der Auftragnehmer anfängt, Aufwände “schön zu rechnen” oder in eigener Entscheidung nicht alle Arbeit berechnet, die geleistet wurde, dann ist das ein anderes Problem.
Die Idee, Software nach Wert zu verkaufen, klingt spannend – hast du eine Idee, wie man das technisch/organisatorisch umsetzen könnte? Wenn wir beispielsweise einen Preis pro Story Point ausmachen würden, profitiert der Auftragnehmer von einer ständig steigenden Geschwindigkeit des Teams (mehr SP pro Iteration = mehr Geld pro Iteration). Der Auftraggeber würde auch profitieren, weil er pro Iteration mehr bekommt. Wäre das ein denkbarer Ansatz?
Software nach Wert zu verkaufen ist für Dienstleister richtig schwer. Ich habe es bisher nicht versucht. Beispiele wären n% von App Sales z.B. gehen direkt zu Dienstleister oder n% der Ersparnisse wenn es um ein Produkitivitätstool geht. Oder für eine Webseite wird ein Beitrag pro Besucher oder Conversion berechnet. Geschäftswirt ist besonders schwer im Voraus zu berechnen und das wäre meistens nötig bevor ein Dienstleister entscheidet ob er das Projekt machen soll oder nicht.
Preis pro Storypoint klingt Interessant. Aber gehört nach meiner Meinung nicht zu Wert-basiert sondern zu Kosten-basierten Preismodellen. Ich nehme an dieser Preis pro Story Point wird so berechnet nach Team Kosten pro Sprint dividiert durch die Velocity oder so was?
Es finde es hat immer noch ein paar Nachteile, ich denke Story Points sollen lieber nur für Sprint und Release Planung benutzt werden, aber es soll viel besser als T&M sein denke ich.
Hi,
richtig. Meine Meinung ist T&M ist schlimmer als Festpreis. Es hat ähnliche Nachteile wie Festpreis wie z.B. die Nachteile von Schätzung wie erwähnt, aber braucht auch noch Zeiterfassung was noch Nachteile hat. Es schadet die Kundenbeziehung wenn die Schätzung nicht mit der tatsächlichen Rechnung stimmt. Zu viel Zeit wird verschwunden um “besser” mit Schätzen zu werden. Es bringt Konflikt mit der “agilen” Schätzung für Sprint und Release Planung. Die Schätzung in Stunden mit Unterschrift hat immer Vorrang. Es behindert auch Innovation. Wenn Arbeit wurde für 5 Tagen geschätzt und die ganze Woche dafür geplant, aber jemand entdeckt dass es in einem Tag möglich ist, und nur ein Tag darf in der Rechnung erscheinen, dann es kann sein das es zu spät ist um genugend Arbeit zu finden um die Kosten der anderen 4 Tagen abzudecken. Es wird also oft finanziell unverantwortlich klug zu arbeiten. Leute die langsamer sind schauen besser aus weil sie “verdienen” mehr für die Firma als Leute die schnellerer, klügere Lösungen finden. Es behindert auch Teamarbeit. Wenn Arbeit wurde für die “Junior Entwickler” Rate angeboten, aber alle Juniors sind ausgelastet und nur die Architekt Zeit hat, darf er die Arbeit nicht übernehmen, sonst macht der Kunde Ärger wenn er sieht das die Arbeit “unnötig Teuer” ist.
Das haupt Problem ist das die Wert von Software kann nicht in Stunden gemessen werden. Nicht jede Stunde ist gleich Wert. Die meiste Arbeit passiert tatsächlich zu Hause in der Dusche oder im Zug, und im Büro wird es nur eingetippt. Wir verkaufen nur die Eintippzeit. Es ignoriert auch die wahre Kosten von Softwareentwicklung. Es konzentriert nur an die Zeit in der Entwicklung Selbst und benötigt komische Berechnungen um z.D. die Kosten der Angebotsschreiben, Anforderungssammeln und Analyse, und die Lieferung der Software. PMs werden die Schätzung (für Angebot) oder Zeiterfassungen (für die Rechnung) so manipulieren dass die originale Zahlen keine bedeutungsvolle Komponente von den tatsächlichen Betrag mehr sind. Es ignoriert auch Kosten wie Verzörgerungskosten und Kosten von Warteschlangen.
Die Software-eintippsdaur von einem Feature (oder “Größe” allgemein) ist wahrscheinlich die kleinste Komponente des gesamten Impakt auf dem System. Sogar Zufall spielt eine größere Rolle.
Ich habe diese Ideen besser in meinem Blog beschrieben:
http://kurthaeusler.wordpress.com/2013/05/20/pricing-and-a-little-bit-about-estimation/
Und auf dem ALE 2013 vorgetragen:
http://www.slideshare.net/kurthaeusler/offers-andpricing
Für mich das geht aber nicht um “Vertragsform”. Vertragsform ist für mich eine rechtliche, länderspezifische Diskussion über z.B. den Unterschied zwischen Arbeitsvertrag und Dienstvertrag usw. Für mich das ist bisher nicht so Problematisch weil ich bisher ganz gut ohne Vertrag arbeiten konnte (mit ausländischen Kunden mindestens).
Für mich die Diskussion über “Festpreis” oder “T&M” hat weniger mit Verträge zu tun, sondern um wie Preise berechnet sind.
Für mich die beste Preismodelle für Dienstleister sind wahrscheinlich Wertbasiert wenn möglich (aber es ist sehr schwer), oder auch Preis pro Feature basiert nicht auf Schätzungen sondern auf Messungen.
Es kommt aber auch darauf an wie agile der Prozess ist. Normalerweise solche Fragen oder Probleme erscheinen meistens bei Hybrid Projekten wo die Anforderungssammeln und Analyse und das Angebotsschreiben (und wahrscheinlich auch die Auslieferung der Software) passieren wasserfallartig und nur die Entwicklung selbst passiert “agil”. Wenn es möglich ist richtig agil zu arbeiten dann finde ich alles viel einfacher.
Natürlich aber, ist alles egal wenn alle Aspekten von Verträge, Angebote, Rechnungen usw vom Kunden bestimmt ist. Dann ist alles richtig einfach, wir müssen gar nicht darum kummern, sondern einfach machen was und wie der Kunde will.
Entschuldigung für mein schlechtes Deutsch, ich habe meine Grammatik usw. nur ganz schnell geprüft.
Hi Kurt. Deine Antwort finde ich spannend. Ich habe ich so verstanden, dass du T&M schlimmer findest als Festpreis. Richtig? Und wenn ja, welche Gründe siehst du? Welche alternative Vertragsform findest du gut geeignet für eine Arbeit zwischen Auftraggeber und Dienstleister?
Festpreis ist mindestens nicht so schlimm wie T&M aber wir müssen aufhören zu reden als ob es nur die zwei Alternativen existieren…..