Warum agile Projekte aus Kostensicht besser planbar sind
Wie oft haben wir diese Situation schon erlebt: Es gibt ein bestimmtes Vorhaben und wir wissen auch ungefähr, was wir damit erreichen wollen. Die erste Frage aber lautet: Was wird uns das Ganze kosten? Und sind wir einmal ganz ehrlich, diese Frage stellen wir uns alle täglich auch in unserem persönlichen Leben. Was würde das Ganze kosten? Es ist eine absolut valide Frage, denn vor allen Dingen im unternehmerischen Leben sind wir von Erlösen und Kosten beeinflusst. Bewegen wir uns im agilen Projektumfeld, tun wir uns hingegen mit der Kosten- und folglich auch mit den Budgets für agile Teams unglaublich schwer.
Planung hat uns schon immer gut getan
Schauen wir in die Vergangenheit, wo das Projektmanagement seinen Ursprung hat. Wir werden feststellen, dass die Menschen schon immer in Projekten gedacht haben. Sei es das Anlegen, Bestellen und Ernten von Äckern, das Erlegen von Tieren oder das Errichten von Bauten. Schon damals erkannte man, dass eine gewisse Planung, um ein bestimmtes Ziel zu erreichen, von Vorteil sein kann (zu den Zielen gibt es hier einen Post).
Je größer die Bauten der Menschheit wurden, desto genauer musste man planen. Und auch damals mussten die Herrscher, welche diese Bauten in Auftrag gaben, vorab überlegen, ob sie sich das leisten können. Zudem wurden auch damals zu den verschiedenen Bauabschnitten die Leute Abschnitt für Abschnitt entlohnt und so manche Burg wurde nicht fertig gestellt, weil der Burgherr bankrott war. Dennoch spielten die Kosten der Vorhaben eine immer bedeutendere Rolle, zu Recht. Und da wir den Ursprung des heutigen Projektmanagements vor allen Dingen aus dem Baugewerbe heraus kennen, ergab sich das bekannte magische Dreieck aus Umfang (Scope), Zeit und Kosten.
Die ewige Frage nach den Kosten
Diese Grundlagen des Projektmanagements haben wir auch in der klassischen Software- oder Produktentwicklung adaptiert und von dort gelernt: Ein Ziel wird ausgerufen, Zeiträume für die verschiedenen Phasen des Projektes werden festgelegt und der Aufwand im Sinne von Tagewerken wird geschätzt. Multipliziert mit dem Stunden- oder Tagessatz der Beteiligten bekommt man eine Aufwandsschätzung auf den Tisch. Dann packt man noch einen Risikoaufschlag drauf und fertig ist die Budgetierung für unser Projekt. Um es auf einen kurzen Nenner zu bringen: Wir fragen also nach dem (Scope): was wollen wir erreichen und wie lange (Zeit) werden wir dafür brauchen. Voraussetzung dafür ist, dass wir das was und gleichzeitig auch das wie lange so exakt wie möglich beschreiben und schon frühzeitig abschätzen können.
Auf Basis der Zeitschätzung können wir eine mehr oder weniger exakte Voraussage treffen, wie sich die Kosten des Projektes gestalten werden. Hier haben Unternehmen, welche sich in gut strukturierten und fest beschriebenen Prozessen bewegen, einen klaren Vorteil. Sie sind vor allen Dingen in solchen Planungen in einer besseren Ausgangslage, weil der Scope, das „was“, sehr genau bestimmbar ist und daher bessere Vorhersagen zulässt. Und auch die Analogie zur Bauwirtschaft wird deutlich. Wenn völlig klar ist, was getan werden muss, und sich die Rahmenbedingungen sehr langsam oder gar nicht ändern – wir also mit keinerlei Überraschungen rechnen sollten außer denen, die der Architekt nicht vorgesehen hat – sind die Kosten eines solchen Projektes vorab relativ genau bestimmbar.
Und was bekomme ich für mein Budget?
Etwas anders gelagert ist es im agilen Projektumfeld: Hier haben wir akzeptiert, dass der exakte Endzustand des Produktes am Anfang des Projektes nicht beschrieben werden kann. Folglich kann weder irgendjemand den (scheinbar) exakten Aufwand dafür schätzen, noch irgendwie bestimmen, wann der Zustand „Fertig“ – im Sinne von Funktion und Projektbudget – erreicht worden ist. Das wie lange ergibt sich also nicht aus einem gut verstandenen was, vielmehr fixieren wir die Zeit (wie lange: Time-Box) und heben das „Was“ auf eine andere Ziel-Ebene (und sind nebenher noch beim wie sehr variabel)
Wir gehen also davon aus, dass wir in bestimmten, festgelegten Zyklen einen Mehrwert liefern. Wie wir das bewerkstelligen, werden wir anfänglich noch nicht exakt beschreiben können. Auch was genau dieser Mehrwert sein wird, das lässt sich am Anfang nur schwer ausführen. Gleichwohl können wir sehr deutlich sagen, was uns ein Release am Ende an Investitionen abverlangen wird, denn genau diese Rahmenbedingungen ändern sich nicht. Die Kapazitäten des Teams sowie der Overhead sind bekannt und können von vornherein benannt werden. Der einzige Unterschied ist, dass wir uns zu einem festgelegten Zeitpunkt in der Zukunft eben nicht einen exakt beschriebenen Zustand einer Software oder eines Produktes mit allen möglichen Features und Eigenschaften festlegen und vereinbaren können.
Budgets werden regelmäßig gerissen
Die wahre Herausforderung scheint also nicht das Budget zu sein. Vielmehr es kommt darauf an, eine geeignete Ebene der Umfangsbeschreibung zu finden. Hierbei helfen uns sehr gut die verschiedenen Ebenen der agilen Produkt-Entwicklung. Zunächst hier eingeordnet in diesem Modell, welches die Granularität der verschiedenen Elemente der (agilen) Produktplanung zeigt.
Diese verschiedenen Stufen der Produktentwicklung sind in der klassischen und agilen Vorgehensweise im Grunde gleich. Der einzige Unterschied – neben den Bezeichnungen – ist, dass wir bei der klassischen Vorgehensweise von Anfang an versuchen, die zu erledigenden Aufgaben in höchster Granularität detailgenau zu beschreiben, um eine möglichst exakte Kostenschätzung zu ermöglichen. Je weiter wir nach rechts kommen und umso granularer wir die Aufgaben beschreiben können, desto genauer können wir eine (annähernd genaue) Budgetabschätzung abgeben. Anders, wenn wir neben der Granularität unsere Aufgabenbeschreibung auch noch deren Zeitvarianz in Betracht ziehen: Die Beständigkeit oder Zeitvarianz der einzelnen Elemente einer Produktentwicklung ist nämlich völlig unterschiedlich, insbesondere dann, wenn die Rahmenbedingungen einer gewissen Unsicherheit unterliegen (Siehe auch Stacey Matrix). Während eine Idee und eine darauf basierende Produktvision eine gewisse Stabilität vorweisen, können sich die konkreten Anforderungen und Ausgaben recht schnell ändern.
Budgets für agile Teams & Projekte
Wie wir weiter oben festgestellt haben, können wir den Umfang bei agilen Projekten eben nicht detailgenau beschreiben. Wir wissen aber, wie viele Ressourcen und wie viel Zeit wir für ein bestimmtes Projekt oder ein bestimmtes Ziel aufwenden können. Ziel muss es also sein, unsere Vereinbarungen mit Kunden, Stakeholdern, Product Ownern oder wem auch immer, in der Zeitvarianz-Granularitäts-Matrix so weit links wie möglich einzuordnen; mindestens aber bei jedem Element in jenem Bereich, der mit dem Budget-Horizont übereinstimmt.
Bilde ich also beispielsweise meine Produkt Roadmap auf der zeitlichen Basis von Quartals- oder Halbjahreszyklen ab, kann ich hieraus Key-Features, Ziele und Metriken entnehmen und in die noch immer fluide Umfangsvereinbarung mit meinen Auftraggebern übernehmen. Voraussetzung hierfür freilich ist, diese Dinge auch beschrieben und vereinbart zu haben und damit eine Grundlage zu besitzen, um die Verhandlungen mit meinen Geldgebern entsprechend zu führen. In „Wir sind jetzt Agil – Willkommen im Chaos“ habe ich genau das noch noch einmal genauer beleuchtet.
Hier können die Techniken, welche in der OKR Methodik Anwendung finden, sehr gut helfen. Gleichzeitig schaffe ich hier die Grundlage, Changes auf dieser Ebene explizit zu machen ohne dass dies eine Auswirkung auf das Budget hat. Letztendlich geht es um den Leistungsumfang und am Ende um den Nutzen (Value) des Kunden und nicht um die Kosten (die ja stabil sind).
Fazit
Die Planung klassischer Projekte geht davon aus, dass man den Zielzustand exakt und detailgenau beschreiben kann. Auf Basis dessen ist dann eine nahezu präzise Kostenabschätzung möglich. Im Hinblick auf eine Budget- und Kostenplanung ist dies von Vorteil. Ressourcen und Zeit werden als Fixum angenommen und damit die eigentlichen Kostentreiber benannt. Vor allen Dingen im Technologieumfeld diese Zielzustände allerdings nur auf einer groben Nutzenebene beschreibbar. Die Aufgabe hier besteht darin, die Leistungsvereinbarungen, also den Nutzen (Value), auf eine andere Zielebene zu heben, welche vorab beschrieben und vereinbart sein muss. Die Zeit ausufernder Projektbudgets ist damit Geschichte.
Three Key-Take-Aways
- Agile Projekt-Vorgehensweisen lassen sich besser in klassische Budgets fassen.
- Voraussetzung ist eine qualitativ hochwertige Produkt-Planung, welche die Zeitvarianz der Planungselemente und den Budget-Horizont in Übereinstimmung bringt.
- Changes haben damit nie eine Auswirkung auf das Budget. Der Kundennutzen wird bei gleichbleibenden Kosten deutlich gesteigert.
Weiterführende Links
- Informationen zur Stacey Matrix
- Was ist die Sunken Cost fallacy
- Hinweise zu OKR
Titelbildquelle: Photo by Mille Sanders on Unsplash
