So rechnen Unternehmen Kosten für agile Softwareprojekte ab

Im Wasserfallmodell haben sich die Finanzexperten noch sicher gefühlt. Die Abrechnung agiler Projekte stellt sie allerdings vor neue Herausforderungen. Vertrauen ist unabdingbar, wenn es zum Beispiel darum geht, die Risiken gerecht zu verteilen.

Keine fixen Projektpläne, eine unzureichende Steuerung und ein hohes Fehleraufkommen – hartnäckig hält sich das Vorurteil, dass in agilen Projekten Chaos und Laisser-faire-Haltung herrschen. Aus Controlling-Sicht führt dies häufig zu einer gefühlten Budgetunsicherheit. Um dieser bei einem Kunden oder im eigenen Unternehmen entgegenzuwirken, gilt es zunächst, den Finanzexperten die Logik des agilen Projektmanagements näherzubringen – am besten in einer Gegenüberstellung mit der ihnen vertrauten Wasserfallmethode.

Vermeintliche Sicherheit im Wasserfallprojekt

Als wesentlicher Unterschied kristallisiert sich dabei heraus, dass klassische Werkverträge darauf basieren, zu Beginn des Projektes den Liefergegenstand möglichst genau zu beschreiben. Das heißt: Der Inhalt steht fest, Zeit und Budget sind typischerweise geschätzt. Bei einem agilen Projekt hingegen sind bei den gängigen Abrechnungsformen Zeit und Budget fix, während der Inhalt oder Scope geschätzt wird. Aufgrund dieser Tatsache entsteht bei den Finanzexperten im Unternehmen ein Unsicherheitsgefühl. Beschäftigen sie sich dann aber näher mit den jeweiligen Besonderheiten der beiden Abrechnungsmethoden, relativiert sich das ungute Gefühl erfahrungsgemäß schnell.

Bei einem Vorhaben nach dem Wasserfallmodell hat der Projektleiter ein detailliertes Pflichten- und Lastenheft, das er abarbeitet. Erfahrungsgemäß gibt es dazu aber im Laufe des Projekts zahlreiche Change Requests, die am Ende oft zu höheren Kosten führen als der ursprünglich kalkulierte Preis. Oder anders formuliert: Es ist eine Illusion, dass ein komplett dokumentiertes Projekt so läuft wie im Vorhinein geplant. Oftmals sind nach einer langen Planungsphase die Pflichten- und Lastenhefte an dem Tag, an dem sie abgeliefert werden, schon veraltet. Und so bergen gerade Vertragswerke, die auf der Wasserfallmethode beruhen und vermeintliche Budgetsicherheit bieten, hohe Risiken.

Auf der anderen Seite werden agile Projekte sehr wohl gesteuert – allerdings in dem Wissen, dass es in einer schnelllebigen Wirtschaftswelt immer Unsicherheiten gibt und sich die Rahmenbedingungen und Anforderungen zum Beispiel an eine zu entwickelnde Software permanent verändern. Konkret heißt das: Im sogenannten Projekt-Backlog werden zunächst lediglich die Headlines für das gesamte Projekt aufgeschrieben. Erst wenn das Team die betreffenden Themen bearbeitet, werden sie detailliert ausgearbeitet. Für den nächsten Sprint wird jeweils das Thema ausgewählt, das die höchste Wertschöpfung für den Kunden verspricht. Auch das Backlog wird permanent angepasst. Dies führt jedoch keineswegs zu Chaos, da die genau erreicht werden soll. Um auch das „Wie“ zumindest grob zu spezifizieren, wird ein initiales Backlog erarbeitet – also eine Liste von Inhalten, die nach heutigem Kenntnis­ stand für dieses Projekt zu liefern sind.

Für dieses Backlog wird der Aufwand geschätzt. Das fällt leicht, wenn Referenzarbeiten heran­ gezogen werden können, für die eine bestimm­te Anzahl von Leuten und Tagen oder eine bestimmte Anzahl von Story Points benötigt wurden. Auf diese Weise lässt sich anhand diverser Vergleichsobjekte der Aufwand des aktuellen Vorhabens schätzen.

„Die Erfahrung zeigt, dass in agilen Projekten aufgrund der intensiveren Kommunikation zwischen Auftraggeber und Auftragnehmer und der tieferen Einbindung der Stakeholder am Ende die Zufriedenheit größer ist.“

Warum agile Methoden effizienter sind

In der Logik der agilen Formate weitergedacht, gibt das Backlog nun den Rahmen vor. Von vornherein ist aber klar, dass es zu Änderungen kommen wird. Erfahrungsgemäß werden im Laufe der Zeit sogar ganze Themenkomplexe ausgetauscht, was für beide Vertragspartner in Ordnung ist, solange sich dadurch der Aufwand nicht gravierend ändert.

Für den Fall, dass dies aber doch geschieht, gilt es, sich auch in Bezug auf den ermittelten Festpreis Gedanken zu Risikoverteilung und möglichen Exit­Optionen zu machen. Möglich ist zum Beispiel: Nach Erreichen eines verein­barten Budget­Limits werden die Kosten so weit heruntergefahren, dass der Lieferant nur noch kostendeckend arbeitet. Man teilt sich das Risiko des Überziehens des Projektrah­mens zu mehr oder weniger gleichen Teilen. Zudem sind auch bei einem agilen Festpreis Vereinbarungen wie die Abrechnung nach dem Erreichen bestimmter Meilensteine reali­sierbar.

