Wie kann ein Preismodell für agile Projekte im Agenturumfeld aussehen?

Zusammenfassung:

• Agenturen führen agile Projektmanagement-Methoden ein, um wettbewerbsfähig zu bleiben.
• Die Abrechnung und Vertragsgestaltung in agilen Projekten stellt sich als problematisch heraus.
• Das „adVANTAGE“-Modell bietet hierfür eine faire Lösung.
• Mit dem „adVANTAGE“-Modell ist das Risiko gleichmäßig zwischen dem Auftraggeber und dem Auftragnehmer verteilt.
• Das „adVANTAGE“-Modell hat sich bei der Firma adesso AG in der Praxis unter Beweis gestellt.

Der Ist-Zustand und ein Blick in die Zukunft

Die meisten erfolgreichen Startups und Software-Unternehmen haben schon längst den Vorteil von agilen Softwareentwicklungsmethoden erkannt. Auf der anderen Seite bleiben viele Digital- und Internet-Agenturen den klassischen Projektmanagement-Methoden, die auf umfangreichen Lasten- und Pflichtenheften basieren, treu. Das bringt viele Probleme mit sich, gerade wenn es um Web- und Software-Anwendungen geht, die technologisch komplex sind und in einem von konstanten Veränderungen geprägten Umfeld entwickelt werden. Damit die Agenturen in der Zukunft mithalten können und ein zuverlässiger Partner auch bei IT-Projekten für die Auftraggeber bleiben, sollten auch sie den Schritt in die agile Welt wagen.

Eine der größten Herausforderungen bei agilen Projektmanagement-Methoden im Agenturumfeld ist die Vertragsgestaltung.

Die agilen Methoden ermöglichen schnelle Entwicklungszyklen und helfen, durch das iterative Vorgehen, das Produkt zu entwickeln, das den eigentlichen Mehrwert schafft und gut am Markt ankommt. Nicht ohne Bedeutung ist auch das Versprechen eines funktionierenden Inkrements am Ende jedes Sprints, was den Projektabbruch oder eine Projektpause jederzeit ermöglicht, ohne dass es ein nicht funktionierendes System dem Auftraggeber übergeben wird. Nach jedem Sprint ist die Software in einer Form, dass sie in die Produktion (produktive Umgebung = verfügbar für die Endnutzer) gestellt werden kann.

In diesem Artikel wird genauer auf eine der größten Herausforderungen bei der Einführung von agilen Projektmanagement-Methoden im Agenturumfeld eingegangen – Vertragsgestaltung und Abrechnungsmodelle in agilen Projekten.

Herausforderungen bei der Vertragsgestaltung im Agenturumfeld

Wie in der Studie „adVANTAGE: A Fair Pricing Model for Agile Software Development Contracting.“ [1] beobachtet wurde, können die Auftraggeber in Software-Projekten zum Zeitpunkt des Auftrages nur sehr limitierte und grobe Anforderungen definieren. Es liegt teilweise an den fehlenden Fähigkeiten, die Software-Anforderungen in einer formalen Sprache der Anforderungsanalyse (Requirements Engineering) auszudrücken sowie insbesondere daran, dass die genauen Anforderungen im Vorfeld nicht bekannt sind und nur während der Entwicklung im engen Austausch zwischen dem Entwicklungsteam, den Stakeholdern und den Endnutzern definiert werden können.

Klassische Projektmanagement-Methoden

Wie im obigen Absatz bereits erwähnt, sind die Anforderungen am Anfang eines jeden IT-Projekts nicht genau definierbar und man kann nur die Projektrichtung bestimmen, jedoch nicht die Umsetzungsdetails definieren. Auftraggeber tendieren aber trotzdem zu einem Fixpreis-Modell und erwarten volle Vorhersagbarkeit von Auftragnehmern. Ein solcher Fixpreis kann rational nur dann bestimmt werden, wenn alle Umsetzungsdetails definiert sind, alle visuellen Entwürfe vorliegen und alle externen Abhängigkeiten, etwa zu externen Schnittstellen definiert und gelöst sind. Ein Zustand, der im realen Projektumfeld nie zustande kommt.

