Keine fixen Projektpläne, unzureichende Steuerung und 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 Budget-Unsicherheit. Um dieser bei einem Kunden oder im eigenen Unternehmen entgegenzuwirken, gilt es zunächst, den Finanzexperten die Logik der neuen Form des agilen Projektmanagements nahezubringen - am besten in einer Gegenüberstellung mit der ihnen vertrauten Wasserfallmethode.

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äftigten sie sich jedoch näher mit den jeweiligen Besonderheiten der beiden Abrechnungsmethoden, relativiert sich dieses erfahrungsgemäß deutlich.

Vermeintliche Budget-Sicherheit in Wasserfallprojekten

So hat bei einem klassischen Wasserfallprojekt 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 in Summe häufig sogar teurer kommen 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, bereits veraltet. Und so bergen gerade Vertragswerke, die auf der Wasserfallmethode beruhen und vermeintlich Budget-Sicherheit 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 Teams bewährten Frameworks wie zum Beispiel Scrum folgen, durch die auch der Erfolg engmaschig kontrolliert wird. So wird in jedem Sprint überprüft, ob die Inhalte 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 gearbeitet wird. Auf diese Weise ist der Projektfortschritt für den Kunden zu jedem Zeitpunkt transparent.

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

Diese Gegenüberstellung zeigt, dass der Kunde bei gut gesteuerten agilen Projekten grundsätzlich sogar eine höhere Transparenz und Kostenkontrolle hat als bei klassischen Wasserfallprojekten. Doch was bedeuten die Besonderheiten agiler Projekte nun genau für deren Abrechnung? Aufbauend auf der Logik der agilen Projekte - der Scope ist geschätzt beziehungsweise flexibel und der Kunde steuert die Wertschöpfung selbst - rechnen Beratungsunternehmen häufig über eine sogenannte Run-Rate ab.

Das bedeutet: Das Beratungsunternehmen stellt ein Team zur Verfügung und der Kunde zahlt pro Zeit. Als Product Owner ist der Kunde selbst für den Inhalt verantwortlich. Das ist aus Auftragnehmersicht das einfachste Modell, aus Sicht des Auftraggebers jedoch das riskanteste, weil er das komplette Risiko einer Fehlentwicklung trägt. Fairer ist es daher, gerade auch nach der Philosophie der agilen Methoden, die auf ein vertrauensvolles Miteinander und kontinuierliche Kommunikation und Abstimmung setzen, das Risiko zu teilen.

Eine Möglichkeit ist, ein niedrigeres Fixum für die eingesetzten Ressourcen zu vereinbaren und eine Prämie für erreichte Ziele - zum Beispiel für so genannte Releases oder gelieferte 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.

Königsweg: Agiler Festpreis plus Risikoteilung

Der Königsweg bei der Abrechnung agiler Projekte ist jedoch der sogenannte agile Festpreis. Dieser bedeutet zwar mehr Aufwand bei der Vertragsausgestaltung und ist deshalb oft noch 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 Unterschied zur Wasserfallmethode entsteht, ist die Beschreibung dessen, was geliefert werden soll. Denn 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 Vertragsgegenstands.

Um dennoch auch für agile Projekte einen Festpreis zu ermitteln, setzten sich Unternehmen und Lieferant zusammen und definieren gemeinsam die Ziele für das Projekt. Im Fokus stehen dabei der Business Value für den Kunden und die Vision davon, was mit dem Projekt genau erreicht werden soll. Um auch das "Wie" zumindest grob zu spezifizieren, wird ein initiales Backlog erarbeitet - also die Liste von Inhalten, die nach heutigem Kenntnisstand zu diesem Projekt zu liefern sind.

Für dieses Backlog wird der Aufwand geschätzt. Dazu herangezogen werden Referenzarbeiten, für die man eine bestimmte Anzahl von Leuten und Tagen oder eine bestimmte Anzahl von Story Points benötigt hat. Auf diese Weise wird anhand verschiedenster Vergleichsobjekte der Aufwand des aktuellen Projekts geschätzt.

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 dennoch geschieht, gilt es, sich auch in Bezug auf den ermittelten Festpreis Gedanken zur Risikoverteilung und möglichen Exit-Optionen zu machen.

Möglich ist zum Beispiel: Nach Erreichen eines vereinbarten Budget-Limits werden die Kosten so weit heruntergefahren, dass der Lieferant nur noch kostendeckend arbeitet. Man teilt sich das Risiko des Überziehens des Projektrahmens zu mehr oder weniger gleichen Teilen. Zudem sind auch bei einem agilen Festpreis Vereinbarungen wie die Abrechnung nach dem Erreichen bestimmter Meilensteine realisierbar.

Möglich im Sinne einer höheren Budget-Sicherheit ist jedoch gerade auch bei agilen Projekten die Abrechnung beziehungsweise Vertragsgestaltung nach dem Prinzip "Design to Cost". Bei diesem gibt das Unternehmen für ein Feature oder einen Liefergegenstand ein gewisses Budget 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 Funktionalitäten für eine Software zuerst programmiert. Was nicht mehr in den Rahmen passt, wird gestrichen.

Gemeinschaftliche Schaffung eines Mehrwerts

Grundsätzlich geht es bei der Frage nach der passsenden Vertragsgestaltung und Abrechnung 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 passende Modell gewählt wird - was für den Kunden in der Regel auch Vorteile gegenüber der üblichen Vertragsgestaltung bei der Wasserfallmethode bietet. So ist beispielsweise ein klarer Risikosplit ein Ansatz, der hier eher selten gewählt wird. Dasselbe gilt für den Design-to-Cost-Ansatz, der jedoch dem Bedürfnis vieler Unternehmen nach Budget-Sicherheit entspricht.

Insgesamt zeigt die Erfahrung, dass in agilen Projekten aufgrund der deutlich höheren Kommunikationsdichte und tieferen Einbindung der Stakeholder am Ende die Zufriedenheit größer ist. Auch durch die tagtägliche Kommunikation über den Projektfortschritt, 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 extreme Transparenz in einem agilen Projekt sorgt zudem dafür, dass Dinge, die nicht gut laufen, sehr schnell erkannt werden und im Sinne des Kunden nachgebessert werden kann. Auch die Controller, die sich mit der agilen Projektarbeit näher beschäftigen, erkennen in der Regel, dass die Steuerung des zu erreichenden Mehrwertes hier deutlich besser gelingt und lassen sich auch von den Vorteilen passender Abrechnungsmodelle überzeugen. (pg)