TechDivision Bubble Budgeting

Eigentlich vermeiden wir Anglizismen und das inzwischen bestens bekannte Bullshit-Bingo soweit wie möglich. In diesem Fall ist uns jedoch kein anderer Begriff eingefallen, der kurz und knackig beschreibt, um was es geht und den man sich auch noch leicht merken kann.

Das Konzept bzw. die Idee des von uns als Bubble Budgeting bezeichneten Ansatzes ist recht simpel und leicht verständlich. Dennoch sollte das Ganze von allen Beteiligten „ernst“ genommen werden – was mitunter nicht immer selbstverständlich ist.

In den meisten Fällen, möchte ein Unternehmen möglichst frühzeitig über etwaige Kosten eines Projektes informiert werden, um diese in die Budgetplanung einfließen zu lassen. Sehr häufig ist es aber so, dass dieser Wunsch – was ja auch durchaus nachvollziehbar ist – sehr früh im Prozess, in den meisten Fällen vor einer etwaigen Beauftragung, geäußert wird. D.h. der Dienstleister muss in einem ganz frühen Stadium Kosten für ein Projekt benennen, bei dem es noch jede Menge Unklarheiten gibt und das sich erfahrungsgemäß auch während der Implementierungszeit noch signifikant ändern kann – in nicht wenigen Fällen auch entsprechend ändern wird, sei es aufgrund von internen neuen Anforderungen oder Erkenntnissen oder weil sich am Markt Änderungen ergeben, auf die man reagieren muss.

Jetzt kommt vermutlich sehr schnell das Argument, dass es ja genaue Spezifikationen in Form eines Lasten- oder Pflichtenheftes, einer Anforderungsskizze oder ähnlichem gibt und man als Dienstleister auf dieser Basis und mit entsprechender Erfahrung doch valide Schätzungen abgeben können müssen. Dem muss ganz klar widersprochen werden. Neben den bereits genannten Gründen sollten hier insbesondere die folgenden Punkte berücksichtigt werden:

 

  • Kein IT-Projekt ist gleich, weil auch kein Kunde gleich ist
  • Gerade IT unterliegt einer enormen Dynamik, wodurch Ansätze und Technologien von heute morgen bereits veraltet bzw. überholt sein können
  • Projekte werden von Menschen gemanagt und wo Menschen sind, „menschelt“ es, im positiven aber auch im negativen Sinne
  • Im Projektverlauf ergeben sich häufig Erkenntnisse, die von „außen“ nicht erkennbar waren und auf die reagiert werden muss

 

Wie löst man also dieses Problem eines fixen Budgets, ohne am Ende eines Projektes einen „echten Verlierer“ zu haben? Die Lösung ist eigentlich recht simpel und die Heran-gehensweise lässt sich durchaus mit anderen Bereichen, die jeder von uns auch kennt, vergleichen.

 

Bubble Budgeting in der Praxis

Zu Beginn eines Projektes wird ein Gesamtbudget definiert. Im besten Fall nennt der Auftraggeber das Budget, das er für eine Phase 1 ausgeben möchte. Alternativ dazu kann anhand grober Anforderungen auch eine erste ganz grobe Schätzung vorgenommen werden. Hier besteht der Vorteil darin, dass nicht unnötig viel Zeit in etwaige „Rocket-Science-Schätzungen“ verbraten wird, bei denen man sowieso schon weiß, dass das Endprodukt mit extrem hoher Wahrscheinlichkeit aus den bereits genannten Gründen anders aussehen wird.

Bubble Budgeting bedeutet im wesentlichen: Eine intensive Zusammenarbeit und Kommunikation mit dem Kunden sowie größtmögliche Transparenz geht vor spitzfindigen Verträgen (siehe agiles Manifest). Die Ansage lautet ganz einfach: „Wir haben in Deinem Projekt anhand der Erkenntnisse aus einem gemeinsamen Kick-Off-Workshop z.B. 6 Epics oder – um es einfacher auszudrücken – auch Bubbles identifiziert.“ Bubbles klingen anfassbar, sind plastisch.

Diese 6 Bubbles können wir beispielsweise für € 100k in 3 Monaten umsetzen. Wir wissen nicht, wie groß genau die einzelne Bubble ist, darum bepreisen wir sie auch nicht einzeln, sondern geben nur eine grobe Schätzung für alle 6 Bubbles zusammen. Wir wissen vom Gefühl her, dass Bubble 4 wahrscheinlich deutlich größer als Bubble 2 ist. Aber das wollen wir gar nicht diskutieren, sonst geraten wir in Diskussionen („Ist X jetzt 2 oder 3 Mal größer als Y? Und womöglich stellt sich hinterher auch heraus, das Y größer war als X…), die wir nicht wollen und die niemandem nutzen.

TechDivision-Bubble-Budgeting

 

Stellen Sie sich nun die 100k als eine Gefäß vor, in dem sich die 6 Bubbles befinden. Eine detaillierte Beschreibung der Bubbles erfolgt nicht. Die Bubbles heißen z.B. „Suche“ oder „Newsletter-Marketing“. Im Kickoff-Workshop und der Vor- und Nachbereitung werden diese Bubbles, sprich Epics, mit möglichst vielen sog. User Stories gefüllt mit Funktionalitäten, bei denen schon jetzt sicher ist, dass sie zu einem „Minimal-Produkt“ für einen GoLive gehören. Man spricht hier auch von einem sog. Minimal Viable Product. Ziehen wir eines davon größer als 1/6 (viele Änderungsrunden, erwiterter Scope, Gold Plating etc.), müssen wir im Blick behalten, dass andere dafür kleiner werden (müssen), weil sie sonst nicht mehr alle in das abgebildete Gefäß passen. Ganz einfach!