In der Praxis wird mit dem Problem so umgegangen, dass die Dienstleister versuchen, den Projektaufwand für das ganze Vorhaben mit allen potenziellen Risiken einzuschätzen – oder eher zu erraten, denn bei so vielen Unbekannten lässt sich der Aufwand nicht rational einschätzen. Es werden zusätzlich Puffer-Zeiten eingeplant, um potenzielle Mehraufwände abzudecken und das Projekt gewinnbringend abzuschließen. Diese Art der Projektschätzung mangelt jedoch an Transparenz, betrachtet Änderungen der Anforderungen während des Projektes sehr kritisch und führt oft zu einer Lose-Lose-Lösung, bei der weder der Dienstleister noch der Kunde mit dem Projektergebnis zufrieden sein können. Der Fixpreis stellt sich oft als zu niedrig angesetzt dar (in der initialen Pitch-Phase versucht man, die Wettbewerber mit dem besten Preis zu schlagen) und das Produkt, das anhand der initialen Spezifikation entwickelt wurde, entspricht nicht den Marktbedürfnissen.

Der beschriebene Zustand stellt somit keine Grundlage für eine erfolgreiche und langfristige Zusammenarbeit dar. Bei der Suche nach Verbesserungen in diesem Prozess wird man sich immer häufiger an den agilen Ansätzen orientieren müssen.

Agile Projektmanagement-Methoden

Die bereits erkannten Probleme mit umfangreichen Projektspezifikationen in Form von Lasten- und Pflichtenheften, die alle Aspekte des Projektes definiert haben sollen, haben zur Entstehung der agilen Entwicklungsmethoden, wie Scrum, geführt. In diesen Entwicklungsmethoden wird auf die umfassenden Spezifikationen verzichtet und stattdessen arbeitet man in kurzen intensiven Zyklen –  sog. Sprints, die eine Laufzeit von einer Woche bis sechs Wochen haben. Dadurch wird sichergestellt, dass man regelmäßig ein funktionierendes Ergebnis sieht und darauf basierend kann man nötige Optimierungen vornehmen. Auf den ersten Blick scheint diese Vorgehensweise eine perfekte Lösung zu sein, um die langen Spezifikationsphasen zu vermeiden und direkt mit der Arbeit zu beginnen. Das Potenzial dieser Vorgehensweise wurde schnell für interne Projekte von Unternehmen erkannt, da der Verzicht auf genaue Planung viel Vertrauen an das Entwicklungsteam verlangt. Bisher wurde es aber für problematisch gehalten, für Unternehmen und externe Dienstleister auf Basis von agilen Verträgen zusammenzuarbeiten.

Aus den im obigen Absatz beschriebenen Gründen lässt sich der Fixpreis für ein agiles Projekt nicht bestimmen. Die Entwicklung von Prototypen und die vorprogrammierten Änderungen der Anforderungen führen dazu, dass viel von der geleisteten Arbeit sich nicht direkt in dem Endprodukt widerspiegelt. Der eigentliche Aufwand lässt sich dabei nicht im Voraus bestimmen. Ein Fixpreis-Vertrag würde den Auftraggeber dazu bewegen, mehrere Änderungen der Anforderungen und zusätzliche Funktionalitäten ohne zusätzlichen Kosten zu fordern und den Dienstleister dadurch benachteiligen und das komplette Projektrisiko an ihn übertragen.

Auf der anderen Seite, ein reines Time-and-Material-Modell, in dem jede Projektstunde, ungeachtet des Projektergebnisses, vergütet wird, kann den Auftraggeber benachteiligen, weil er weniger Kontrolle über das Endergebnis behält und zudem könnte dieses Modell den Dienstleister zur langsamerer und weniger sorgfältiger Arbeit ermutigen, weil er von Projektverzögerungen profitiert (verbucht mehr Stunden). In dem Fall liegt das gesamte Projektrisiko bei dem Auftraggeber.

Tabelle 1 – Merkmale verschiedener Projektmanagment-Methoden

Keine von den beiden Situationen ist gleichzeitig für die beiden Parteien zufrieden stellend. Es wird daher ein Vertragsmodell angestrebt, welches das Risiko gleichmäßig verteilt sowie einen Kostenmanagementmechanismus für den Auftraggeber bereitstellt. In einer Studie wurde das Modell namens adVANTAGE vorgestellt, das genau diesen Ansprüchen entspricht und sich in der Praxis bei Firmen wie der adesso AG bewiesen hat. [1] In der Tabelle 1 wurden die wichtigsten Merkmale des Fixpreis-Modells, des Time-and-Material-Modells (T&M) sowie des adVANTAGE-Modells gegenübergestellt.

Das adVANTAGE-Vetragsmodell

