Agile Fixed Price Projekte
26. März 2014
Unternehmen, die in stark regulierten Märkten agieren, haben häufig die Anforderung, für eine Investition z.B. in ein Software-Projekt im Vorfeld einen Business Case zu rechnen. Hierbei geht es darum, den Nutzen den Kosten gegenüberzustellen, schließlich geht es außer bei strategischen Projekten um das Erwirtschaften von Gewinn. Der Nutzen lässt sich mit verschiedensten Methoden bestimmen: Eine davon ist im Beitrag „Business Value messen“ in diesem Blog beschrieben. Jetzt gilt es, auch die Kosten des Projektes zuverlässig vorab zu bestimmen. Doch geht das überhaupt?
Die Erfahrungen aus dem klassischen Projektmanagement zeigen, wie schwierig, zeitaufwendig und damit teuer diese Aufgabe sein kann. Langwierige Kostenschätzklausuren und Plausibilisierend wirken sich auch negativ auf das Time-to-Market des Projekts aus. In der Regel werden auch Kosten für Funktionalität geschätzt, die am Ende keiner benötigt. Auch die Verzögerung des Produktionsstarts erzeugt Umsatzausfälle und damit Kosten, die häufig niemand auf der Rechnung hat.
Die einzige Variable im eisernen Dreieck des klassischen Projektmanagements aus Kosten, Termin und Inhalt ist die Qualität. Senkt man diese aus Kosten-, Termin oder Inhaltsgründen, reduziert man auch die Kundenzufriedenheit und damit den Return on Invest, mithin den erzielten Nutzen für den Kunden und das Unternehmen.
Doch es gibt einen Ausweg aus dieser Klemme, der besonders gut mit agilen Vorgehensweisen wie Scrum harmoniert. Dieser Ausweg weicht das eiserne Dreieck auf, indem er den Inhalt (Scope) in Frage stellt und dabei die Kosten limitiert. Das wird besonders das Controlling freuen, da Projekte in Budget abgeschlossen werden. Auch der Kunde ist erfreut, denn er erhält endlich gute Qualität und die Funktionalitäten, die er wirklich benötigt.
Wie funktioniert das?
Indem die Kostenschätzung des klassischen Vorgehens in eine Maximalkostenrechnung mit Kostencontrolling überführt wird.
Zunächst werden die Maximalkosten bestimmt, also die Kosten, die das Projekt maximal erzeugen darf, um noch wirtschaftlich zu sein. Hierzu werden vom erwarteten monetären Nutzen die Gewinnerwartung und die Verwaltungs- und Allgemeinkosten abgezogen. Diese Maximalkosten stellen das Projektbudget dar und werden als Projektkosten im Vertrag zwischen Auftraggeber und Auftragnehmer vereinbart.
Der Inhalt des Projektes wird im Vertrag nur grob spezifiziert, der Auftraggeber muss keine vollständigen und abgenommenen Fachkonzepte beibringen. Wichtig ist jedoch eine klare Definition des Ziels, welches der Auftraggeber durch den Einsatz der zu entwickelnden Software erreichen will.
Auf Basis dieses Ziels und der groben Projektinhalte werden die Anforderungen gemeinsam spezifiziert. Wird für die Durchführung des Projektes z.B. Scrum eingesetzt, entsteht so ein abgeschätztes, priorisiertes Product Backlog, welches die Anforderungen (Scope) an das Software-Projekt nach Geschäftswert sortiert beschreibt, die höchste Wertigkeit soll dabei als Erstes umgesetzt werden. Hierbei gilt als Regel: Jede Anforderung, die noch nicht in die Umsetzung gelangt ist, kann kostenneutral durch eine andere Anforderung gleicher Komplexität ersetzt werden, es wird also statt mit Change-Requests mit sogenannten Exchange-Requests gearbeitet. Die Abschätzung der Anforderungen erfolgt in einer abstrakten Größe (üblicherweise Story Points), die die Komplexität der abzuschätzenden Anforderung relativ zu einer Normanforderung beschreibt.
Um die entstehenden Kosten bei der Umsetzung steuern zu können, wird bei der Realisierung in Sprints (Iterationen mit fixer Länge) die Geschwindigkeit (Velocity) des Teams gemessen, dass heißt, wieviele Story Points auf die im Sprint umgesetzten Anforderungen entfallen. Nun werden die vom Team in der Iteration verbrauchten Arbeitstagen durch die erbrachten Story Points geteilt. Dieser Wert wird mit dem bestimmbaren internen Kostensatz pro Tag multipliziert und ergibt das verbrauchte Budget.
Summe der Arbeitstage aller Teammitglieder der Iteration/erbrachte Story Points = Wert eines Story Points
Wert aller erbrachten Story Points * Kostensatz pro Tag = verbrauchtes Budget
Auf diese Weise kann sogar ein Kostencontrolling für mehrere Projekte durchgeführt werden, die vom Team gleichzeitig im Sprint bearbeitet werden. Über die Story Point Abschätzungen kann man das verbrauchte Budget gewichtet über die Projekte verteilen, es entsteht volle Kostentransparenz.
Kombiniert man das Kostencontrolling mit der Releaseplanung, die eine Aussage macht, in welchem Sprint welche Anforderung umgesetzt werden wird, kann auch die Budget- und Terminentwicklung vorher gesagt werden. Das Schöne daran ist, dass mit sinkendem Restbudget Anforderungen mit immer geringerem Wert umgesetzt werden. Damit fällt am Ende des Budget die Entscheidung, das Projekt zu beenden, leicht, denn die wichtigsten und wertbringendsten Anforderungen wurden umgesetzt. „Schmuck am Nachthemd“, den man nicht wirklich benötigt, wird auch nicht realisiert, erzeugt also auch keine Kosten. Und das Kostencontrolling beruht auf Messungen, nicht auf Schätzungen.
Wichtig für den Erfolg dieses Verfahrens ist die Einhaltung folgender Werte
- Vertrauen
- Mut
- Transparenz
Der Auftraggeber braucht Vertrauen, dass er, obwohl er bei Vertragsabschluss nicht exakt weiß, was er bekommt, doch das Richtige bekommt. Dieses Vertrauen muss sich der Auftragnehmer erarbeiten. Hierzu gehört auch, dass beide Seiten mit Mut an die Sache herangehen, dieses „Experiment“ zu wagen und mit einem unscharfen Vertrag zu starten. Wesentlicher Faktor dafür, dass aus diesem Mut kein Wagemut mit unkalkulierbarem Risiko wird, ist die Transparenz über die Dinge, die während der Arbeitsphase tatsächlich bearbeitet werden. So entsteht am Ende des Auftrags nicht die Software, von der der Auftraggeber glaubte, sie zu brauchen, sondern die Software, die ihm tatsächlich nützt.
Wenn Sie mehr zu diesem Thema erfahren wollen, sprechen Sie uns gern an oder lesen Sie hier weiter:
Agile Kostenmodellierung im Business Case
Quelle Foto: © apops – Fotolia.com
| Keine Kommentare