✁
digitalien.org — Stefan Knecht
Impact Mapping — outcome statt output
Impact Mapping ist eine schnelle und visuelle Methode zur integrierten strategischen Planung.
Es wird klar, welche Vorhaben und Produktfeatures die Unternehmensziele befördern und welche Projekte keinen Nutzen bringen.
Impact Mapping ist eine lange gereifte Methode
Impact Mapping variiert eine Methode, die als InUse-Effekt-Mapping von Mijo Balic und der Schwedin Ingrid Domingues als Effektkarta oder Effektstyrning weiterentwickelt wurden.
Diese nehmen Anleihen bei einem Ansatz von Robert O. Brinkerhoff, der die Wirkung von Trainings als RoI (Return on Investment) in Unternehmen verbessern wollte. Das Vorgehen zur Feature-Injection von Chris Matts steckt darin, ebenso Arbeiten von Tom Gilb zur Verbesserung von Iterationstechniken.
Das methodische Vorgehen hat Gojko Adzic in einem kleinen Buch gut lesbar und operationalisiert zusammengefasst. Einige der Zitate und Formulierungen sind aus diesem Buch adaptiert weil es knapper kaum geht.
Quellen sind am Ende zusammengefasst.
Impact Mapping ist schnell und ideologiefrei
Anders als mit formaleren Verfahren können nach kurzer Zeit (in Tagen statt Wochen) Geschäftsziele, Annahmen in der Produktentwicklung und der Projektumsetzung formuliert, messbar und damit prüfbar gemacht werden.
Das Vorgehen scheint auf den ersten Blick trivial: kann man denn anders vorgehen als genau so?
Während eines → Impact Mapping Workshop mit einer gut zusammengestellten, diversen Gruppe aus Linien- und Führungskräften entstehen erstaunliche Dynamiken und Klärungen.
Was bis dahin unausgesprochen blieb, kommt spätestens dann ans Licht. Auch die Umstände, die man bislang nicht sehen wollte. Oder sehen konnte.
Impact mapping: den effizienten Weg zum Geschäftsziel finden
Produkte, Services und Projekte stehen selten für sich selbst sondern in dynamischer Beziehung und Abhängigkeiten zum eigenen und anderen Unternehmen.
Mit Impact Mapping werden Wechselwirkungen, Konsequenzen und Risiken klar benannt und dann der effiziente, sparsamste Weg zum Erreichen von Geschäftszielen gefunden.
Geschäftsziele müssen klar und messbar sein. Wie sind sie zu erreichen?
Impact Mapping klärt und gewichtet strukturiert, welche unternehmerischen Aktionen welche Konsequenzen = Impact zur Folge haben.
Impact ist das outcome: die beobachtbare Verhaltensänderung, die zu einem gewünschten Zustand führt.
Mehr zu diversity → Für welches Problem sollte diversity die Lösung sein?
Es geht nicht nur um Software, Deliverables und Workflows: Impact Mapping betrachtet die gesamte Organisation mit ihrem Tun und Nicht-Tun und führt so eher früher als später zu Führungsmethoden und Managementstilen. Für die Umsetzung eines Impact Mapping ist es unerheblich, ob agil oder konventionell gearbeitet wird.
Das Vorgehen ist einfach und mehrschichtig und vor allem: ideologiefrei.
Es braucht keine Vorbedingungen ausser Aufmerksamkeit für einen, maximal zwei Tage, Moderationsfähigkeiten und: Nerven, dick wie Drahtseile.
Vision = Ziel → Was genau soll erreicht werden?
Zieldefinitionen und Produktvisionen formulieren, wie ein Projekt nützlich ist um Unternehmensziele zu erreichen. Sie schildern ein zu lösendes Problem, nicht die Lösung.
Mehr dazu: Vision und Zweck auseinander halten
Ziele sollen präzise und numerisch formuliert sein, das macht das Messen und Nachverfolgen einfacher.
Für kommerzielle, gewinnorientierte Unternehmen haben Ziele eine finanzielle Komponente. Also etwa »den Umsatz in Österreich um 12% erhöhen« oder »in drei Monaten 20% mehr Nutzer zu Kunden konvertieren«.
Nicht-finanzielle Ziele kann man ebenso numerisch darstellen, etwa »die Anzahl authentischer 5-Sterne Bewertungen in 12 Wochen auf 200 steigern« oder »20% mehr Likes auf Instagram als im April 2021«.
Handlungsleitende Ziele sind SMART
Gut formulierte, handlungsleitende Ziele sind SMART:
- Specific
- Measurable
- Action-oriented / achievable / attainable
- Realistic / reasonable / relevant
- Timely / time-bound
Die SMART-Merkregel scheint abgedroschen? Ist sie nicht. Es steckt alles drin, was es braucht um effizient arbeiten und planen zu können. Peter Drucker hat SMART popularisiert, Locke & Latham (2002) u.a. bestätigten die Nützlichkeit von Zielen mit evidenter Forschung.
Wendet man für jedes Geschäftsziel die SMART-Regeln an, dann ergeben sich klare, mess- und überprüfbare Ziele:
- langfristige Ziele = strategische Ziele zeigen Richtung, Vision
- mittel-/kurzfristige Ziele = taktische Wegmarken unterstützen die Richtung
Kontext schaffen: Womit werden Unternehmensziele erreicht?
Eine Impact Map bringt alle Deliverables (Teilprojekte, Zulieferungen, Aktivitäten/Handlungen) in den übergreifenden Kontext der Unternehmensziele.
So wird nachvollziehbar greifbar, welche Aktivitäten Geschäftsziele erreichen lassen und welche eingestellt oder pausiert werden können.
Der Kontext wird in in drei aufeinander folgenden Ebenen hergestellt.
Im englischen Original sind die vier Begrifflichen Ebenen im Impact Mapping Goal – Actor – Impact – Deliverables.
Ins Deutsche gehoben sind die passenden Entsprechungen Ziel – Akteure – Verhalten – Aktivität. Aktivität fällt etwas aus dem Rahmen? Ja: die Liefergegenstände (deliverables) sind nicht nur Software sondern auch Handlungen der Organisation, auch diese werden delivered, geliefert — gleichberechtigt und ebenso wichtig.
Organisationshandlungen können sein, etwas neu und anders als zuvor zu machen oder etwas zu unterlassen, nicht weiter zu tun.
Das Vorgehen in drei Ebenen ist einleuchtend strukturiert: vom Warum (Ziel) zu handelnden Personen, zu Verhaltensänderungen. Erst Ebene 3 leitet effiziente und effektive Aktivitäten ab.
Machen, was am Einfachsten das Ziel erreichen hilft — alles andere nicht machen
Zur Umsetzung ausgewählt werden nicht alle denkbaren Aktivitäten sondern nur jene Handlungen/deliverables, die das Ziel am Einfachsten erreichen lassen. Mit so wenig Aufwand wie möglich. Gemacht wird nur, was »auf das Ziel einzahlt«. Die Kunst ist also das Weglassen und die Konzentration auf den wirklichen Nutzen.
Wenn Sie Lean Management kennen gelernt haben, dann kann auffallen, dass Impact Maps alle Lean Prinzipien im Kern hat. Wert identifizieren, Verschwendung und Leerlauf vermeiden, Nachhaltigkeit anstreben.
Mehr dazu → Was Lean Thinking ausmacht
Impact Mapping als Großgruppenveranstaltung
Mehr dazu: → Impact Mapping als Workshop
Es braucht nicht viel für einen Impact Mapping Workshop. Eine weisse Wand, Haftnotizen, Stifte und ein wenig Vorbereitung. Ja, auch Geduld und Nerven aus Stahl.
Die Fragen in diesem dreistufigen Ablauf sind recht direkt, das zeigen die exemplarischen Haftnotizen:
Erst divergent, dann konvergent
Impact Maps visualisieren zugrundeliegende Annahmen und den Scope/Umfang von Projekten.
Sie werden gemeinsam von leitenden, entscheidungsfähigen und -willigen Mitarbeitern aus IT/Technik, Controlling und kaufmännischen Bereichen erstellt. In der Diskussion der Zusammenhänge geschieht organizational alignment als transparente und nachvollziehbare Ausrichtung aller Vorhaben auf die Ziele des Unternehmens.
Zwei Denkformen folgen aufeinander: zuerst divergent, dann konvergent. Im divergenten Schritt wird eingesammelt, Ideen produziert, ge-brainstormt.
Die Landkarte aller möglichen Massnahmen oder Investitionen in Verhaltensänderungen wächst, die Optionen werden ausgedehnt.
Im konvergenten Schritt wird aussortiert und priorisiert auf jene Massnahmen, deren Umsetzung am Einfachsten zum Ziel führt. Zu diesem Moment sind das Annahmen.
Ein Seiteneffekt: Wenn Unternehmensziele und/oder die Produktvision vage formuliert sind, führt die visuelle Kartierung von Wirkketten zu konkreter Formulierung.
Warum? Wer? Wie Was?
In der Diskussion mit allen Teilnehmenden entsteht ein strukturiertes Mindmap um vier Fragen zu beantworten: Warum? Wer? Wie? Was?
Was nicht sofort in der Veranstaltung beantwortet werden kann, wird über einen Parkplatz an eine Person zur Beantwortung übergeben.
Die Antworte/n erhalten (wie Stories in einem Scrum-Sprint) einen Liefertermin, zu dem sie der ganzen Gruppe vorgestellt werden.
Je weniger offene Fragen bleiben, um so besser. Wenn alle Fragen direkt mit den Teilnehmenden geklärt werden können, dann haben Sie die Richtigen ausgewählt — Glückwunsch!
4W an einem Beispiel
Erweitern wir das abstrakte Beispiel des Vorgehens mit einem (fiktiven und von Gojko Adzic lose adaptierten) Beispiel.
Es geht wieder um eine nicht weiter erläuterte Musikplattform. Eines der Geschäftsziele ist, die Reichweite über mobile Werbung erhöhen.
Zunächst wird nur der oberste Ast eines ersten Geschäftszieles betrachtet:
mit mobiler Werbung in 2 Monaten 20% mehr Reichweite erzielen.
Für das Beispiel hier ist irrelevant, ob das alles realistisch ist, es geht nur um eine Illustration des Vorgehens in drei Schritten, vom Wer zum Wie zum Was.
Akteure sind alle, die helfen können, das Ziel zu erreichen oder zu erschweren. Hier sind es Superfans mit Smartphones. Das Ziel ist, die Reichweite des Angebotes für diese Benutzergruppe zu erhöhen.
Die angestrebte Verhaltensänderung oder Konsequenz für diese Akteure ist, Anreize zu bieten um die Musikplattform häufiger zu nutzen, die retention zu erhöhen.
Ebene 3 hat zwei Deliverables: »Push-updates« und »Discounts«. Wenn die Musikplattform neue Inhalte bietet, dann »Push-updates« an die Superfans schicken, über diese Erinnerung das Verhalten »Klick« auslösen und den Superfan zurück auf die Plattform bringen. Darin steckt die Annahme, dass bei einer Rückkehr zur Plattform deren Dienste häufiger genutzt werden, das wiederum zahlt ein auf die Reichweite. Mehr wiederkehrende Nutzer erhöhen die Reichweite.
Das Deliverable »Push-updates« ist eine grosse Story, vermutlich ein Epic und wird in besser handhabbare kleinere Stories zerlegt.
»Push-updates« ist ein Deliverable aus Software — »Discounts« (verbilligte Konzertkarten, Streaming-Tickets usw.) sind hingegen keine Software sondern eine Marketingmassnahme, eine Aktivität oder Handlung, die in der Marketing-Abteilung umgesetzt wird.
Das Aufgliedern einer grossen und unhandlichen Story/Epic in mehrere und besser handhabbare kleinere Stories ist bekannt. Rechts dazu noch einmal das Kartonkärtchen, auf dem das Formulierungsschema einer Story erinnert ist.
Der Weg ist der Gleiche: Rolle – Feature – Ziel ist das Gleiche wie Wer – Wie – Was.
Das war ein beispielhaftes Mapping für ein einziges und nachprüfbar, messbar formuliertes Geschäftsziel.
Ein wenig Fantasie — es kann mehrere Geschäftsziele geben und damit wird das Mapping schon aufwändiger — doch immer nach demselben Schema.
Wäre man sehr ordentlich, dann fiele auf: das grundlegende Geschäftsziel ist nicht, die Reichweite zu erhöhen, sondern mit der Musikplattform Geld zu verdienen. Mehr Reichweite ist ein Vehikel um Geld zu verdienen. Möglicherweise eines von vielen weiteren.
Man könnte nun das Geschäftsziel, die Vision »Geld verdienen mit der Musikplattform« ebenso auffächern und ein großes Ziel in leichter erreichbare, kleinere Ziele auffächern.
In der Anwendung von Impact Mapping auf einen konkreten Fall wird das auch genau so geschehen. Für das fiktive Beispiel reicht die Andeutung.
Akteure = WER: Welche Personen haben welchen Einfluss?
Mehr dazu → Persona und Use Cases
Die meisten Methoden zum Anforderungsmanagement ignorieren negative Motive der Akteure, etwas nicht zu tun, zu unterlassen.
Diese Vorgehensmodelle unterscheiden nicht zwischen wohlmeinenden Akteuren und ablehnenden. Das Erheben und Analysieren von Requirements konzentriert sich allein auf die Eigenschaften der Software und blendet objektive wie subjektive Vorteile/Einschränkungen für Nutzer aus.
Impact Mapping macht das anders. Es wird dagegen herausgearbeitet, wer wovon profitiert und wer Nachteile haben könnte.
Die Frage nach handelnden Personen (Actors, Akteure) hat zwei Seiten:
- wer kann/soll/wird Förderliches tun,
- wer kann aktiv oder durch Nichtstun das Erreichen des Zieles verhindern?
Die Logik von Impact Maps zwingen, über all diese Entscheidungsträger, Nutzergruppen und Kundensegmente nachzudenken und klar zu unterscheiden:
- Wer kann welche gewünschte Wirkung erzeugen oder behindern?
- Wer sind Nutzer/Kunden/Verbraucher unseres Produkts?
- Wer wird noch davon betroffen sein?
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.
Spezifische Nutzer(gruppen) beschreiben
Mehr dazu → Persona und Use Cases beschreiben
Akteure beschreiben, so spezifisch sein wie es möglich ist: generische Formulierungen wie “die Nutzer” sind zu allgemein und ein Warnsignal dafür, dass die Motive von Nutzern noch nicht hinreichend durchdrungen sind. Es mag viele verschiedene Nutzertypen und Bedürfnisse geben. Welche?
Auch sind selten alle identifizierten Nutzertypen gleichermassen ausschlaggebend um das ausgewählte Geschäftsziel zu bedienen. Welche sind genau gemeint? Ja, das penible Differenzieren von Nutzertypen und Use Cases ist aufwändig … nicht zu differenzieren ist one-size-fits-all: das ist nicht realistisch.
Etwas spitzfindiger hat ‘Verhalten’ vier Ausprägungen:
- anfangen, etwas zu tun
- aufhören, etwas zu tun
- etwas anders tun
- verhindern, etwas zu tun
Impacts als riskante Konsequenzen betrachten
Im gleichen Schritt werden auch Impacts als riskante Konsequenzen qualifiziert. Was geschieht, wenn diese Risiken eintreten, was ist der maximale Schaden? Wie wahrscheinlich ist das?
Dieses Quantifizieren von Risiken ist ebenso nützlich wie das Identifizieren der wirksamsten Impacts oder Verhaltensmodifikationen.
Impacts sind nicht Produktfeatures: es geht in diesem Schritt ausdrücklich nicht darum, Produkt-/Softwarefeatures zu erfinden. Jetzt werden erwünschte und riskante Verhaltensänderungen erfasst und bewertet.
Leichter geht das, wenn statt des erwünschten Zielverhaltens die Veränderung von Verhalten formuliert wird, also der Unterschied in Zukunft zum heutigen Ist-Stand. Im Beispiel der Gaming-Plattform kann das sein »Nutzer rufen statt einmal wöchentlich, einmal täglich die Best-Of Liste auf« oder »Nutzer wird in einer Woche zwei neue Spieler statt einem werben«.
Und nochmals: neben den erwünschten Verhaltensänderungen gleichberechtigt auch die abträglichen und riskanten Verhaltensweisen betrachten, also alles, das erwünschtes Verhalten verhindern könnte. Das eine Verhalten beschleunigt zum Ziel, das andere bremst.
WAS kann getan werden um Verhalten zu ändern?
Jetzt endlich kommen wir zu dem Schritt, der unnötig verzögert schien: Features!
Doch nicht.
Es geht nicht nur um Features und Produkteigenschaften — es geht gleichberechtigt auch um Aktivitäten der Organisation und des Unternehmens. Das alles sind Deliverables, weit mehr als Software.
Die Frage ist:
- Was sollten Abteilungen, Menschen aktiv tun oder nicht mehr tun um das Ziel zu erreichen?
- Was kann und sollte das Entwicklungsteam, IT, Infrastruktur, Marketing, Controlling und Vertrieb tun, was unterlassen?
Alle diese Tätigkeiten sind ebenso deliverables/Zulieferungen/Mitarbeit oder Teilprojekte wie es (Software-)Features sind.
Weil alle Annahmen bereits im ersten und zweiten Schritt restlos geklärt sind, kommen in Deliverables keine Annahmen mehr vor. WAS man tun kann sind bereits die positiv aussortierten Optionen, die Impact/Verhaltensänderung verursachen.
Diese Sicht ist schockierend neu im Vergleich zu konventionellem Scoping. Im konventionellen Erheben von Anforderungen bleiben Effekte aus Impact/Konsequenzen unbeachtet. Tatsächlich ist die Vernetzung in und mit dem Unternehmen (und dem Markt!) ebenso entscheidend für das Erreichen von Unternehmenszielen wie es das richtig gewählte Featureset ist.
Gewöhnungsbedürftig? Es geht noch weiter:
Prüfung auf Konsistenz
Das Testen erhält eine weitere Dimension. Nicht nur wird Software in ihren Inkrementen/Teillieferungen auf die fehlerlose Integration mit allen aktivierten Softwarebestandteilen getestet — auch alle Aktivitäten der Organisation werden immer wieder geprüft. Diese Prüfung geschieht auf innere Konsistenz (ist die Handlung in sich schlüssig?) und äussere Konsistenz (erreicht die Handlung das Ziel, das zu erreichen sie vorgibt?).
Wenn ein deliverable/Liefergegenstand einen impact nicht so unterstützt und vorantreibt, wie gedacht (selbst wenn technisch alles korrekt geschieht), dann wird ein Fehler beobachtet.
Ein Fehler ist ein Problem und muss gelöst werden.
Liefert das Management?
Damit hat Impact Mapping eine überraschende Führungskomponente:
es geht nicht mehr nur um technische Exzellenz (die Dinge so gut tun und umsetzen, wie sie spezifiziert sind) sondern ebenso wesentlich um Management Delivery.
Liefert ‘das Management’, was es zusagt?
Das hat Zündstoff.
»Wessen Verhalten wird wie wodurch geändert?«
Wenn das so schnell nicht geht oder zu Widerständen führt: ein kleiner Umweg hilft.
Gehen Sie unaufgeregt die vorliegenden Dokumenten und Anforderungsanalysen vorgeschlagenen Produktfeatures durch. Fragen Sie sich und alle anderen Teilnehmenden »Wessen Verhalten wird in welcher Weise durch dieses Deliverable/Feature/Aktivität geändert?«.
Ja, diese immer gleiche Frage ständig erneut zu stellen, kann nervtötend sein. Es nutzt aber nichts, die Alternative ist: nicht fragen, weiter im Dunklen tappen und Aufwand, Zeit, Herzblut in etwas zu investieren, das keinen Unterschied macht.
Glauben statt Wissen wollen Sie noch viel weniger?
Jedes Ziel hat eine Benchmark-Tabelle mit Metriken und Messinstrumenten — jede:r weiss Bescheid, wie der Impact beobachtet und gewertet wird.
Erinnerung: Impact = beobachtbare Verhaltensänderung = Konsequenz
Meilensteine planen
Nächster Schritt: Meilensteine planen.
Mehr dazu → Realistische Roadmaps planen
Zuvor noch mit wachem Auge (nach einer Pause und guter Durchlüftung von Leib und Hirn) alle Ziele erneut kritisch betrachten. Sind die Ziele noch die richtigen? Ja? Gut.
Welche Ziele können in welchem der aufeinanderfolgenden Meilensteine erreicht werden?
Wenn Uneinigkeit in der Gruppe besteht: Was steht ganz oben auf der Featureliste?
Im bekannten Beispiel ist der Meilenstein die Kette der Deliverables, die zum Geschäftsziel “+20% Reichweite” führt. Das wäre das erste Release, an dem prüfbar ist, ob die Massnahmen/Deliverables funktionieren.
Meilensteine und Ziele auswählen
Alternativ geht die Auswahl der Ziele je Meilenstein auch gut mit einem Dot-Voting. Jede:r Teilnehmende erhält eine Anzahl Klebepunkte und kann sie auf die Ziele Verteilen, Häufelungen sind erlaubt. Wer variieren möchte, nimmt Spielgeld aus dem Monopoly-Kasten, jede:r den gleichen Betrag.
Damit eine Entscheidungssituation entsteht: jede:r erhält weniger Klebepunkte oder Spielgeld als es Ziele gibt.
Stakeholder priorisieren impacts
Gibt es in der Impact Map eine low-hanging-fruit mit mächtigem Impact? Also ein leicht zu testendes und gewünschtes Verhalten, das man zuerst validieren könnte? Die Sponsoren/Stakeholder sollten immer zuerst die Impacts priorisieren, nicht die Deliverables. Es geht (immernoch!) um das Erreichen von Geschäftszielen, nicht um das Abarbeiten einer Feature-Wäscheliste auf Basis unbelegter Annahmen.
Bei dieser Differenzierung kann helfen, zuerst einen Akteur zu identifizieren, dessen Use Case/s oder Bedürfnisse zuerst und vor allen anderen bedient werden soll.
Wenn all das die Lage nicht einfacher macht: das → Kano-Modell bietet ein Verfahren um die Qualität von Bedürfnissen unterscheidbar zu machen und damit zu priorisieren.
Zuvor kann die Gruppe noch den Hinweis erhalten:
Fünf aufeinanderfolgende Meilensteine, bei denen jeder ein verschiedenes Geschäftsziel erfüllt sind besser sind als ein einziger Meilenstein, der fünf Ziele nur halb bedient.
Eine gut gelungene Impact Map ist bereits die Release- oder Meilensteinplanung.
Tom Gilb rät, Releases ungefähr so zu dimensionieren, dass sie 2% der Gesamtinvestition umfassen. Das scheint nicht viel, ist aber iterativ im Wortsinn: viele kleine Schritte sind treffsicherer als ein durch unvalidierte Annahmen getriebener big bang, der auch grob daneben gehen kann.
Metriken, Skalen und Benchmarks
mehr dazu → Richtig messen: gute Metriken finden
Im geschäftlichen Umfeld sind Benchmarks häufig, Vergleichswerte aus der Vergangenheit oder zur Konkurrenz.
Für Investitionen ist der break even eine sinnvolle Zahl. Also der Moment, in dem eine Investition sich einstellt und darüber hinaus positive Erlöse schafft. Ist der break even erreicht, dann sind die Investitionen bis zu diesem Moment aufgeholt und wenigstens kein Geld verloren. Break-even heisst also auch: mindestens das muss herauskommen, der minimal erwartete Impact.
Investitionen haben meist auch Budgets und damit Begrenzungen (constraints). Wenn etwas — aus welchem Grund auch immer — nicht mehr kosten darf als x, dann kann das aufwändige Lösungswege versperren.
Wie kann eine Benchmarktabelle aussehen?
Aus dem fiktiven Beispiel, von Goiko Adzic adaptiert:
| Anzahl Nutzer in 6 Monaten | Betriebskosten | wiederkehrende Nutzer | |
| Skala | # aktive Nutzer pro Monat | Hostingkosten + OPS Gehälter | % wiederkehrende Nutzer eine Woche nach Erstanmeldung |
| Messinstrument | Nutzer-dB | Lohnbuchhaltung | Nutzer-dB |
| Benchmark | 150.000 | 18.000€ | 25% |
| Break-Even | 220.000 | 25% | 25% |
| Ziel | 450.000 | 15.000€ | 70% |
In diesem (fiktiven!) Beispiel wären die 150k neuen Nutzer in 6 Monaten der Vergleichswert etwa einer konkurrierenden Musikplattform. Mindestens so viel “wie die” wollen wir auch erreichen. Der Break-Even ist der ökonomische Wert, ab dem die Plattform Geld verdient und Investitionen sich amortisiert haben. Da wird es positiv, von den roten in die schwarzen Zahlen.
Der Zielwert ist, was man sich ausgedacht hat in feuchten Träumen oder das vermutete Potenzial der Geschäftsidee. Bei den Betriebskosten steckt in der korrespondierenden Zelle vielleicht auch ein wenig wishful thinking mit drin: die Annahme, dass bei der Skalierung der Plattform die Betriebskosten mit mehr als doppelt so vielen Benutzern geringer würde.
Sie wissen ja wie das ist mit Businessplänen.
Stille Annahmen? Zahlen sind besser.
mehr dazu → Richtig messen: gute Metriken finden
Die zuvor stillen und vielleicht vagen Annahmen werden für jedes angestrebte impact in Zahlen ausgedrückt bevor implementiert wird.
So wird Fortschritt messbar und alles, das keinen Impact produziert kann eingestellt pausiert oder verschoben werden.
Das ist eine ganz andere, erheblich schlankere Form: statt Aufwand und die Anzahl abgearbeiteter Aufgaben zu verfolgen, sehen Stakeholder sinnvolle Fortschrittsberichte. Das Reporting bedient, was eigentlich erwünscht ist: das Erreichen des definierten Geschäftszieles in der schrittweisen Validierung der zugrundeliegenden Annahmen.
Der Glauben an die Wirksamkeit einer Massnahme wird ersetzt durch das Wissen und Messen. Weniger Business-Vodoo, mehr Rationalität.
Annahmen sind so lange nicht validiert, bis sie durch Beobachtungen, Zahlen oder Messungen gesichert sind. Das gilt auch für alle Annahmen auf einer Impact Map. Deliverables, die sich nicht validieren lassen (die nicht die erwarteten Ergebnisse bringen) gründen auf falschen Annahmen. Diese bewiesenermassen falschen Voraussetzungen entfallen auf dem Impact Map.
Validierte, durch Daten/Beobachtungen/Messungen bewiesene Annahmen sind ein Indiz, auf diesem Ast der Impact Map weiter zu gehen.
Risiken, Impacts und Investitionen
Gute, reale Ziele sollten sich irgendwie quantifizieren lassen. Am Besten in Geld. Dann wird es leichter den RoI (Return on Investment) zu bestimmen. Wenn es keinen RoI gibt? Dann scheint das Vorhaben kein sinnvolles ökonomisches Ziel zu sein.
Wenn die zuvor getroffenen Annahmen eintreten, dann kann inkrementell, in kleinen Schritten weiterinvestiert werden bis das Ziel erreicht ist. Dann kann die Investition in neue Features beendet werden. Möglicherweise, bevor ein Budget oder die Projektlaufzeit ausgeschöpft sind.
Dieses Schaubild hilft vielleicht bei der Entscheidung. Die Y-Achse zeigt die Fähigkeit zu investieren, Fähigkeit verstanden als vorhandenes Budget, kurze Entscheidungswege, abrufbare Mittel u.a.; die x-Achse spannt das Risiko auf bzw. die Konsequenzen einer Entscheidung für oder gegen eine Investition.
Im rechten unteren Quadranten sind die Mittel begrenzt(er) und das Risiko eine Investitionsentscheidung ohne wahrnehmbaren Impact zu treffen noch immer hoch. Was dann? In einer solchen Situation hilft fast nur das kleinschrittige Schärfen vorhandener Features/Organisationshandlungen.
Wirken diese Massnahmen?
Wenn nicht, dann hilft nur “zurück auf Los” und die Phase des Product Discovery erneut zu starten. Vielleicht waren die Annahmen nicht robust oder die Datengrundlagen nicht ausgereift.
Mehr dazu: Inkrementell? Iterativ?
Alles unklar? Gute Experimente machen.
Experimentiert wird, wenn der Ausgang eines Deliverables oder die zugrunde liegenden Annahmen nicht im Vorhinein klar sind. Der Ausgang ist ergebnisoffen und beginnen mit einer Hypothese — sonst bräuchte es keine Experimente sondern nur Entscheidungen.
Experimente sind also Investitionen in Lernen. Lernen hilft Unsicherheit zu reduzieren und mehr Klarheit zu schaffen.
Mit Software hat das nicht unbedingt zu tun. Auch Unternehmenshandlungen wie Marketingkampagnen oder die Veränderung von internen Workflows können experimentell geprüft werden.
Gute Experimente haben diese drei Eigenschaften:
- Variation: neue Ideen prüfen (nicht alte Fehler wiederholen)
- Überlebbarkeit: Experimente sollen auf einer Skala geschehen, die im Fehlerfall nicht gleich das ganze Vorhaben gefährdet: Treffer unterhalb der Wasserlinie sind keine gute Idee
- Selektion: Rückmeldung zu erhalten ist das Ziel des Experimentierens — aus dem Scheitern und Fehlern kann so viel gelernt werden wie aus gelungenen Experimenten
Definieren Sie das Lernbudget als maximale Zeit und Kosten, die ein Experiment dauern oder kosten darf bis greifbare Ergebnisse entstehen.
Wie sieht eine nutzbare Impact Map aus?
Ingrid Domingues stellt ein schönes Beispiel bereit:
Das Format ist ein wenig verschieden von der hier verwendeten Bildsprache, die Logik die Gleiche.
Quellen
Adzic, G. (2014). Impact Mapping; Making a big impact with software products and projects (leanpub).
Adzic, G., & Evans, D. (2014). Fifty quick ideas to improve your user stories. Neuri Consulting LLP.
Brinkerhoff, R. O., & Apking, A. M. (2001). High-impact learning: Strategies for leveraging, business results from training. Perseus Pub.
Brinkerhoff, R. O., & Gill, S. J. (1994). The learning alliance: Systems thinking in human resource development (1st ed). Jossey-Bass.
Bruner, J. (1991). The Narrative Construction of Reality. Critical Inquiry, 18(1), 1–21. https://doi.org/10.1086/448619
Domingues, I., Berndtsson, J., & Adzic, G. (8.11.14). Getting the most out of impact mapping. InfoQ.
Domingues, I. (19.9.2019). Finally ditch the Persona! InUse. Abgerufen 9. März 2021, von https://www.inuse.se/read/finally-ditch-persona/
Domingues, I. (25.2.2017). Impact map template – now in Mind Manager format! InUse. https://www.inuse.se/read/impact-map-template-now-mind-manager-format/
Gilb, T., & Brodie, L. (2006). Competitive engineering: A handbook for systems engineering, requirements engineering, and software engineering using Planguage (reprinted). Elsevier Butterworth Heinemann.
Goodhart, C. (1975). Problems of Monetary Management: The U.K. Experience. In: Reserve Bank of Australia (Hrsg.): Papers in Monetary Economics. Band 1, 1975
Hubbard, D. W. (2010). How to measure anything: Finding the value of „intangibles“ in business (2nd ed). Wiley.
https://github.com/impactmapping/open-impact-mapping-workshop — weitere Materialien zu Impact Mapping, Open Source
https://www.impactmapping.org — ein feines, von Gojko Adzic betriebenes Website mit vielen weiteren Materialien
Locke, E. A., & Latham, G. P. (2002). Building a practically useful theory of goal setting and task motivation: A 35-year odyssey. American Psychologist, 57(9), 705–717. https://doi.org/10.1037/0003-066X.57.9.705
Matts, C., & Adzic, G. (14.12.2011). Feature Injection: Three steps to success. InfoQ. Abgerufen 11. März 2021, von https://www.infoq.com/articles/feature-injection-success/
Ottersten, I., & Balic, M. (2007). Effect managing IT (Ed. 1.1). Liber ; Distribution, North America, International Specialized Book Services.
Patton, J. (2014). User story mapping: Discover the whole story, build the right product (First edition). O’Reilly.
Ries, E. (2011). The lean startup: How today’s entrepreneurs use continuous innovation to create radically successful businesses (1st ed). Crown Business.
Robinson, F. (2001). Minimum Viable Product. https://www.syncdev.com/minimum-viable-product/
Robinson, F. (3.10.2008). SyncDev: How It Works: Minimum Viable Product. Link zu archive.org
Senge, P. M. (1995). The fifth discipline: The art and practice of the learning organisation. Random House Australia Pty Ltd.
Shore, J. (20.3.05). Beyond Story Cards: Agile Requirements Collaboration. Link
Toeniges, L. (2016). WHITE PAPER Impact Mapping. https://www.innovativelg.com/user_area/content_media/raw/Impact_Mapping_WhitePaper_Final.pdf
Abbildungen
Die Grafik zu Impact Mapping als Mechanik ist mit Genehmigung adaptiert von Gojko Adzics Website impactmapping.org
Alle anderen Abbildungen sind erstellt von Stefan Knecht.