Um faire Regeln sowie eine gleichmäßige Verteilung des Projektrisikos sicherzustellen, kombiniert das adVANTAGE-Modell Elemente von klassischen Fixpreis-Verträgen sowie von T&M-Verträgen. Das adVANTAGE-Modell gibt eine grobe Einschätzung der gesamten Projektkosten und des Projektumfangs, ähnlich dem Fixpreis-Vertrag, ohne den Dienstleister daran zu binden (wie beim T&M). Des Weiteren stellt dieses Modell sicher, dass der Auftraggeber nur dafür bezahlt, was tatsächlich geliefert wurde (wie beim T&M), schützt ihn jedoch davor, dass das Projekt komplett außer Kontrolle gerät, weil es auch im finanziellen Interesse des Dienstleisters ist, so effizient wie möglich zu arbeiten. Projektverzögerungen bringen ihm zumindest hypothetisch keinen Vorteil.  Die zwei Grundbestandteile dieses Modells sind also: Risikominimierung (durch gleichmäßige Verteilung) sowie Effizienzanreize für den Auftragnehmer (niedrige Leistungsfähigkeit wird bestraft).

Schritt 0:  Initiale Anforderungsaufnahme und Budgetschätzung.

Um sich ein erstes Bild vom Projekt machen zu können, werden vor der ersten Iteration die Anforderungen erfasst. Typischerweise werden sie in „pflichtig“ und „optional“ aufgeteilt. Da meistens der Auftraggeber nicht in der Lage ist, alle Anforderungen des Projektes zu nennen (und schon gar nicht in formaler Sprache auszudrücken), werden sie zuerst als „User Stories“ erfasst – d.h. individuelle, testbare Einheiten, die man auf der Business-Ebene mit einfachen Worten beschreiben kann.

Der Dienstleister schätzt den Aufwand für die Umsetzung jeder User Story ein. Aufgrund der groben Natur der User Story ist die Einschätzung durch eine gewisse Unsicherheit geprägt. Diese Unsicherheit ist aber nicht höher als bei der Einschätzung auf Basis eines Lastenheftes oder einer im voraus geschriebenen Spezifikation. Von Vorteil ist es hierbei zusätzlich, dass diese Unsicherheiten auf jede kleine Story verteilt und nicht auf das ganze Projekt bezogen werden. Im Unterschied zu dem Fixpreis-Modell stellt diese Einschätzung nicht die Grundlage für die Abrechnung dar, sondern ist es eine rein informative Kennzahl für die weiteren Phasen.

„User Stories (…) – individuelle, testbare Einheiten, die man auf der Business-Ebene mit einfachen Worten beschreiben kann.“

Schritt 1: Priorisierung der User Stories und Definieren von Sprints.

Basierend auf den Aufwandschätzungen für jede Story kann der Auftraggeber die Reihenfolge, in der sie bearbeitet werden, bestimmen (Priorisierung), weitere Stories hinzufügen oder auch einzelne streichen. Bei jeder Entscheidung soll der Auftraggeber den Wert jeder Story (geschätzte Kosten der Story) sowie sein Budget im Auge behalten. Diese Transparenz zwingt den Auftraggeber dazu, sich genau die Gedanken darüber zu machen, ob gewisse Funktionalität wirklich wichtig ist, denn er sieht direkt den Preis und Aufwand für jede Funktionalität und nicht nur einen Preis für das ganze Projekt, der sich für ihn wie eine „Black Box“ anfühlt. Diese granulare Kontrolle über das Budget und Funktionalitäten führt dazu, dass man nur die guten Stories in das Backlog aufnimmt (diejenigen, die ein gutes Kosten-Leistungs-Verhältnis haben). Ein weiterer großer Vorteil dieses Vorgehen ist es, dass diese Priorisierung nach jedem Sprint stattfindet und die Stories, die für später geplant sind, nicht zum Beginn des Projektes sehr genau spezifiziert werden müssen, im Gegensatz zu dem Fixpreis-Modell.

Nach der Priorisierung findet am Anfang jedes Sprints die Auswahl der Stories für den anstehenden Sprint statt. Es werden die Stories mit der höchsten Priorität in der Menge, die im Laufe des Sprints objektiv umsetzbar ist, ausgewählt. Die Auswahl der Stories soll es ermöglichen, am Ende des Sprints ein funktionierendes System auszuliefern. (Ggf. nicht mit allen Funktionalitäten, d.h., wenn man als Beispiel ein Kundenmanagement-System nimmt, wäre Ziel des ersten Sprints, dass der Nutzer sich auf der Plattform anmelden kann. Im zweiten Sprint könnte er sich zusätzlich registrieren. Im dritten hätte man drei Nutzer-Typen etc..)