Möglich im Sinne einer höheren Budget­-Sicher­heit ist jedoch gerade auch bei agilen Projek­ten die Abrechnung beziehungsweise Vertrags­gestaltung nach dem Prinzip „Design to Cost“. Dabei gibt das Unternehmen für ein Feature oder einen Liefergegenstand ein gewisses Bud­get vor, zum Beispiel 50.000 Euro. Dann kann man nach der Logik agiler Projekte fragen: Was können wir für 50.000 Euro liefern? Nach dem Iterationsprinzip werden zum Beispiel die wichtigsten Funktionen einer Software zuerst programmiert. Was nicht mehr in den Rahmen passt, wird gestrichen.

Grundsätzlich geht es bei der Frage nach der passenden Vertragsgestaltung und Abrech­nung bei agilen Projekten darum, dass sich beide Parteien auf die gemeinschaftliche Schaffung von Mehrwert einigen und in Abwä­gung der Bedürfnisse beider Partner das pas­sende Modell gewählt wird. Für Kunden hat dieses Vorgehen in der Regel Vorteile gegen­ über der Vertragsgestaltung bei der Wasserfall­methode. So ist beispielsweise ein Risikosplit ein Ansatz, der im Wasserfallmodell selten gewählt wird. Dasselbe gilt für den Design­ to ­Cost­ Ansatz, der jedoch dem Bedürfnis vieler Unternehmen nach Budget­Sicherheit entspricht.

Gemeinschaftliche Schaffung eines Mehrwerts

Die Erfahrung zeigt, dass in agilen Projekten aufgrund der intensiveren Kommunikation zwischen Auftraggeber und Auftragnehmer und der tieferen Einbindung der Stakeholder am Ende die Zufriedenheit größer ist. Durch die tägliche Kommunikation über den Projekt­ fortschritt, die durch die agilen Frameworks vorgegeben ist, entstehen keine größeren Black Boxes, bei denen der Kunde nicht weiß, was der Lieferant gerade tut.

Die hohe Transparenz in einem agilen Projekt sorgt zudem dafür, dass Probleme schneller erkannt und ausgeräumt werden können. Auch Controller, die sich mit der agilen Projektarbeit näher beschäftigen, erkennen heute in aller Regel, dass die Steuerung des zu erreichenden Mehrwerts hier deutlich besser gelingt. Sie lassen sich auch von den Vorteilen passender Abrechnungsmodelle überzeugen. Teams bewährten Frameworks wie zum Bei­spiel Scrum folgen, durch die auch der Erfolg engmaschig kontrolliert wird.

So wird in jedem Sprint überprüft, ob die In­halte wertschöpfend sind oder nicht. Hinzu kommt außerdem, dass die Steuerung der Wertschöpfung beim Product Owner liegt, der in der Regel von Kundenseite eingesetzt wird. Er entscheidet, an welchen Themen zu ar­beiten ist. Auf diese Weise ist der Projektfort­ schritt für den Kunden zu jedem Zeitpunkt transparent.

Run-Rate: Häufig angeboten, aber nicht ideal

Eine Gegenüberstellung zeigt, dass der Kunde bei gut gesteuerten agilen Projekten grund­sätzlich sogar eine höhere Transparenz und Kostenkontrolle hat als bei klassischen Was­serfallprojekten. Doch was bedeuten die Be­sonderheiten agiler Projekte nun genau für deren Abrechnung? In der Logik der agilen Vor­haben ist der Scope in der Regel ein Schätzwert, also flexibel, und der Kunde steuert die Wert­schöpfung selbst. Deshalb rechnen Beratungs­unternehmen häufig über eine sogenannte Run­Rate ab.

In diesem Fall stellt das Beratungsunterneh­men ein Team zur Verfügung, und der Kunde zahlt pro Zeiteinheit. Als Product Owner ist er selbst für den Inhalt verantwortlich. Das ist aus Auftragnehmersicht das einfachste Mo­dell, aus Sicht des Auftraggebers jedoch das riskanteste, weil er das komplette Risiko einer Fehlentwicklung trägt. Fairer ist es, das Risiko zu teilen. Das entspricht auch eher der Philoso­phie der agilen Methoden, die auf ein vertrau­ensvolles Miteinander und kontinuierliche Kommunikation und Abstimmung setzen.

Eine Möglichkeit ist es, ein niedriges Fixum für die eingesetzten Ressourcen zu vereinba­ren und eine Prämie für erreichte Ziele – zum Beispiel für sogenannte Releases oder gelie­ferte Story Points. Ebenfalls fair ist es, Exit­ Möglichkeiten für beide Seiten zu schaffen. Das Unternehmen beauftragt zum Beispiel zunächst fünf Sprints und schaut danach, wie sich die Leistung des Teams entwickelt hat. Dann kann es entscheiden, ob es in dieser Konstellation weitergehen soll.

Der Königsweg bei der Abrechnung agiler Pro­jekte ist jedoch der sogenannte agile Festpreis. Dieser bedeutet zwar mehr Aufwand bei der Vertragsgestaltung und ist deshalb bislang eher die Ausnahme. Dem Kunden bietet er aber über die aufgezeigten Steuerungs­- und Kontrollmechanismen hinaus eine höhere Planungssicherheit.

Das grundsätzliche Problem, das hier im Un­terschied zur Wasserfallmethode entsteht, ist die Beschreibung dessen, was geliefert werden soll. Es gibt zwar eine Idee und Vision vom Nutzen der zu liefernden Features, aber noch keinen konkreten Plan für deren Umsetzung. Dies ist eine Stärke der agilen Projektarbeit, weil keine Leistungen festgeschrieben werden, die zum Zeitpunkt der Umsetzung womöglich nicht mehr wertschöpfend sind. Es erschwert jedoch die Beschreibung des Vertragsgegen­stands.

Quelle: computerwoche.de (Ausgabe vom 06. September 2021)