Die Schwierigkeiten beginnen schon mit dem traditionellen jährliche Budgetplanungsprozess: Er passt nicht zu agil. Warum ist das so? Um die Frage zu beantworten, müssen wir uns nur einmal anzuschauen, wie dieser Prozess üblicherweise abläuft. Die Budgetverhandlungen beginnen damit, dass jeder mehr Geld als eigentlich notwendig einfordert, um die Unsicherheit einer längerfristigen Planung einzupreisen.

Die fehlende unterjährige Flexibilität von Budgetanpassungen und die Tatsache, dass man im Zuge der Verhandlungen sowieso mit einer gewissen Kürzung rechnet, verstärkt diesen Effekt und blockt zudem Gelder, mit denen andere ProjekteProjekte finanziert werden könnten. Das ist nicht nur ein aufwändiger und ineffizienter Prozess, der die Unzufriedenheit der Beteiligten schürt, er sorgt auch für ein Phänomen, das vor allem in Wasserfall-Projekten auftaucht, das sogenannte Sandbagging. Alles zu Projektmanagement auf CIO.de

Teams schieben ein nicht aufgebrauchtes Budget entgegen der eigentlichen Projektplanung von Monat zu Monat weiter, nur um am Ende des Planungsjahres damit konfrontiert zu sein, deutlich mehr Geld ausgeben zu müssen als notwendig, um nicht in unbequeme Gespräche über eine schlechte Projektplanung verwickelt zu werden. Gleichzeitig können aufgrund fehlender Budgets keine zusätzlichen Unternehmensvorteile mittels weiterer werthaltiger Projekte generiert werden. Kurzum: Die klassische Budgetplanung verfolgt das Ziel, möglichst viel Sicherheit bezüglich der nächsten zwölf Monate (oder noch darüber hinaus) zu bekommen. Doch diese Art der Planung funktioniert heute nicht mehr - insbesondere nicht in einer sich rasant verändernden und schwer vorhersehbaren Projektlandschaft.

In der agilen Welt haben sich die Prioritäten verschoben. Nicht die "Planungssicherheit", sondern die Fähigkeit, sich schnell an verändernde Bedingungen anpassen zu können und möglichst viel und schnell aus Kundenfeedback zu lernen, steht im Vordergrund. Richtigerweise geht man nun davon aus, dass Ideen scheitern und schnelle Anpassungen, auch budgetärer Art, notwendig werden können. Eine Optimierung des Investments mit geeigneten Streuungsmethoden unter unsicheren Begleitumständen ist das Ziel. Darin unterscheidet sich diese Art der Budgetierung vom bisherigen Vorgehen: Sie konzentriert sich auf üblicherweise kürzere Zeiträume von zum Beispiel drei oder maximal sechs Monaten und lässt Anpassungen zu.

Das eine ist der Budgetplanungsprozess, das andere sind die Vertragsmodellen, die im Rahmen von Projekten die Zusammenarbeit mit Dienstleistern regeln. Oft werden die IT-Abteilungen mit beidem allein gelassen. Hier wäre eine ganzheitlich unternehmerische Betrachtung überfällig. Nur wenn die agile Transformation als Herausforderung angesehen wird, die verschiedene Unternehmensbereiche betrifft - und dabei beispielsweise auch Belange des Einkaufs und der Rechtsabteilung adressiert - lassen sich die Weichen für eine erfolgreiche Umsetzung gestellt.

Vertragsmodelle und Entscheidungskriterien

Um die Projektzusammenarbeit mit Dienstleistern zu regeln, gibt es folgende Vertragsmodelle:

1. Time-and-Material (Dienstleistungsvertrag)

2. Festpreis (Werkvertrag)

3. Output-basiert (transaktionsbasiert)

4. Outcome-basiert

5. Story-Point-basiert

6. Projektions-basiert

Es gibt gute Gründe, sich für das eine oder andere Vertragsmodell zu entscheiden. Wichtig dabei ist es, sich über die Entscheidungskriterien für die Auswahl im Klaren zu sein. Üblicherweise werden Kriterien wie Sicherheit hinsichtlich des Lieferergebnisses oder der anfallenden Kosten herangezogen. Manchmal findet zusätzlich noch eine Risikoanalyse statt, die die Herausforderungen für den Dienstleister beziehungsweise das eigene Unternehmen beim jeweiligen Vertragsmodell unter die Lupe nimmt.