„Es werden die Stories mit der höchsten Priorität in der Menge, die im Laufe des Sprints objektiv umsetzbar ist, ausgewählt.““

Schritt 2: Sprint Umsetzung.

Am Anfang jedes Sprints werden die User Stories um sehr detaillierte Anforderungen ergänzt. Der initiale Input kommt vom Auftraggeber und die weiteren Anforderungen werden anhand von Rückfragen seitens des Entwicklungsteams definiert. Durch diese kollaborative Vorgehensweise wird sichergestellt, dass für diese kurze Iteration alle Anforderungen gut definiert sind und das Entwicklungsteam produktiv arbeiten kann. Der Sprint kann zwischen einer und sechs Wochen dauern, je nach Umfeld, in dem man agiert. Eine konstante, nicht veränderbare Dauer des Sprints ist essenziell für den Prozess. Ein anderer wichtiger Punkt ist es, dass die Reihenfolge sowie die Menge der Stories innerhalb des Sprints nicht veränderbar ist. Es sei denn, das Team setzt vor dem Sprint-Ende alle Stories erfolgreich um. In diesem Fall werden weitere Stories vom Backlog nachgezogen. Da die Abrechnung nach dem Stories-Wert erfolgt, ist es für den Dienstleister durchaus lukrativ und erstrebenswert. Für den Auftraggeber bedeutet es mehr umgesetzte Stories in kürzerer Zeit – eine Win-Win-Situation.

Die Reihenfolge sowie die Menge der Stories innerhalb des Sprints ist nicht veränderbar.

Schritt 3: Sprint-Inspektion und Abrechnung.

Am Ende jedes Sprints wird jede User Story individuell untersucht, ob sie die funktionalen und qualitativen Anforderungen erfüllt hat. Es werden auch die tatsächlichen Aufwände (in Stunden) offengelegt und mit der Schätzung verglichen. Je nachdem, ob alle Stories erfolgreich abgeschlossen wurden, gibt es verschiedenen Szenarien für den Sprint-Abschluss.

Unterbezahlter Sprint.  Wie in der Tabelle 2 abgebildet, werden die Kosten für den Sprint als die Summe aller Sprint-Aktivitäten gesehen. Es gibt Positionen wie Scrum Master-Aufwand oder Anforderungsanalyse-Meetings, die nicht einer konkreten Story zuzuordnen sind (hier z.B. 22.000 EUR). Bei den User Stories ist der initial geschätzte Aufwand sowie der tatsächliche Aufwand zu sehen (z.B. 80 Manntage – jeweils 1.000 EUR pro Tag – s.u.). In der folgenden Tabelle ist zu sehen, dass, wenn das Team weniger Zeit gebraucht hat, als zuvor geschätzt wurde, dann wird nur der tatsächlich benötigte Aufwand in Rechnung gestellt.

Tabelle 2 – Unterbezahlter Sprint

Überbezahlter Sprint. Auf der anderen Seite, wenn der tatsächliche Aufwand höher als geschätzt war, wird der zusätzliche Aufwand auch in Rechnung gestellt, jedoch zu einem deutlich niedrigeren Preis. In der Tabelle 3 ist ein Beispiel zu sehen, in dem die Mehraufwände zu 60 % des normalen Tagessatzes gebucht werden. Auf diese Art und Weise stellt adVANTAGE eine faire Verteilung des Risikos zwischen den beiden involvierten Parteien sicher. Der Auftraggeber bezahlt nur für die fertiggestellten Funktionalitäten und der Dienstleister wird bezahlt, auch wenn seine initialen Schätzungen zu niedrig angesetzt wurden.

Tabelle 3 – Überbezahlter Sprint

Nicht fertige/nicht akzeptierte Stories. Es kann auch dazu kommen, dass manche Stories während des Sprints nicht fertig geworden sind oder vom Auftraggeber nicht abgenommen wurden. In beiden Fällen obliegt es dem Auftraggeber zu entscheiden, ob die Stories in den nächsten Sprint aufgenommen werden oder ob sie abgebrochen und vom Backlog entfernt werden (alternativ auf „on hold“ gesetzt werden).

