Wer in einem agilen Arbeitsumfeld nach einem Festpreis gefragt wird, müsste eigentlich sofort den Kopf schütteln. Doch diese Tautologie ist dennoch häufiger Alltag in der Akquise und Abrechnung agiler Projekte. Aber wie überzeugen wir unser Gegenüber davon, dass es auch anders geht? Und welche Möglichkeiten gibt es?
Die IT hat die Dynamik und Schnelligkeit ihres Faches inzwischen größtenteils verstanden und arbeitet in vielen Firmen weitestgehend agil und adaptiv. Doch im zentralen Einkauf der gleichen (und meist großen) Unternehmen sieht das ganz anders aus. Hier zählt der Plan und ein vorab abschätzbarer Aufwand häufig noch viel mehr, als Anpassung und Lösung.
Aber Projekte verändern sich. Die Welt bleibt während eines Projektes nun einmal nicht stehen und der anfängliche Plan entspricht eher selten der Realität. Ein in zahlreichen Überstunden ausgearbeiteter Plan ist also nur bedingt sinnvoll und auch die noch so gründliche Spezifikation kann nicht immer genauestens eingehalten werden. Sie nehmen viel Zeit in Anspruch und sind doch - schon absehbar - ungültig. Und das alles kostet Geld.
Doch wie sieht eine gute agile Preisgestaltung aus? Da wir in einer komplexen Umgebung leben, ist eben auch diese nicht einfach abzuschätzen, sondern muss auf das Projekt angepasst werden. Ein Vertrag sollte also die Agilität im Projekt unterstützen und ermöglichen. Das gilt es nun genauer zu beleuchten.
Wird oft verlangt, um auf „Nummer sicher“ zu gehen. Schon vor Beginn eines Projektes werden alle Seiten des Projektmanagement-Dreiecks festgelegt: ein fester Zeitrahmen, ein fester Funktionsumfang des Produktes (Scope) und ein fester Preis. Klingt wie Musik in den Ohren der meisten Budgetverantwortlichen. Doch wie „fest“ ist dieser Festpreis wirklich?
Während des Projekts wird es immer wieder Änderungen geben - zum Beispiel aufgrund neuer technischer Möglichkeiten. Doch diese kosten zusätzliches Geld. Alle Änderungen vorherzusehen und gar vorab finanziell zu schätzen, gleicht einem Blick in die Glaskugel. Wenn zudem der Umgang mit den Änderungen nicht eindeutig definiert ist, verlagert sich das Risiko allein auf den Auftragnehmer. Dieser muss in manchen Fällen (und langen Nächten) Mehraufwände in Kauf nehmen, wenn es komplizierter wird. Jedoch ohne dafür bezahlt zu werden, da es eben ein Festpreis ist.
Auch für den Auftraggeber hat das Nachteile. Er hat kaum Einfluss auf die Leistungserbringung und kauft im Grunde eine Katze im Sack, die er vorab mit viel Aufwand so genau wie möglich spezifiziert hat und muss dann ohne Transparenz warten, wie sie aussieht.
Das Wissen um die kommende Veränderung kann ebenfalls in krimineller Natur zu einem bewusst niedrigen Angebot mit deutlichen Lücken im verlangten Pflichtenheft gipfeln. Und mit den Change Requests wird dann das eigentliche Geld gemacht.
Dann müssen während des Projektes ständig neue Angebote und Beauftragungen geschrieben werden. Das erzeugt einen enormen Administrationsaufwand, kostet wertvolle Abstimmungszeit und somit schließlich auch Geld! Und das Wort Zusatzkosten klingt dann gar nicht mehr so schön musikalisch in eben jenen Ohren des Budgetverantwortlichen.
Klingt also mehr nach Streit und selbstgemachtem Mehraufwand als agiler, wertebasierter Zusammenarbeit. Ein Festpreisvertrag ist im Grund die manifestierte Abwesenheit von Vertrauen. Wir sichern damit unsere Angst ab. Doch für das vermeintliche Sicherheitsgefühl nehmen wir eigentlich einen Angriff auf die agilen Werte in Kauf. Und fokussieren nur noch auf das Ergebnis und wie dieses aussehen soll. Doch ist das agil? Im Laufe eines Projektes sollte es möglich sein, einen Prototypen zu bauen, diesen am Markt zu testen und Änderungen vorzunehmen, um das Produkt seinem Zweck anzupassen und immer weiter zu verbessern. Änderungen sollten Teil des Projektes sein, nicht unwillkommene Störfaktoren. Denn gelingt dies nicht, ist das Produkt am Ende vielleicht nutzlos. Und ein Festpreis hat dann die Agilität und Überlebensfähigkeit eines Produktes zerstört.
Doch was, wenn wir im Projektmanagement Dreieck Termin und Kosten fixieren während der Scope variabel bleibt? Der agile Festpreis sieht vor, nach einer Testphase, in der quasi „Probe-User-Stories“ abgearbeitet werden, Auftraggeber und –nehmer gemeinsam Kosten und Termine festsetzen. Der Umfang ist dann innerhalb eines ebenfalls vereinbarten Rahmens veränderbar. Mehr dazu ist in „Der agile Festpreis“ von Andreas Opelt, Boris Gloger, Ralf Mittermayr und Wolfgang Pfarl nachzulesen (hier könnt ihr das Buch bestellen).
Viele versuchen das umzusetzen, indem sie dem Auftraggeber zusichern, jeden Sprint abzurechnen. Klingt ja auch erst einmal nicht schlecht, schließlich arbeitet das Team mit Scrum, legt vorher ja fest, was im nächsten Sprint gemacht wird und dafür gibt’s dann Geld. Ist das eine agile Abrechnung?
Dieser „Agilität in Ketten“ liegt die Annahme zu Grunde, dass mit dem Commitment des Teams im Planning der Auftraggeber eine Zusage bekommt, was er am Ende des Sprints bekommen wird und was dann abgerechnet werden kann. Doch das Commitment ist kein vertragliches Versprechen! Es ist eine Art Absichtserklärung, was im „Sprint Goal“ erreicht werden kann. Den Glauben stärken, dass man das gemeinsam auch schaffen kann. Es ist keine externe Zusicherung oder gar haftbare Aussage. Denn so bekommt der Sprint einen vertraglichen Druck. Ein Sprint wäre dann nicht mehr der durch das agile Framework geschaffene geschützte Raum, in dem das Team Dinge entscheiden kann, sondern wird zu einer Art Erfüllungspflicht. Auch das verstößt gegen agile Wertvorstellungen.
Entgegen einem Werkvertrag hat die Abrechnung nach Aufwand nicht das Ergebnis im Fokus, sondern legt zunächst die Zusammenarbeit fest. Der Auftraggeber hat also ein grobes Ziel vor Augen und kann – ganz im agilen Sinne – ja noch nicht wissen, wie lange das dauern wird oder welche Schritte dafür nötig sind. Auch das Ergebnis selbst kennt er nur vage. Er beauftragt also den Auftragnehmer, mit ihm dieses Projekt umzusetzen.
Das heißt aber nicht, dass dieser nun blind losarbeitet und für den Auftraggeber nur ein nebulöses Überraschungsei bleibt. Sondern es wird gemeinsam der agile Lifecycle durchschritten: ein Prototyp geplant und geschaffen, dieser getestet, verbessert, etc. Die Abrechnung erfolgt dann nicht nach Arbeitspaketen - denn diese stehen ja vorher nicht fest - sondern fortwährend nach Aufwand.
Oft wird die Abrechnung nach Aufwand nur für den Auftragnehmer als positiv empfunden, doch bietet sie dem Auftraggeber eine größere Möglichkeit sein Produkt mitzugestalten, transparent darüber Bescheid zu wissen, woran gerade gearbeitet und wofür das Geld benötigt wird. Er ist fortwährend eingebunden, darf mitentscheiden, wie es weitergeht. Das heißt zwar, dass natürlich mehr Kommunikation zwischen Auftraggeber und Dienstleister stattfinden muss, als vielleicht in einem laufenden Wasserfallprojekt, doch nur so handelt es sich um eine evolutionäre und auf die tatsächlichen Bedürfnisse abgestimmte Entwicklung. Keine schlechten Argumente für die nächste agile Vertragsverhandlung, oder? Die gesamte Zusammenarbeit ist durch die ihr eigene Transparenz erst wirklich agil.
Es geht darum, dass Vertrauen als Basis dienen muss (!), wenn ein Projekt agil verläuft. Und damit meinen wir nicht nur das Vertrauen im Team untereinander, sondern – und das ist oft der Denkfehler – auch das Vertrauen zwischen Auftraggeber und –nehmer.
Zusammenarbeit nach Aufwand ist eine Zusammenarbeit wie unter Kollegen. Im agilen Manifest ist genau das auf den Punkt gebracht: Die Zusammenarbeit steht über den Vertragsverhandlungen. Vertrauen und die gemeinsame Arbeit an dem Produkt ist also der Grundstein, nicht der (noch so wasserdichte) Vertrag.
Alle Karten liegen offen auf dem Tisch, die Arbeit ist transparent. Und damit ist der Auftragnehmer beim Auftraggeber eigentlich wie ein interner Mitarbeiter, nicht wie ein Dienstleister. Wenn das Verhältnis so aufgebaut ist, dann ermöglicht es erst wirkliche Agilität. Das agile Level eines Projektes beginnt also bereits mit der Budgetierung.
Legen wir mit einem Festpreisvertrag der Agilität eines Projektes Steine in den Weg, wird auch die Bearbeitung des Projektes selbst nie wirklich agil ablaufen. Verträge, welche die agilen Werte außer Acht lassen, lassen also gar kein agiles Projekt zu! Das Reagieren auf Veränderung ist mehr wert als das Befolgen eines Plans - auch bei der Budgetierung. Denn nur so kann ein wirklich erfolgreiches Produkt entstehen. Und das ist doch der eigentliche Plan, oder? Also keine Angst vor agiler Budgetierung!
Rufen Sie uns an: 030 – 555 74 70 0