Bei Time-and-Material werden die im Projekt zu liefernden Gegenstände nicht vertraglich vereinbart. Der Lieferant wird vielmehr aufgrund seines Zeit- und Materialeinsatzes bezahlt. Die Qualifikationen der eingesetzten Mitarbeiter sind dabei üblicherweise auch Vertragsbestandteil. Bei diesem Vertragsmodell kann es durchaus passieren, dass das Projektergebnis nicht den Erwartungen entspricht. Darin genau besteht das Risiko für den Auftragsgeber, da in einem solchen Fall oft weitere Kontingente beauftragt werden müssen, was zu erheblichen Mehrkosten führen kann. Dies zeigt auch, dass das Projektrisiko auf der Lieferantenseite gering ist. Vertrauen spielt also bei einem Dienstleitungsvertrag eine wichtige Rolle.

Einen anderen Ansatz verfolgt das Festpreismodell. Hier werden die Liefergegenstände so gut es geht im Vorfeld definiert und es wird ein Festpreis für deren Erbringung vereinbart. Dieses Modell verlangt vorab einen detaillierten Anforderungskatalog, was oft dazu führt, dass sich der Projektstart verzögert. Hinzu kommt, dass die Anforderungen zu Beginn häufig gar nicht vollständig bekannt sind.

Aus reiner Kostensicht ist das Festpreismodell für den Auftraggeber bequem. Allerdings kommt es in der Praxis häufig zu folgenden Problemen: Da der Dienstleister das höhere Kostenrisiko trägt und gerade bei IT-Projekten eben immer unerwartete Probleme auftreten können, versucht er gegen Ende der geplanten Projektlaufzeit das vorab festgelegte Lieferergebnis zu verwässern. Dabei hilft ihm, dass zu Beginn kaum alle Anforderungen ausreichend bekannt sein können.

Sie werden nur durch grobe Absichtsbeschreibungen definiert. Im späteren Projektverlauf kann es dann dazu kommen, dass der Auftraggeber versucht, immer mehr Inhalte umsetzen zu lassen. Hier sprechen wir typischerweise von einem Scope Creep. Außerdem verleitet dieses Vertragsmodell zum Fingerpointing, indem sich Lieferant und Auftraggeber gegenseitig für das Scheitern verantwortlich machen. Festpreismodelle sind demnach nicht geeignet, wenn es um den Aufbau gegenseitigen Vertrauens geht.

Output-basierte Vertragsmodelle kommen ursprünglich aus der Baubranche, der Ansatz wurde vor einigen Jahren auf IT-Projekte übertragen. Hier liegt das Hauptaugenmerk auf dem Lieferergebnis, nicht darauf, wie es erzielt wurde. Dieses Modell findet oft beim Erbringen von Serviceleistungen Anwendung, eher selten im Projektgeschäft.

Ein typisches Beispiel ist ein Servicevertrag, der vorsieht, dass eine bestimmte Anzahl an Tickets innerhalb einer bestimmten Zeitdauer unter Einhaltung vereinbarter Reaktionszeiten bearbeitet wird. Das Risiko verteilt sich hier gleichmäßig auf beide Vertragspartner. Während der Dienstleister das Risiko trägt, gegebenenfalls in kurzer Zeit zusätzliche Ressourcen zur Verfügung stellen zu müssen, um einen Peak bedienen zu können, trägt der Auftraggeber das Risiko, die falsche Menge an Tickets vereinbart zu haben. Folge kann eine Beeinträchtigung des operativen Geschäfts sein. Obwohl die Kosten üblicherweise gut kontrollierbar sind, zeigt sich ein anderes Problem: Der vertraglich festgelegte Output ist meist nicht an den Geschäftszielen des Unternehmens ausgerichtet. Dieses Modell trägt auch nicht automatisch zur Qualitätsverbesserung des Produkts bei.

Deshalb wurde das Outcome-basierte Vertragsmodell entwickelt. Das prominenteste Beispiel ist "Power by the Hour" von Rolls Royce. Die Flugzeugmotorensparte von Rolls Royce hatte in der Vergangenheit mit den Fluggesellschaften Serviceverträge nach dem Time-and-Material-Prinzip abgeschlossen. Bei diesen Verträgen standen die anfallenden Kosten in direktem Bezug zur Anzahl an Technikern und der Menge der verbrauchten Materialien. Im betrieblichen Alltag bedeutete das, dass Rolls Royce immer dann mit den Serviceverträgen verdiente, wenn die Flugzeuge der Kunden am Boden waren. Mit anderen Worten: Rolls Royce verdiente, wenn die Fluggesellschaften keinen Umsatz machten.

