Agilitätsboost in Softwareprojekten: Bessere Produkte durch inkrementelle Budgetierung
Mit dem steigenden Druck der Digitalisierung steigt auch das IT-Budget in Unternehmen seit Jahren an. Ein Trend, der ganz eigene Probleme verursacht. War die Budgetplanung von Softwareprojekten bereits zu Wasserfall-Zeiten gelinde gesagt „schwierig“, wurde der effiziente Einsatz von Entwicklungsbudgets spätestens seit der Ära der agilen Softwareentwicklung zur Königsdisziplin. Die inkrementelle Budgetierung bietet einen Lösungsansatz.
Klassische Budgetplanung vs. Softwareentwicklung
Zur operativen Budgetplanung in Wirtschaftsunternehmen gibt es verschiedene Modelle. Ob klassische Top-down-Budgetierung oder das immer beliebtere Zero-Based-Budgeting – das Prinzip dahinter ist größtenteils dasselbe: Basierend auf Absatz- beziehungsweise Umsatzschätzungen, Ressourcen- und Investitionsplänen wird der angenommene Budgetbedarf für die Folgeperiode geschätzt. Neben Marktprognosen orientiert sich die Schätzung oft an vergangenen Perioden unter Berücksichtigung zukünftiger Wachstumsziele. Während sich der Kapitalbedarf auf diesem Weg für viele Unternehmensbereiche relativ verlässlich ermitteln lässt, stellen Softwareprojekte das Verfahren vor große Herausforderungen. Durch die komplexe Natur von Software, die Geschwindigkeit technologischer Neuerungen und die Individualität jeder Neuentwicklung kommen gängige Budgetierungsverfahren einem Ratespiel nahe.
Detaillierte Aufwandsschätzung auf Kosten von Agilität
Um eine möglichst akkurate Planung abgeben zu können, beschreiten viele Produktverantwortliche einen umstrittenen Pfad: den der Aufwandsschätzung. Dazu werden alle geplanten Produktfeatures aufgelistet und der Umsetzungsaufwand auf Detailebene geschätzt. Für ein wenig zusätzlichen Freiraum wird auf die ermittelte Zahl ein Puffer geschlagen und fertig ist das Projektbudget. Aus diesem Vorgehen ergeben sich mehrere Probleme. Ein Grundprinzip agiler Entwicklung ist, dass sich das Produkt im Entwicklungsverlauf verändern und an die tatsächlichen Marktgegebenheiten anpassen muss. Eine Schätzung auf Feature-Ebene vor Projektbeginn ist mit wirklicher Agilität nicht vereinbar. Zudem wird der Begriff Schätzung ad absurdum geführt. Da vor Entwicklungsbeginn keinerlei Erkenntnisse über die tatsächliche Komplexität sowie eventuelle Blocker vorliegen, ist eine Schätzung bestenfalls gut geraten, schlimmstenfalls völlig aus der Luft gegriffen. Durch das Versehen der Werte mit Zahlen und Kosten wird eine Verbindlichkeit suggeriert, die nicht gegeben ist.
Nix verpassen: Abonniere den t3n Newsletter! 💌
Jetzt anmelden
Fast fertig!
Bitte klicke auf den Link in der Bestätigungsmail, um deine Anmeldung abzuschließen.
Fokus auf Organisationseinheit statt auf dem Produkt
Gerade in großen Unternehmen mit starrer Organisationsstruktur sind Silos ein erheblicher Faktor bei der Budgetplanung. So erhält jede Abteilung ein eigenes Budget, das für geplante Entwicklungsprojekte verbraucht werden kann. Die Verantwortung für diese Budgets hat jedoch nicht etwa der/die Verantwortliche/r für das zu entwickelnde Produkt, sondern jeweils der/die Verantwortliche/r für die entsprechende Abteilung. Statt also als interdisziplinäres Produktteam auf ein gemeinsames Ziel hinzuarbeiten, versucht jede Abteilung, ihr Budget möglichst sparsam einzusetzen. Als Resultat werden essenzielle Projektrollen doppelt oder gar nicht besetzt und Backend-Funktionalität wird ins Frontend geschoben oder umgekehrt. Eine erfolgreiche Produktentwicklung ist quasi ausgeschlossen.
Projektbrille statt Produktbrille
Das größte Problem bei der klassischen Budgetplanung in Softwareprojekten liegt im Fokus, der sich daraus ergibt. Eine Produktidee wird ausgearbeitet, ein Team zusammengestellt, Aufwände geschätzt und ein Budget festgelegt. Der/die Produktverantwortliche, in diesem Fall oft ein/e Projektleiter/in, verfolgt von da an das Ziel, das Projekt „in time and in budget“, also innerhalb des geschätzten Zeitraums und im geschätzten Budgets, abzuschließen. Während diese beiden Beschränkungen wichtige wirtschaftliche Kennzahlen sind, muss das eigentliche Ziel bei der Softwareentwicklung anders lauten. Das Projekt ist nur dann erfolgreich, wenn am Ende ein Produkt entsteht, das ein Nutzerproblem erfolgreich löst, vom Markt angenommen wird und skaliert. Selbst wenn dieses Ergebnis nicht im veranschlagten Zeitraum oder Budgetrahmen realisierbar ist, ist es dennoch einem „in time and in budget“ abgeschlossenen Projekt mit erfolglosem Endprodukt vorzuziehen. Das Festlegen eines Gesamtbudgets vor Projektbeginn führt dazu, dass die Validierung des Problem-Solution-Fit aus den Augen verloren wird. Zudem wird es nahezu unmöglich, wenig erfolgversprechende Ideen zu verwerfen.
Ein möglicher Lösungsansatz: Inkrementelle Budgetierung
Behandelt wird das Konzept der inkrementellen Investition etwa in dem Buch „The Corporate Startup“ von Tendayi Viki, Dan Toma und Esther Gons. Zwar geht es dort allgemein um Innovationsvorhaben und nicht speziell um Softwareentwicklung, die Parallelen sind jedoch umfassend. Der Gedanke dahinter ist so simpel wie schlüssig: Statt einen hohen Einmalbetrag zu Beginn eines Innovationsvorhabens auf Basis eines Businessplans mit größtenteils aus der Luft gegriffenen Zahlen zu investieren, erfolgt die Vergabe von Budgets Schritt für Schritt, basierend auf den jeweiligen Erkenntnissen der erreichten Stufe. Da die Entwicklung individueller Softwarelösungen problemlos als Innovationsprojekt durchgehen kann, erfolgt die Anwendung analog.
Budgetphase 1: Validierung des Problem-Solution-Fit
Bevor mit der eigentlichen Entwicklung begonnen wird, muss bewiesen sein, dass das angenommene Problem tatsächlich existiert, die geplante Lösung wirklich die richtige Lösung dafür ist und eine technische Umsetzung möglich ist. In dieser Phase sollte das Budget so knapp gewählt werden, dass es gerade ausreicht, um Zielgruppeninterviews zu führen und einen simplen nicht-technischen Prototyp der Idee (Mockup, Paper-Prototype etc.) zu entwickeln und zu testen.
Budgetphase 2: Entwicklung des MVP
Sobald der Problem-Solution-Fit validiert ist, wird das Minimum Viable Product entwickelt. Ziel dieser Stufe ist es, eine erste funktionale Produktversion zu releasen, mit der die wichtigsten Erfolgshypothesen direkt am Markt getestet werden können. Das dafür verfügbare Budget kann also auch hier (im sinnvollen Rahmen) bewusst knapp gehalten werden, um unnötigen Perfektionismus auszuschließen.
Budgetphase 3: Erreichen des Product-Market-Fit
Nun geht es darum, in kurzen Feedbackzyklen den MVP in ein marktreifes Produkt weiterzuentwickeln. Die richtigen Wachstumsmotoren müssen gefunden sowie Kunden gewonnen und gehalten werden. Marketing und Vertrieb spielen eine große Rolle. Wann der Product-Market-Fit tatsächlich erreicht ist und die Phase der Skalierung beginnt, hängt von den intern definierten Erfolgsfaktoren ab. Der Budgetbedarf in dieser Phase wird den Bedarf vorangegangener Phasen deutlich überschreiten.
Budgetphase 4: Skalierung
Das Produkt hat die ersten Härtetests erfolgreich bestanden, es herrscht kontinuierliche Nachfrage und das Geschäftsmodell ist validiert. Jetzt geht es an die Skalierung. Die Zahl der Nutzer soll vervielfacht werden und möglicherweise werden neue Nutzergruppen erschlossen. Das Produkt muss nun gleichzeitig den Bedürfnissen der Early Adopters sowie der Early und Late Majority genügen. Auf dieser Stufe muss umfassend investiert werden und das kann nun auch guten Gewissens geschehen. Durch das Ausräumen der größten Risikofaktoren in vorhergehenden Phasen herrscht genug Sicherheit für kostspielige Entscheidungen.
Passende Rahmenbedingungen als Voraussetzung
Die phasenweise Budgetierung ist nur möglich, wenn die entsprechenden Strukturen innerhalb der Organisation geschaffen werden. Voraussetzung für die agile Budgetvergabe ist, dass Softwarebudgets nicht mehr auf die Fachabteilungen verteilt werden. Stattdessen existiert ein Topf für das Gesamtunternehmen und die Vergabe erfolgt an das jeweilige interdisziplinäre Produktteam, unabhängig von Abteilungszugehörigkeiten. Ein speziell für diesen Zweck geschaffenes Gremium bestimmt über die Kapitalvergabe und ist Ansprechpartner für Produktteams mit Finanzierungsbedarf. Die Höhe der zu vergebenden Budgets orientiert sich an den beschriebenen Phasen und ist für alle transparent und nachvollziehbar. Wenn nötig und sinnvoll, können pro Stufe feste Budgetrahmen definiert werden. Eine inkrementelle Budgetierung, die sich an den Stadien des Produktentwicklungsprozesses orientiert, hat gleich drei Vorteile: Die Vergabe von Kapital wird vereinfacht, zeitgleich das Risiko von Fehlinvestitionen minimiert und ein transparenter, fairer Vergabeprozess innerhalb der Organisation geschaffen.
Tatjana Moser berät und unterstützt als Senior Business Designer bei intive große Unternehmen bei der Realisierung ihrer digitalen Projekte. Von Ideation über Konzeption bis zum Produktmanagement ist alles dabei.https://samplecic.ch/agilitatsboost-in-softwareprojekten-bessere-produkte-durch-inkrementelle-budgetierung.html
Комментарии
Отправить комментарий