In den vielen Jahren meiner IT-Karriere musst ich leider viel zu oft Produktentwicklungen beobachten, die scheiterten. Sie scheitern nicht aus technischen Gründen, oder weil das Umsetzungsteam schlechte Arbeit leistete. Das Problem war also nicht in der technischen Hemisphäre der Projektwelt zu finden, sondern auf der anderen Seite, in der Organisation und dem Mindset der Entscheider.
Ein Analyse:
Die IT ist eine der jüngsten wissenschaftlichen Disziplinen. Sie entstand im letzten Jahrhundert, als Emporkömmling aus der Physik und Elektronik. In der klassischen Physik ist ein jedes Ereignis berechenbar und planbar. Das Projektmanagement, geisteswissenschaftlich fundiert, ist aus der BWL erwachsen und als plangetriebenes Vorgehensmodell ebenfalls kausal durchzuführen. Es gibt im klassischen Projektmanagement Projektpläne und Projektstrukturpläne, Gantdiagramme und noch viel mehr, die den genauen Aufbau und Ablauf von Projekten planen und einer Umsetzung herbei führen. Das Umsetzungsteam bekommt also vom Projektmanagement genaue Vorgaben, wann, was wie in welcher Qualität fertiggestellt werden muss. Das Umsetzungsteam und das Projekt sind also auf Output getrimmt. Die gesamte Projektplanung basiert auf Annahmen, Erfahrungen und Analysen der Entscheidungsträger.
Es kann also gesagt werden, dass mit klassischem Projektmanagement das Ziel des Projekts zu beginn definiert wird und das Umsetzungsteam dann versucht, diesen geplanten Output auch zu realisieren. Im klassischen Produktmanagement werden über die Projektziele auch noch gröbere Meilenstein gesetzt. Es werden „Roadmaps“ erstellt, die einen plan definieren WANN, WAS umgesetzt werden muss. Dabei lassen Roadmaps meist das WIE der detaillierteren Projektplanung über.
Das Problem
Das Problem am klassischen Produktmanagement und klassischen Projektmanagement liegt also in der plangetriebenen Vorgehensweise. Es werden gleich zu Beginn der Produktentwicklung Annahmen und Hypothesen zum Markt, zu Kundenbedürfnissen und zum Produkt gemacht. Ein Plan wird erstellt, der dann exekutiert wird. Das Umsetzungsteam wird auf genau das reduziert, was es machen soll, nämlich die Umsetzung. Das alles passiert unter Einhaltung der Planvorgaben, die zu Beginn der Produktentwicklung gemacht wurden. Somit entsteht bei den Stakeholdern ein falscher Eindruck. Die Stakeholder werden dazu gebracht, sich auf den Plan zu konzentrieren und dadurch entsteht in ihnen das Bedürfnis, dass sich das Team an den Umsetzungsplan hält und pünktlich Deliveries liefert.
Es steht also der Output und die Pünktlichkeit des gelieferten Outputs im Zentrum des Handelns. Das Problem dabei ist, dass Hypothesen und Annahmen ggf. nicht mit der Realität vereinbar sind und sich der Markt und Kundenbedürfnisse jederzeit ändern können. Das heißt, selbst wenn der Plan zu Beginn der Produktentwicklung gestimmt hätte, kann dieser sehr schnell obsolet werden. Die eigentlichen Risiken werden außerdem nicht zu Beginn der Produktentwicklung angegangen, sonder werden erst zum Schluss aufgedeckt.
Roadmap – Begriffsklärung
Definition Roadmap1:
| Die Roadmap2 ist ein seit Anfang der 2000er Jahre auch im deutschen Sprachraum verbreiteter Anglizismus, der in manchen Milieus – insbesondere in Wirtschaft, Politik und Medien – gerne als Synonym für eine Strategie oder einen Projektplan verwendet wird. Aus dem Englischen übersetzt bedeutet der Begriff wörtlich Straßenkarte. |
Eine Roadmap dient also zur Projektplanung und zur Erstellung einer Strategie für die Produktentwicklung. Meist werden Roadmaps als visuelles Darstellungsmittel dieser Strategie verwendet und kommunizieren langfristige Projektziele, die meist über einen längeren Zeitraum von mehr als einem Jahr gehen, in leicht verständlicher Form. Ausgehend von den einzelnen Punkten auf der Roadmap werden diese dann in kleinere, leichter zu bewältigende Schritte zerlegt und detailliertere Pläne gemacht. 3
Die Abgrenzung
Der Vorteil von Roadmaps liegt also in der Visualisierung und der vereinfachten Kommunikation von Entwicklungsschritten. So wird oft von Kunden oder Investoren ein Ausblick für die Entwicklung des Produkts verlangt4. Das Problem der Roadmap liegt aber darin, dass diese die Aufmerksamkeit der Stakeholder auf den Output fokussiert und das Umsetzungsteam als reine Umsetzer degradiert. Des Weiteren werden Produktrisiken, Marktrisiken und Entwicklungsrisiken nicht oder sehr spät adressiert.
Roadmaps – So geht’s wirklich
Da das Problem von Roadmaps, also in der plangetriebenen Output-Sicht liegt und die Vorteile in der Visualisierung und der vereinfachten Kommunikation liegen, sollten Produktmanager darauf achten, Roadmaps Outcome-Getrieben zu erstellen. Es müssen die folgenden Produkt-, Projekt- und Marktrisiken frühzeitig adressiert und minimiert werden.
- Value-Risk: Werden es die Kunden kaufen?
- Usability-Risk: Kann der Kunde das Produkt verwenden?
- Feasibility-Risk: Kann das Team das Produkt bauen?
- Viability-Risk: Kann das Team ein funktionierendes Geschäftsmodell daraus machen?
Dazu ist es notwendig, die Ziele nicht als Output zu formulieren, sondern den Outcome zu spezifizieren. Diese Ziele lassen sich am Besten mit Methoden wie Objectives and Key-Results5 formulieren. Das Team sollte dann abgeleitet von den Zielen in einem eigenen Discovery-Prozess durch Experimente und Prototypen versuchen, den Outcome herbeizuführen. Setzt sich ein gewisser Prototyp durch und wird das qualitative und quantitative Feedback vom Markt und den Usern sehr positiv zurückgemeldet dann kann der Prototyp als Ausgangsbasis für den Delivery-Prozess verwendet werden.
Im Idealfall wird der Prototyp auch gleichzeitig von Marketing und Vertriebsmaßnahmen begleitet. Dadurch lassen sich auch das Value-Risk und das Viabiltity Risk minimieren.
Zusammenfassung
Roadmaps sind im klassischen Sinn Strategiepapiere, die meist inhaltliche Ziele, Visualisieren und auf einem Zeitstrahl zuordnen. Dadurch verleiten sie zu einer plangetriebenen Entwicklung, engen die Teammitglieder ein und bringen alle Beteiligten dazu, hauptsächlich auf den Output zu achten. Der Outcome und die Risiken werden erst sehr spät oder gar nicht berücksichtigt. Dies ist sehr problematisch und führt sehr oft dazu, dass Projekte und Produktentwicklungen die falsche Richtung einschlagen oder diese auf Veränderungen im Markt nicht regieren. Um Agilität zu leben und die Vorteile von Roadmaps sicher zu stellen, sollen Roadmaps nur outcome-getriebene Ziele beschreiben und Visualisieren. In der Umsetzung dieser Roadmap wird dann die Entwicklung in zwei individuelle Prozesse aufgeteilt. Der erste Prozess (Discovery-Track) dient dazu, die richtigen Features und Produkteigenschaften durch Experimente und Prototypen zu entdecken, während der zweite Prozess (Delivery-Track) dazu dient, die erfolgreich umgesetzten Prototypen und Experimente in einem marktreifen produktiven Zustand zu bringen und in das Produkt zu integrieren. Letzten Endes muss die Roadmap auch noch die Bedürfnisse der Stakeholder befriedigen. Stakeholder wollen sich sicher sein, dass das Team an jenen Punkten arbeitet, die am vielversprechendsten sind und sie brauchen für die Budgetplanung und den Betrieb einen groben Plan, wann welches Thema angegangen wird. Dies sollte aber wie gesagt Outcome fokussiert sein.
1https://de.wikipedia.org/wiki/Roadmap
2http://www.duden.de/rechtschreibung/Roadmap
3https://de.wikipedia.org/wiki/Roadmap
4https://de.wikipedia.org/wiki/Roadmap
5https://digitalisierungscoach.com/2020/04/04/objectives-and-key-results-eine-methode-zur-umsetzung-der-digitalisierungsstrategie/
DigitalisierungsCoach 
Kommentar verfassen