Rolls Royce hat dieses Modell inzwischen gegen ein anderes ausgetauscht, das sich am Geschäftserfolg der Fluggesellschaften orientiert: Fluggesellschaften zahlen nun eine Gebühr pro Stunde basierend auf der Anzahl der Flugstunden für ein Flugzeugtriebwerk. Dieses Vertragsmodell richtet sich also an den Kundenbedürfnissen aus und führt letztendlich zu einer Win-Win-Situation.

Solche Vertragsformen könnten sich beispielsweise auch am Zugewinn von Neukunden, der Kundenzufriedenheit oder der Verringerung der Kundenfluktuation ausrichten. Hier wird zwar eine bessere Risikoverteilung erreicht, unterm Strich erhöht sich aber das Risiko des Dienstleisters. Im schlimmsten Fall muss er sogar den gesamten Aufwand allein tragen. Ein solches Modell setzt ein hohes Maß an Vertrauen voraus, das ein Grundpfeiler der agilen Arbeitsweise ist. Weiterhin führt es einen wichtigen Entscheidungsfaktor ein, der häufig bei der Auswahl des Vertragsmodells gar nicht berücksichtigt wird - die Incentivierung.

Ein Story-Point-basiertes Vertragsmodell setzt eine reife, agile Projektorganisation voraus. Wie der Name erahnen lässt, stammt dieses Modell aus dem Scrum-Umfeld. Das Lieferergebnis ist nicht von Beginn an detailliert ausdefiniert, sondern zeigt eine gewisse Flexibilität. Die Projektkosten werden, und darin liegt ein Kritikpunkt an diesem Vertragsmodell, in Story-Points angegeben. Dies widerspricht dem eigentlichen Prinzip von Story-Points und suggeriert eine mögliche Umrechnung von Story-Points in Geldeinheiten.

Zudem bleibt die Frage nach der Verlässlichkeit einer abstrakten Schätzung auf nicht unbedingt detailliert definierte Lieferergebnisse, wobei es in der Natur der Story-Points liegt, dass diese Ergebnisse vielen Einflussfaktoren unterliegen und hohe Abweichungen damit einhergehen. Es kommt dann zu einer Vermischung einer - eher um Sicherheit bemühten - Wasserfall-basierenden Denkweise mit Begrifflichkeiten aus der agilen Welt.

Beim Story-Point-Modell wird der Kostenrahmen als Kapazität angegeben. Nehmen wir zum Beispiel an, das Projektteam eines ERP-Projekts hat eine Kapazität von 1.000 Story-Points für den Rollout eines Templates zur Verfügung. Bei jeder neuen Anforderung ergeben sich nun zwei Optionen: Entweder wird sie neu entwickelt oder das Team verwendet eine bereits implementierte Funktion des Templates. Die erste Option, wird die zur Verfügung stehende Kapazität an Story-Points stärker belasten als die zweite.

Damit wird das verfolgte Ziel bezüglich der Incentivierung deutlich. So oft wie möglich sollen schon vorhandene Funktionen verwendet und die Standardisierung gefördert werden, um Story-Points einzusparen und für andere, innovative Entwicklungen zu verwenden.

Angelehnt an das Story-Point- und Output-basierte Vertragsmodell ist auch ein Projektions-basiertes Vertragsmodell denkbar. Hierbei wird anhand einer kurzen Erkundungsphase ein voraussichtliches Umsetzungsvolumen - zum Beispiel die Anzahl von umgesetzten Referenzelementen - innerhalb eines definierten Bearbeitungszeitraums oder eines Sprints abgeleitet. Ziel ist es, sowohl den Projektumfang als auch das Umsetzungsvolumen in einer bestimmten Zeiteinheit abschätzen zu können.

Dadurch kann der Kostenrahmen als Umsetzungsvolumen angegeben werden und ermöglicht damit einen gewissen Output als Zielwert inklusive eines "Risk Shares", also der Festlegung, wie bei signifikanten Abweichungen zu verfahren ist. Eine regelmäßige Überprüfung der Parameter im Projektverlauf eröffnet zudem die Chance, Anpassungen vorzunehmen. Die Incentivierung für den Dienstleister besteht darin, Abläufe in der Umsetzung sowie die Produktqualität zu verbessern. So kann er Mehraufwand verhindern. Der Auftraggeber sollte das Ziel verfolgen, sich auf werthaltige Anforderungen zu konzentrieren, damit der höchste Nutzen mit kalkulierbaren Kosten und kurzer Time-to-Market verbunden wird. Ein entscheidender Vorteil dieser Variante ist zudem, dass oft früh erkannt werden kann, ob das Projekt zu einem Erfolg führen wird (Stichwort fail fast).

