Scrum-Projekte budgetieren

Wie kann man eigentlich (agile) Projekte budgetieren? Wenn man noch nicht weiß, wie lange das Projekt schlussendlich dauern wird? Müssen wir dafür nicht erst alle Aufgaben wissen, um den Aufwand abzuschätzen? Nein. Denn wir haben in aller Regel wahnsinnig viele Daten, die wir zur Planung nutzen können.

Nutzt historische Daten!

2015 habe ich schon einmal über das Schätzen von Projektaufwänden geschrieben./1/ Schaut gern nochmal in den Beitrag. (Ich bin übrigens kein Freund von NoEstimates. Wenn wir das Geld und die Zeit von anderen Leuten verbrennen, haben diese das Recht zu erfahren, wie lange etwas dauern und wieviel Geld es sie kosten wird!)

Bild von Scott Graham auf Unsplash

Meist ist ein Projekt, über deren Umsetzung wir nachdenken, in ähnlicher Form in der eigenen Organisation oder auch in anderen Unternehmen schon einmal gelaufen. Ein paar Details werden zwar anders sein. Aber unsere grundsätzliche Herangehensweise, das Kundenverständnis, ein Teil der eingesetzten Technologie und die Partner, mit denen wir zusammenarbeiten, bleibt gleich. Daher lohnt es sich, Daten von vergleichbaren Projekten zu sammeln (ich empfehle von mindestens fünf):

• Wie viel KALENDERzeit ist vergangen - von Projektbeginn bis -ende?
• Wie viele Bearbeitungstage wurden auf die Projekte TATSÄCHLICH gebucht?
• Welche Kosten sind in dieser Zeit entstanden?
• Was wissen wir über Art und Menge der Aufwandstreiber in diesem Projekt? Bei IT-Projekten sind Treiber oft die aktiven Anwender und die unterschiedlichen Module (weil sie für unterschiedliche Geschäftsprozesse stehen).

Sollten wir die Daten (nicht alle) im eigenen Haus haben, müssen wir sie uns durch Herumtelefonieren und Recherchieren besorgen. 

Sobald sie uns vorliegen, können wir den Aufwand und ihre Treiber in Vergleich setzen und das könnte z.B. so aussehen:

• Projekt A: 104 PT, 105 aktive Anwender, 2 Module
• Projekt B: 176 PT, 200 aktive Anwender, 2 Module
• Projekt C: 67 PT, 66 aktive Anwender, 2 Module
• Projekt D: 96 PT, 80 aktive Anwender, 1 Modul
• Projekt E: 72 PT, 90 aktive Anwender, 1 Modul (aber ein anderes als in Projekt D)
  

Der Aufwand schwankt in diesem Beispiel pro aktivem Anwender zwischen 0,8 und 1,2 Personentagen - wobei ein Modul mehr Aufwand verursacht als ein anderes (aus dem Vergleich von Projekt D mit E). 

Nun können abfragen, wie viele aktive Anwender im neuen Projekt zu erwarten sind. Und ob beide Module eingesetzt wird bzw. welches davon. 

Nehmen wir an, wir erwarten 150 Anwender für das aufwändigere Modul aus Projekt E. Dann wäre es eine gute Idee mit 180 Tagen in die nächste Planungsrunde zu gehen (150 Personen x 1,2 PT/Person).

Dieses Vorgehen nennt man übrigens "Reference Class Forecasting". 

Für mich ist besonders wichtig, dass all dies mit den Expert:innen zu besprochen werden. Und es ist gut, wenn das Ausrechnen des Aufwands dabei keine einfache und schon gar keine simple Formel ist. 

DASS der neue Planungswert zu berechnen ist, liegt schlicht daran, dass es sehr wahrscheinlich ist, dass die Dinge wieder sehr ähnlich laufen werden, wie in den vorangegangenen Projekten. Aus der Diskussion können die Expert:innen aber die Unterschiede herausfiltern und so aus den bisherigen Erfahrungen lernen:

• Wie unterscheiden sich die abgelaufenen Projekte untereinander? Inwiefern ist das anstehende Projekt anders?
• Wie ändert sich der Aufwand, wenn sich die Größenordnungen ändern? Was passiert, wenn wir 10.000 aktive Anwender haben oder 10 Module brauchen?
• Können wir ein Projekt in kleinere Teile zerlegen?

Bewertet erst den Nutzen

Bisher lag der Planungsfokus fast ausschließlich auf den Kosten, Denn die ließen sich scheinbar leichter erheben und nachverfolgen. Allerdings wurde dabei vergessen, dass wir uns mit Projekten einen Vorteil erarbeiten wollen. Es fehlte uns eine einfache Methode, um diesen Vorteil in Geld- oder Finanzwerten zu fassen.

