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.



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!

Neueste Posts

360 Stories – ein Spiel für Teams Die B2B E-Commerce Pyramide
Digital Storytelling - ein Kurztrip in die Kreativität und wieder zurück
TechDivision veröffentlicht Magento 2 Schnittstelle für pixi* TechDivision wird von Focus Business als „TOP Arbeitgeber Mittelstand 2018“ ausgezeichnet

Archiv

Dezember November Oktober September August Juli Juni Mai April März Februar Januar
Dezember November Oktober September August Juni Mai April Februar Januar
Dezember November Oktober September August Juli Juni März Februar
Oktober September August Juli Juni Mai April März Januar
Dezember November Oktober September August Juli Mai April Februar
November Oktober September April Februar
Dezember September Juni Mai Februar Januar
Juli Mai April März Februar Januar
September August Juli März
Oktober September Juli Juni Mai März Februar
Februar

Kategorien

E-Commerce Unternehmensmeldung Online-Marketing Magento Commerce Neos TYPO3 SEO SEA Usability Digitale Transformation Agile Projektentwicklung Corporate Web Analytics Künstliche Intelligenz Mobile Marketing Social Media Veranstaltungen Research & Development

Unser Herz schlägt online -
Deins Auch?


Wir stellen uns jeden Tag neuen Heraus-forderungen des Online-Business – immer auf der Suche nach spannenden Lösungs-ansätzen und sinnvollen Technologien. Eine Vielzahl namhafter Kunden vertrauen auf das Online Know-how „Made in Kolbermoor / Rosenheim und München“. 

Lust auf TechDivision? Hier geht zu unseren Stellenanzeigen

eStrategy Magazin


Erfahren Sie mehr zu den Themen E-Commerce, Online-Marketing, Mobile, Projektmanagement, Webentwicklung und E-Recht in unserem kostenlosen Online-Magazin.

Jetzt herunterladen!

Whitepaper:
Agiles Projektmanagement


In unserem kostenlosen Whitepaper versuchen wir Basiswissen und Erfahrungen aus vielen Jahren täglicher Projekt- und Unternehmenspraxis zu vermitteln, mit denen Sie die Anforderungen des Arbeitslebens von Heute besser bewältigen können.

Jetzt herunterladen!

Autor

Haben wir Ihr Interesse mit unserem Blog geweckt?

Wir sind der richtige Partner für anspruchsvolle Projekte im Bereich E-Commerce, Corporate Web, Consulting und Online-Marketing. Sprechen Sie mit uns!

Autor

Josef Willkommer Geschäftsführer / CMO