Voraussetzung ist hier ein mindestens zweiphasiges Vertragsmodell, wobei in der ersten Phase die Kosten (Time-and-Material oder Festpreis) für eine kurze Laufzeit zur Projekterkundung festgelegt werden. In dieser Phase ist es das Ziel, die minimal notwendigen Voraussetzungen für die technische Projektdurchführung zu ermitteln (zum Beispiel über einen bis drei Sprints bei Scrum) und elementare Anforderungen im Rahmen einer vollständigen, agilen Arbeitsweise umzusetzen (für einen bis drei Monate etwa).

Anhand der Ergebnisse dieser Phase lässt sich ableiten, welches Aufkommen an neuen Anforderungen im Durchschnitt entstehen wird und wie viele davon über einen bestimmten Zeitraum bearbeitet werden können. In den folgenden Vertragsphasen wird ein Kostenrahmen für ein Umsetzungsvolumen vereinbart, wobei die Anforderungen nicht unbedingt weit im Voraus definiert werden müssen. Es reicht aus, dies jeweils vor dem Start der Bearbeitungsphase zu tun - zum Beispiel im Backlog Refinement vor der nächsten Sprint-Planung.

Dieses Verfahren kann bei richtiger Anwendung eine gute Projektion hinsichtlich Kosten, Nutzen und Laufzeiten liefern. Ein weiterer Vorteil ist, dass nicht zwingend eine reife Projektorganisation für agile Methoden existieren muss. Durch regelmäßige Auswertungen der Ergebnisse über einen gewissen Zeitraum hinweg kann das Modell individuell an Leistungsänderungen angepasst werden.

Die Outcome- und Story-Point-basierten Vertragsmodelle haben gezeigt, dass die Incentivierung im agilen Kontext ein wichtiges Entscheidungskriterium sein kann. Es können ganz im Sinne des agilen Grundgedankens Win-Win-Situationen entstehen. Das Time-and-Material-Modell ist weniger geeignet, da es dem Dienstleiser Anreize liefert, das Projektziel nur langsam zu erreichen, um mehr Ressourcen verkaufen zu können.

Das Incentive bei einem Festpreis-Modell liegt für den Dienstleister darin, Ressourcen möglichst zu reduzieren. Das kann grundsätzlich im Sinne des Auftraggebers sein, da das Projektteam klein bleibt und nicht unnötig aufgebläht wird. Allerdings führt dies nicht zwangsweise zu einem besseren Projektprodukt. Beim Output-basierten Vertragsmodell gibt es im Prinzip kein Incentive, das dem agilen Gedanken entspricht. Anders sieht das beim Projektions-basierten Vertragsmodell aus. Die Incentives Optimierung der Lieferabläufe und Produktqualität für den Dienstleister sowie das Erstellen werthaltiger Anforderungen für den Auftraggeber entsprechen den agilen Grundprinzipien.

Risk-Adapdability-Matrix

Die Risk-Adaptability-Matrix bringt zwei wichtige Entscheidungsfaktoren bei agilen Projekten zusammen, nämlich die des Risikos und der Anpassungsfähigkeit hinsichtlich sich verändernder Anforderungen. Abbildung 1 zeigt die Einordnung der beschriebenen Vertragsmodelle in diese Matrix. Dabei wird bei der Einordnung des Risikos zwischen Auftraggeber (A) und Dienstleister (D) unterschieden.

Es zeigt sich eindeutig, dass Festpreis- und Output-basierte Kostenmodelle nicht für agile Projekte geeignet sind. Der Grund ist hauptsächlich die geringe Anpassungsfähigkeit, die beiden Vertragsmodellen zugrunde liegt. Sie hat wenig mit dem agilen Grundgedanken, offen für Veränderungen zu sein, gemeinsam. Beim Festpreis-Modell kommt hinzu, dass das Risiko sowohl für den Dienstleister als auch für den Auftraggeber hoch ist.

Time-and-Material-, Outcome-basierte und Projektions-basierte Vertragsmodelle sind hingegen gut geeignet für agile Projekte. Sie zeigen ein vergleichsweise niedriges Risikoprofil und ein hohes Maß an Anpassungsfähigkeit. Dabei überrascht Time -and-Material mit einer im Vergleich höheren Flexibilität, die vor allem den sich ständig ändernden Anforderungen gerecht wird. Einzig die hohe Risikodiskrepanz zwischen Dienstleister und Auftraggeber erweist sich als schwierig.