Wer eine Anleitung genau dafür sucht: Für IT-Projekte finde ich das Benefits-Management-Buch von Ward und Daniel immer noch eine gute Anleitung./2/ Die Autoren legen schlüssig dar, dass IT dauerhafte Änderungen bei den Abläufen unterstützt. 

Nur die DAUERHAFTEN ÄNDERUNGEN führen zu ZUSÄTZLICHEN ERLÖSEN oder KOSTENEINSPARUNGEN. Daher sollten wir genau nach diesen Änderungen suchen. Um eben dieses Erlöse oder Einsparungen abschätzen zu können.

Doch auch hier sollten wir vorsichtig sein und uns immer einmal wieder an Taiichi Ohnos Worte erinnern: Was nützt es, wenn eine Maschine mehr Teile produzieren kann, wir sie aber nicht verkaufen können? Was ist der Vorteil von einer automatischen Maschine, wenn ich weiterhin eine Person brauche, um diese Maschine zu überwachen?

Von welchen Kunden kommen die zu erwartenden Erlöse wirklich? Sind das Wunschkunden oder gibt es diese Kunden tatsächlich? Sind sie bereit, den echten Preis dafür zu bezahlen? Welche Arbeitskraft brauchen wir nach dem Projekt NICHT mehr? Was machen diese Personen dann?

Gibt es günstigere Alternativen?

Wenn die Erlöse oder Einsparungen trotzdem nicht zu bewerten sind, gibt es zwei Lösungen: 

• Aus unternehmerischer Sicht sollte das Projekt gar nicht erst gestartet werden. Zumindest fangen wir das Projekt so lange nicht an, solange wir nicht mehr über den Nutzen wissen.
• Wir machen Vorstudien oder kleine Experimente, um Erlöse oder Einsparungen abzuschätzen. Danach wird phasenweise investiert.
  

In der Realität gibt es oft viel mehr Optionen als den EINEN Projektantrag, der auf dem Tisch liegt. 

Wie könnte man bei einem ganz kleinen Kundenkreis Geld verdienen? Wie könnte man in einem Teilbereich mit Änderungen anfangen, um Kosten einzusparen? Wir können auch wie ein Investor eine bestimmte Summe in die Hand nehmen: Wenn das Projektteam für X EUR mind. eine Summe von Y erwirtschaftet, gibt es die nächste Tranche. (Der Fachbegriff hier für lautet "real options").

Bevor wir ein Projekt starten, können (und sollten) wir uns ohnehin die Frage stellen, ob wir mit vielen kleinen Verbesserungen und bestehenden Mitteln nicht auch schon gute Ergebnisse erzielen können. 

Vielleicht wird jetzt ein:e Leser:in einwenden: "Ja, Jan das steht doch aber auch in jedem guten Projektmanagementhandbuch. Bei PRINCE2 ist das sogar ein eigenes Thema." Ja, natürlich ist das so. 

Trotzdem ist für mich wichtig, hierauf immer wieder hinzuweisen. Denn viele Projektplaner folgen diesen Anleitungen ohne wirkliches Verständnis und sie gehen damit große, meist auch zu große Risiken ein. 

In vielen Unternehmen laufen zu viele Projekt gleichzeitig, um die sich zu wenig Leute kümmern. Früher frustrierte das vielleicht "nur" alle Projektbeteiligten (inklusive der verärgerten Klientel und Geldgeber). Heute aber brennen ebendiese Beteiligten aus und/oder wenden sich ab (und anderen Zulieferern zu). 

Führungskräfte, Mitarbeitende, KundInnen und Geldgeber verlassen also wegen solch (vermeintlich) aussichtsloser Situationen ihre Unternehmen. Das nur teilweise investierte Geld bringt dann nicht nur keine Rendite. Es ist einfach nur ein Strohfeuer - reine Verschwendung. Die Folge oft: Kosten werden eingespart, Gehälter gekürzt oder den KundInnen werden überteuerte Produkte verkauft.

Sollten wir das nicht besser verhindern?

Anmerkungen

• /1/ Jan Fischbach: Projektaufwände schätzen, Teamworkblog, erschienen am 03. Aug 2015, abrufbar unter http://www.teamworkblog.de/2015/08/projektaufwande-schatzen.html
• /2/ Ward, John ; Daniel, Elizabeth: Benefits Management : How to Increase the Business Value of Your IT Projects. New York: John Wiley & Sons, 2012.