Letztlich nichts anderes als Dimensional Planning, aber ausgehend vom Budget und einer auf Erfahrung basierenden „gefühlsmäßigen“ Gesamtschätzung. Und wir können aus eigenen Projekten bestätigen, dass diese „gefühlsmäßigen“ Gesamtschätzungen erfahrener Entwickler und POs/PMs fast immer valider waren als die pseudogenaue Hochrechnung von Einzelschätzungen. Die Validität kann sich durch die Flexibilität der Bubbles natürlich automatisch einstellen.

Damit der Kunde mit dem Argument „Risiko“ nicht landen kann, gibt es laufend Reviews und Kostenaufstellungen bezogen auf den gelieferten Value (also Scrum-like vorgehen). Natürlich haben die Kunden Angst davor, dass die Summe der Stunden zu hoch ist. Durch größtmögliche Transparenz und die Möglichkeit einer nahezu jederzeitigen Beendigung der Zusammenarbeit sowie die Tatsache, dass wir als Dienstleister in Vorleistung gehen – d.h. es gibt keine An- oder Vorauszahlung – ist das Risiko auf Kundenseite minimal und wir als Dienstleister sind gefordert, während des gesamten Projektes effizient zu arbeiten.

Änderungen während des Projektes? Kein Problem! Wir haben eine Box von 100k, wir haben 6 Bubbles zieh eines größer = mach andere kleiner oder schmeiß sie raus usw. Das klassische „Change for free“ aus Scrum, wie oben erwähnt. Hier also nichts Neues.

Wichtig ist das konsequente „Fahren auf Sichtweite“ für die Detailplanung und eine grob granulare Planung für die weiter entfernte Zukunft, z.B. sogenanntes Rolling Wave Planning: Welche und wie viele Aufgaben aus den einzelnen Bubbles pro Meilenstein entstehen, legt man erst dann genau fest, wenn die entsprechenden Meilensteine anstehen.

„Mit dem Bubble Budgeting haben wir einer eigentlich selbstverständlichen „Sichtweise“ einen Namen und ein Gesicht gegeben und siehe da – Leute verstehen es plötzlich besser und sind dafür offen.“

Sacha Storz, Agile Evangelist, TechDivision

Und wie überzeuge ich nach dem Projektstart nun den Kunden weiterhin und immer wieder, dass das Konzept funktioniert? Indem ich permanent liefere. Durchstiche statt Komponenten oder Layer. Liefern, schnell, mit reduziertem Scope, um Feedback zu bekommen, dann iterieren und/oder nächstes Inkrement. Auch hier nichts Neues. Aber mit dem Zwang: Ich muss es so machen, sonst springt mir der Kunde ab.

 

Wozu brauche ich Agile?

Agile ist ein Muss, denn ich kann nur schnell liefern und damit fortwährend überzeugen, indem ich inkrementell liefere und iteriere („Die Funktionalität doch etwas aufgebohrt? Kein Problem!“). Aus Bubble Budgeting folgt zwangsweise Agile. Und ich kann nur schnell liefern und Änderungen akzeptieren, wenn ich agile Entwicklungspraktiken verwende (CI, automatisches Testen etc.). Ein „Jetzt nichts mehr anfassen, bitte“ gibt es nicht!

 

Wozu brauche ich Lean?

Man kann evtl. formulieren, dass Agile ohne Lean ohnehin keine gute Idee ist, aber wir wollen es konkreter machen: Die Konzentration auf das Budget macht allen Beteiligten mit dem „Dampfhammer“ klar: Waste = Geldvernichtung. Das ist zwar eigentlich immer klar, aber wir haben schon oft erlebt, dass weder PO noch SM das im Scrum-Team so verankern, dass maximale Wertschöpfung bei Maximierung von „work not done“ die Prio Nr. 1 sind.

Und natürlich brauche ich Lean ohnehin, um allen unnötigen Aufwand den ich habe, immer wieder zu prüfen und wenn möglich als Waste zu eliminieren.

Darüber hinaus brauche ich Respekt für die Mitarbeiter, denn erst ein optimales Team mit einem optimal unterrichteten/aufgeklärten Kunden kann die hochanspruchsvolle Aufgabe „erfolgreiches Projekt“ meistern. Und damit sind wir bei dem bekannten Ausspruch: „Individuals and interactions over processes and tools.“ (siehe agiles Manifest)

 

Was ist daran neu?

Eigentlich nichts! Die Systematik ist jedem klar und auch nicht hoch wissenschaftlich. Das interessante daran ist allerdings, dass es nach unseren Erfahrungen sehr häufig erst durch eine solch bildhafte Darstellung sowie die Umkehrung von „Wie viel kostet X?“ in „Was ist Dir Y wert?“ möglich wird, Verständnis für moderne Arbeits- und Projektmanagementmethoden zu schaffen. Probieren Sie es einfach aus! Es funktioniert – und zwar in allen Bereichen!

 

 

Kommentar abgeben

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.