Der Schlüssel, um diese zu verringern, besteht in der richtigen Incentivierung des Projektteams, womit beide Parteien eingeschlossen sind. So wäre es denkbar, ein Incentive zu verwenden, das sich am Unternehmensziel orientiert, wie beispielsweise ein Zugewinn an Neukunden, Steigerungen von Downloadraten und Nutzungszeiten oder eine Verringerung der Kundenfluktuation, womit ein hybrides Vertragswerk aus Time-and -Material und Outcome-basierten Bestandteilen entsteht. Das Projektions-basierte Vertragsmodell zeigt eine hohe Anpassungsfähigkeit bei einem relativ geringen Risikoprofil, welches - und darin besteht ein Vorteil dieses Vertragsmodells - möglichst gleichmäßig auf Auftraggeber und Dienstleister verteilt ist.

Ein Story-Point-basiertes Vertragsmodell ist prinzipiell für agile Projekte geeignet - jedoch ist hierfür eine stabile und reife Projektorganisation mit agilen Methoden die Voraussetzung. Als Incentive bei Software-Projekten steht hier eindeutig die unternehmensweite Standardisierung im Vordergrund. Darin liegen aber auch die Schwierigkeit und das erhöhte Risiko begründet. Dieses Incentive ist primär für den Auftraggeber wichtig, weniger für den Lieferanten. Hier gilt es also Vorsicht walten zu lassen. Nicht selten hat sich gezeigt, dass ein Story-Point-basiertes Modell bei wenig umsichtiger Verwendung schnell in eine Art traditionelles Time-and-Material verwandelt wird - zu Gunsten des Lieferanten und zu Ungunsten des Auftraggebers.

Erwartungsgemäß gibt es keine klare und einfache Lösung für das komplexe Problem der Budgetierung und Vertragsgestaltung im agilenagilen Kontext. Dabei haben wir am Beispiel einer Mischung aus Time-and- Material und Outcome-basiertem Modell oder dem Beispiel des Projektions-basierten Modells bereits gesehen, dass der Schlüssel in einer individualisierten, an den Projekt- und Unternehmenskontext angepassten Kombination verschiedener Modelle liegt, da dadurch die agilen Anforderungen am besten bedient werden können. Denkbar sind auch andere hybride Modelle. So könnte man einen gewissen Prozentsatz der gesamten Projektkosten als Festpreis abbilden und den verbleibenden Kostenblock an ein Outcome-basiertes Modell koppeln. Alles zu Agile auf CIO.de

Wichtig ist es, ein gesundes Maß zwischen der praktischen Anwendbarkeit eines Vertragsmodells und der Komplexität zu finden. Das ist notwendig, um für beide Vertragsparteien ein faires Modell zu entwickeln.

Vertrauen, Anpassungsfähigkeit, Incentivierung

Wir haben in diesem Artikel verschiedene Vertragsmodelle hinsichtlich ihrer Anwendbarkeit für agile Projekte verglichen. Dabei spielen insbesondere drei Aspekte bei der Auswahl des passenden Vertragsmodells eine zentrale Rolle. Zum ersten ist zu häufig ein fehlendes Vertrauen zwischen den Vertragsparteien, aber auch unternehmensintern zwischen Fachbereichen und den IT-Abteilungen erkennbar. Vertrauensvolle Partnerschaften sind jedoch eine Grundvoraussetzung für jede agile Organisation. Time-and-Material, ein Outcome-basiertes oder ein Projektions-basiertes Vertragsmodell sind hier am geeignetsten.

Zum zweiten ist die Anpassungsfähigkeit an sich ändernde Umstände essenziell. Dies überrascht wenig im agilen Kontext; allerdings gibt es wenige Vertragsmodelle, die diesem Aspekt wirklich Rechnung tragen und sinnvoll in der Praxis eingesetzt werden können. Festpreis- und Output-basierte Vertragsmodelle scheiden deshalb aus. Zum dritten wird das Thema Incentivierung bei der Auswahl des richtigen Vertragsmodells vor allem vor dem Hintergrund agiler Projekte immer wichtiger. Nur wenn mittels der richtigen Incentivierungen Win-Win-Situationen zwischen Lieferant und Auftraggeber (oder auch zwischen den Fachbereichen und der IT) geschaffen werden, kann eine Transformation hin zu agilen Arbeitsweisen erfolgversprechend vorangetrieben werden.