Direkt zum Hauptbereich

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?

Sie wollen mehr über gute Projektarbeit lernen? Es gibt eine Übersichtsseite zum Thema Projektmanagement in diesem Blog. Dort finden Sie weitere Artikel, mit denen Sie sich in das Thema einlesen können.

Ihr wollt mehr über Scrum wissen? Wir haben eine Übersichtsseite zu Scrum, über die man sich in die wichtigsten Artikel in diesem Blog einlesen kann.

Anmerkungen

 

Kommentare

Beliebte Posts aus diesem Blog

Microsoft Teams: Die neuen Besprechungsnotizen - Loop-Komponenten

  Haben Sie in letzter Zeit in einer Teams-Besprechung die Notizen geöffnet? Dort sind inzwischen die Loop-Komponenten hinterlegt. Die sind zwar etwas nützlicher als das, was zuvor zur Verfügung stand. Trotzdem ist noch Luft nach oben. Und es gibt sogar einige ernstzunehmende Stolperfallen. Hier ein erster, kritischer Blick auf das was Sie damit tun können. Und auch darauf, was Sie besser sein lassen.

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

Rebellieren für den Wandel: die 8 Regeln des totalen Stillstandes von Prof. Dr. Peter Kruse

In einem legendärem Vortrag skizzierte Peter Kruse 8 Regeln des totalen Stillstands. Ihm zufolge wurden die Regeln entwickelt, um Managern und Führungskräften dabei zu helfen, Bereiche mit potenziellem Widerstand gegen Veränderungen zu erkennen und Menschen auf strukturierte Weise durch den Veränderungsprozess zu führen.

Und jetzt alle zusammen! Teams - OneNote - Aufgaben - To Do

Ein Meeting jagt das nächste. Sich da nicht zu verzetteln, wird  im Zeitalter virtueller Besprechungen  noch anspruchsvoller. Kein Wunder, dass  im Zusammenhang mit Microsoft 365  zwei Fragen besonders häufig auftauchen: Wie dokumentiert man Besprechungen gut? Was hilft, offene Aufgaben nachzuhalten? Eine gute Lösung: Das in MS Teams integrierte OneNote-Notizbuch als gemeinsame Plattform auch für den Aufgabenüberblick zu nutzen.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

Pragmatisch oder nur “Quick and Dirty”?

“Wir müssen aber pragmatisch vorgehen”, drängt der Kollege. Hm… Im Wörterbuch finde ich für “pragmatisch” in etwa: sachbezogenes, praktisches Handeln. Klingt gut. Leider zeigt sich in meinen Erfahrungen, dass pragmatisch für viele doch eher “quick and dirty” bedeutet. Es soll schnell fertig werden. Aber auf welche oder wessen Kosten? Wo ist die Grenze? Warum steht “praktisch” im Konflikt mit einem langfristigen “Nützlich”? Muss das sein?

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

Nie wieder Ärger mit Besprechungsserien in Outlook

Erstellen auch Sie Besprechungsserien in Outlook? Ärgern auch Sie sich manchmal darüber, wenn Sie etwas zu ändern haben? Falls nicht, versenden Sie entweder keine wiederkehrenden Outlook-Besprechungen (Serienterminen). Oder Sie ändern nie etwas daran. Dann ist dieser Artikel nichts für Sie. Lesen Sie aber bitte weiter, falls Sie sich schon immer mal gefragt haben, ob es eine Lösung gibt? 

Tooling #8: In die Zukunft blicken - die Szenarioplanung

In die Zukunft blicken geht nicht? Oh doch: Die Szenarioplanung.