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?


Anmerkungen

 

Kommentare

Beliebte Posts aus diesem Blog

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?

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.

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.

Beispiel für eine Partyplanung mit Scrum

Wer sich neu mit Scrum beschäftigt, ist vielleicht überwältigt von den ganzen Fachbegriffen. Dann sieht man vielleicht gar nicht, wie einfach die einzelnen Elemente von Scrum sind. Deshalb hier ein einfaches Beispiel für die Vorbereitung einer Party mit Hilfe von Scrum.

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.

Tooling #5: Die gute alte Systemtheorie

Gelegentlich fragen mich Menschen nach den wichtigsten Tools und Herangehensweisen für meine Arbeit. Einige davon habe ich hier im Blog bereits vorgestellt (und zwar  hier ). Heute möchte ich über ein weiteres, vielleicht sogar DAS entscheidende Basiswerkzeug sprechen: Die gute alte Systemtheorie.

Protokolle in OneNote - neue Ideen für's neue Jahr

Protokolliert Ihr Team seine Besprechungen in OneNote? Das geht einfach, schnell ist teamfähig und hat eine exzellente Suchfunktion. Die beliebte Fragen "Wann haben wir eigentlich beschlossen, dass..." ist so schnell beantwortet. Darum wird OneNote an dieser Stelle immer beliebter. In meinen Seminaren dazu sind gute Ideen entstanden, die ich hier weitergeben will.

Ich bin ganz oben (mit Kanban und Outlook)

Mit einem Kommentar zu einem lesenswerten Artikel von Thomas Mauch /1/ habe ich es an die Spitze der Trefferliste bei Google geschafft. Suchen Sie mal nach „Kanban Outlook“. Kanban ist eine alte Idee, aber immer noch der Renner unter den Produktivitätswerkzeugen. (There is an English version of this post.)

Scrum und Kennzahlen (KPIs, Metriken)

In regelmäßigen Abständen hören wir die Frage, welche Kennzahlen (neudeutsch KPIs) bei Scrum sinnvoll sind. Zeit für einen längeren Beitrag, auf wichtige Ressourcen zu verweisen. Der Scrum-Guide selbst gibt dazu keine erschöpfende Auskunft. Und das hat seine Gründe.

OneNote Prinzipien: Zugriffsrechte und Speicherorte

OneNote ist praktisch – ohne jeden Zweifel. OneNote ist auch einfach und intuitiv zu bedienen… Ja… so am Anfang. Doch früher oder später kommen Fragen wie: - wer genau hat eigentlich wie Zugriff auf die Daten? Wie ist das mit Synchronisation zwischen Büro-PC und Smartphone oder iPad? Wie funktioniert OneNote auf dem SharePoint? Auf diese Fragen findet sich die Antwort nicht ganz so leicht. Ich versuche hier die nicht ganz so offensichtlichen Zusammenhänge deutlich zu machen und "gern genommene" Fallen zeigen.