Wie es in der Tabelle 4 zu sehen ist, wird der geschätzte und tatsächliche Aufwand, sowie die Kosten der Story in den nächsten Sprint übertragen und taucht somit auf der Rechnung des aktuellen Sprints nicht auf. Die Story wird dann mit dem gesamten kumulierten Aufwand in der Rechnung des nächsten Sprints auftauchen. Wenn der Auftraggeber sich entscheidet, eine Story abzubrechen und sie vom Backlog zu entfernen, wird die bisher geleistete Arbeit an dieser Story nach üblichen Regeln trotzdem abgerechnet. Die Regel macht Sinn, denn sie stellt für den Dienstleister sicher, dass seine Arbeit immer bezahlt wird und hilft dem Auftraggeber, sich selbst zu disziplinieren, keine unwichtigen Stories in das Backlog aufzunehmen.

Tabelle 4 – Teilweise bezahlter Sprint

Schritt 4: Iteration oder Abbruch.

Nach jedem Sprint hat der Auftraggeber die Möglichkeit, eine neue Iteration beginnend vom Schritt 1 erneut zu starten, wo er die Stories wieder priorisieren, neue hinzufügen oder manche streichen kann. Change Requests (Änderungswünsche) für die bereits abgeschlossenen Stories werden als neue Stories behandelt.

Alternativ kann der Auftraggeber das Projekt nach jedem Sprint abbrechen, wenn er das Gefühl hat, dass das Projekt alle notwendige Funktionalitäten erreicht hat und/oder das Budgetlimit bereits erreicht wurde. Da jeder Sprint in einem funktionierenden Zustand resultiert, ist es für den Auftraggeber eine risikolose Exit-Strategie.

Nach jedem Sprint hat der Auftraggeber die Möglichkeit eine neue Iteration zu starten oder das Projekt zu beenden.

Praxisbeispiele und Schlussfolgerungen

Das adVANTAGE-Modell wurde in der Praxis durch einen großen Deutschen Softwareherstellungsdienstleister – adesso AG – adaptiert. In einem Langzeit-Projekt entwickelte die adesso AG ein neues Vertragsmanagementsystem für eine große deutsche Versicherungsfirma.

Aufgrund der Komplexität des Systems waren sich der Auftraggeber und der Dienstleister einig, dass eine verlässliche Preiseinschätzung im Voraus unmöglich wäre. Durch die Implementierung des adVANTAGE-Modells waren die Parteien aber in der Lage, das Projekt in kleine individuelle User Stories zu teilen. Damit konnte man sehr schnell mit der Arbeit beginnen und überschaubare Einheiten in Rechnung stellen, was dem Auftraggeber einfaches Kostenmanagement ermöglicht hat. Die Zusammenarbeit war mehr produkt- und fortschrittorientiert und die einzelnen User Stories konnten mit einer hohen Qualität umgesetzt werden. Die Zeiterfassung für die Abrechnung wurde von jedem einzelnen Teammitglied für sich selbst gemacht, so dass der Aufwand an Formalitäten nicht höher war als bei klassischen Projekten. Den Erfahrungsberichten der beiden Parteien zufolge, konnte man keinen negativen Einfluss dieser Methode auf die Produktivität feststellen und man hat eine hohe Transparenz geschaffen.

Zum Abschluss muss man noch sagen, dass dieses Vertragsmodell grundsätzliches gegenseitiges Vertrauen sowie das Verständnis für die Risiken eines agilen Verfahrens verlangt, damit es effizient funktionieren kann. Die Autoren der Studie sind aber zuversichtlich, dass die Prinzipien der Risikoverteilung sowie fairen Stundenabrechnung auch in vielen anderen Projekten erfolgreich adaptiert werden können.

Referenzen.

1. Book M., Gruhn V., Striemer R. (2012) adVANTAGE: A Fair Pricing Model for Agile Software Development Contracting. In: Wohlin C. (eds) Agile Processes in Software Engineering and Extreme Programming. XP 2012. Lecture Notes in Business Information Processing, vol 111. Springer, Berlin, Heidelberg

Über den Autor:
Lukasz Gawrys ist Inhaber von Alphta Digital Lab und seit 8 Jahren in der Digital-Branche aktiv. Er hat vor der Gründung seiner Agentur für mehrere Startups in Berlin gearbeitet und IT-Management an der Steinbeis School of Management and Innovation studiert. Seine fachliche Expertise liegt in der Webentwicklung und agilen Projektmanagement-Methoden.