Von der Lösung zum Problem – Impact Mapping mal anders herum – akquinet AG

Als Projektmanager bin ich täglich mit den Anforderungen unserer Auftraggeber konfrontiert. Diese werden interessanterweise sehr oft in Form von Lösungen formuliert. Der Bezug zum eigentlichen Problem ist nicht (mehr) transparent.

Der Auftraggeber könnte sehr davon profitieren, wenn der Dienstleister in seinem Sinne mitdenkt und damit zum Projekterfolg beiträgt. Dazu gehört auch die Beurteilung und der Vergleich von zwei Lösungen miteinander. Dies ist die Basis für eine richtige – effektive und effiziente – Wahl.

Vor Kurzem bin ich auf die Methode namens Impact Mapping gestoßen. Das Impact Mapping ist ein mächtiges Werkzeug, welches eigentlich nur eine Richtung kennt. Als ich sie verstanden hatte, versuchte ich diese einfach mal anders herum anzuwenden. Mit ungeahnten Folgen…

Impact Mapping?

Die Methode des Impact Mapping soll Projekten dabei helfen, eine reale Wirkung zu haben und nicht bloß Software abzuliefern. Das klingt verlockend logisch und motivierte mich, diese Methode auszuprobieren. Im Grunde genommen wird sie bei der strategischen Planung benutzt (1). Impact Mapping unterstützt eine klare Kommunikation von Annahmen und Geschäftszielen, um bessere Entscheidungen bei der Roadmap einer Software treffen zu können. Damit ist diese Methode besonders geeignet für Product Owner bzw. Produktmanager (2).

Eine Impact Map ist wie eine vierstufige Mindmap, die mit dem Kern eines Problems anfängt (3).

Warum machen wir das? Hier steht das Ziel. Idealerweise in direkter Relation zum Geschäftsmodell bzw. dem Geschäftsziel.
Wer wird davon betroffen sein? Die Akteure (gerne als Persona). Hier ist es hilfreich, sehr weit zu denken. Es handelt sich quasi um eine Stakeholderanalyse.
Wie sollen die Akteure beeinflusst werden? Welche Änderungen am Verhalten oder in Prozessen sind hilfreich (für das Ziel)?
Was müssen wir tun, um das “Wie” zu erreichen? Das sind die Projektgegenstände bzw. die Features.

Wer diese Methode anwenden möchte, sollte es sehr leichtgewichtig tun. Klebezettel an der Wand und kurze und prägnante Begriffe sind vollkommen ausreichend. Es macht hier keinen Sinn, eine fertige Story oder Lösung zu beschreiben. Ausgehend von einem Warum entstehen dadurch unzählig viele Was. Diese Was sind die umzusetzenden Features und bilden damit das Backlog der Produktes.

Damit die richtigen Features zuerst umgesetzt werden – es geht ja um den größten Impact – müssen die Features vor der Umsetzung natürlich nach dem vermuteten Impact priorisiert werden.

Ein kurzes Beispiel

Um das Vorgehen ansatzweise zu verdeutlichen, möchte ich das Beispiel aus dem OBJEKTspektrum (4) anführen, da mich dieser Artikel überhaupt dazu gebracht hat, die Methode anzuwenden: Ein Verlag überlegt sich, wie er mehr Gewinn erzielen könnte und geht in etwas folgendermaßen vor:

Warum: Umsatz an Büchern steigt um 10%
Wer: Einkäufer (des Kunden)
Wie: Bücher schneller bestellen
Was: Online-Shop

Es gibt also eine begründete Annahme, dass ein Online-Shop dazu beitragen kann, dass mehr Bücher gekauft werden, da es sehr viel leichter und schneller (als bei der Konkurrenz) geht. Dieses Geschäftsziel ist heute natürlich keine neue Erkenntnis, zeigt aber sehr einfach die Anwendung. So entstehen aus einem Warum am Ende viele Was.

And now something completey different

Das Vorgehen eignet sich also besonders bei der Produktfindung. Wir als Dienstleister werden oft mit einem Lastenheft konfrontiert. Ein Lastenheft ist die Verpackung der Was – meistens noch als Lösung formuliert. Der Prozess zu diesem Lastenheft weicht oft von dem beschriebenen Vorgehen ab. Damit ist dann auch ein Verlust von Transparenz des eigentlichen Problems und des eigentlichen Ziels verbunden.

Wir wollen unsere Kunden während der gesamten Projektlaufzeit ganzheitlich mit unserer Expertise in Technologie und Branchenwissen beraten. Die Voraussetzung dafür ist aber die Kenntnis und das gemeinsame Verständnis des Problems hinter einer Lösung. Nur damit kann in jeder Projektsituation die richtige Entscheidung zusammen mit dem Kunden getroffen werden.

So, jetzt bitte mal anders herum

Da ich bei meinen Kunden immer wieder auf der Suche nach dem Problem bin, habe ich versucht, das Impact Mapping mal anderes herum auszuprobieren. Ich fange also nicht bei dem Warum an sondern bei dem Was.

Das vorsichtige Hinterfragen einer Lösung (dem Was) bekommt mehr Struktur und die direkten Zusammenhänge und mögliche Annahmen werden plötzlich sichtbar. Eine Anforderung “Wir brauchen einen Report der Standzeiten der Maschinen” basiert vermutlich auf folgender Impact Map:

Was “Report Standzeiten der Maschinen”
Wie “Variabler Einsatz der Maschinen”
Wer “Produktionsleiter”
Warum “Weniger Maschinen in der Produktion einsetzen, um Kosten zu sparen”

Das Beispiel verdeutlicht sehr stark den direkten Bezug zu den Akteuren und dem Geschäftsziel. Dieses Vorgehen habe ich mit einem langjährigen Kunden ausprobiert und es fand sehr schnell seine Zustimmung. Auch er hatte mit den ungeahnten positiven Folgen nicht gerechnet:

Schnelles Entwickeln von Alternativen
Erkennen von Synergien bei der Umsetzung von Features, da diese plötzlich als zusammenhängend erkannt wurden
Bewertung und Priorisierung von Lösungen auf Basis des Geschäftsziels
Identifizierung geeigneter (manchmal vorher nicht benannter) Rollen für ein Feature

Jetzt ist dieser neue Prozess der Erfassung und Beschreibung von Anforderungen Kernbestandteil unserer Projekte mit dem Kunden.

Fazit

Die Methode des Impact Mappings ist geeignet, um ein Projekt mit der richtigen Wirkung auszustatten. Die Umkehrung der Methode vom Was zum Warum ermöglicht uns als Dienstleister die Domäne noch schneller zu verstehen und dies dem Auftraggeber auch zu visualisieren. Es entsteht ein Vertrauen in die gemeinsame Zusammenarbeit.

Wir probieren diesen Weg aktuell sehr erfolgreich mit einem Kunden aus. Jetzt sind wir dabei, den Übergang von der Impact Map zur User Story über eine weitere Ebene des Story Mappings zu erweitern (4). Ich verspreche mir davon noch mehr Möglichkeiten, zielgerichtet und ergebnisorientiert auch während der Projektlaufzeit Entscheidungen für eine Planänderung zu treffen – der wesentliche Erfolgsfaktor für unser Projektvorgehen im Agilen Festpreis (5).

Und zuguterletzt können die Projekte nun mit einer echten Roadmap mit realem Impact geplant und umgesetzt werden. Der Nutzen einer Lösung steht mit seiner Wirkung (dem Impact) wieder im Vordergrund!

Tassilo Kubitz