Menu
✁
digitalien.org — Stefan Knecht
Mehr dazu: Impact Mapping — outcome statt output
Auf Github ist von Gojko Adzic und anderen Trainern reichhaltig Material bereitgestellt, ein kleinteiliger Zeitplan sowohl für einen halb- wie ganztägigen Workshop, Cases, Übungen und alles, was dazu gehört. Wenn Sie vorhaben, Impact Mapping anzubieten — das ist ein lohnendes Füllhorn.
Es geht nicht darum, sofort Lösungen zu finden. Widerstehen Sie der Versuchung, in der Veranstaltung nicht beantwortbare Fragen »auf später« zu schieben. Die Gefahr ist, dass »später« nichts geschieht und dunkle Ecken bleiben.
Besser: einen Parkplatz für offene Antworten anlegen, die Fragen zur Lösung an kompetente Person geben und die Abarbeitung verfolgen. Auch dafür ist der priorisierte Backlog da: alles aufnehmen, was zu tun ist.
Stakeholder Mapping ist ein Prozessschritt um besser zu verstehen, welche Motive aus welchen Bereichen Einfluss auf das Vorhaben nehmen können — oder nehmen werden, wenn Bestandsinteressen berührt werden.
Stakeholder ist jede:r, der/die von Ihrem Projekt berührt werden wird. Wer genau ist das?
Stakeholder sind immer Personen, keine Funktionen. Abteilungen und umgebende (IT-)Systeme sollten durch benannte Personen vertreten sein.
Die Frage an jede/n einzelnen Stakeholder lautet: Wer will was warum? — Wer will was keinesfalls?
Wie tangieren die Interessen der Stakeholder einander? Gibt es Koalitionen und weshalb? Konflikte, Bruchlinien, widerstrebende Interessen?
Das Ergebnis eines Stakeholder Mapping kann eine Art Landkarte sein, ein Flowchart oder Mindmap — welche Darstellungsform leicht zu erstellen ist.
Mit diesem Schritt haben Sie so viele Personen, Bereiche, Prozesse und Ressourcen wie möglich kartiert, die von Ihrer Entscheidung betroffen sein könnten.
Diese Abbildung von einflussnehmenden oder betroffenen Personen können Sie vorbereiten. Als Auftakt und zum Warmwerden ist es eine gute Übung, mit der Gruppe gemeinsam die Zuordnungen durchzugehen. Sind die Beziehungen, Wünsche und mögliche Widerstände richtig abgebildet? Was ist zu korrigieren, was fehlt?
Scoping grenzt klar und ohne Konjunktiv (könnte, müsste, sollte) ab, was ein Vorhaben bewirken und leisten soll.
Eine klare Produktvision formuliert auch Nicht-Ziele. Die Produktvision oder Scope setzt so die Aussengrenzen sowohl für Impact-Analyse wie Impact Mapping.
Eine strukturierte Gliederung hilft, die Analyse tief und vollständig zu treiben und im Trubel nichts Wesentliches zu übersehen.
Vorlagen dazu gibt es viele und in verschiedener Komplexität. Am Ende dieses Abschnittes sind einige angeboten. Welche Struktur Sie wählen, ist nicht entscheidend. Nehmen Sie das, mit dem Sie vertraut sind oder sich schnell einarbeiten können.
Wählen Sie das Framework, das Ihnen am Besten zu passen scheint. Mischen Sie Begriffe aus verschiedenen Vorlagen, wenn es so leichter geht.
Wichtiger ist fast noch, Ideen aller Art erst einmal anzunehmen und nicht zu früh zu kritisieren. Auch, wenn es schwerfällt. Erst sammeln, dann priorisieren: divergent → konvergent
Impact Analysen als Format funktionieren gut in einer nicht zu großen Gruppe von maximal 10 Personen. Wird die Gruppe größer, dann ist es schlauer, sich in der Moderation, im Timekeeping und Capturing helfen zu lassen. Die Sozialdynamik ist anfordernd.
Es sollen entscheidungs- und handlungsfähige Vertreter aller Gewerke, Abteilungen und Stakeholder dabei sein. Je mehr Diversität, um so besser. Teilnehmer sind eher im Unternehmen wegen Ihrer Meinung und Verlässlichkeit respektierte Personen, die Entscheidungen ohne Rücksprachen nicht nur treffen können, sondern auch tatsächlich treffen.
Je höher sie in der Hierarchie eines Unternehmens Personen aktivieren können, um so nachhaltiger und wirkungsvoller werden die Ergebnisse sein.
In den divergenten Phasen des Workshops werden die Teilnehmenden in immer wieder neu zusammengestellte Teilgruppen segmentiert. So wird auch sichergestellt, das besonders meinungsstarke Menschen andere, vielleicht stillere Personen weniger dominieren. Soll ja vorkommen.
Die Klarheit stiftende Arbeit in der Gruppe beginnt:
Für jeden Aspekt wird das gewählte Schema angewendet.
Bei der Erforschung absehbarer Konsequenzen können diese Fragen behilflich sein:
Kollisionsgefahren: Gibt es grundlegende Anforderungen, die mit der Änderung kollidieren werden?
Nichts tun: Was sind die Konsequenzen, wenn nichts geschieht und alles bleibt beim Alten?
beobachtbare Vorteile: Was sind mögliche positive Effekte der Änderung? (besserer Durchsatz, höhere Qualität, geringerer Aufwand, weniger befasste Rollen u.a.)
Touchpoints: Welche Stakeholder werden wann und wodurch tangiert?
Domino-Effekte: Wie nachdrücklich ist die Auswirkung auf andere Fachbereich? Was macht das Vorhaben mit bestehenden Workflows, Abläufen oder Gewohnheiten? Gibt es Ketteneffekte?
Können und Fähigkeiten: Haben Mitarbeitende die notwendigen Kompetenzen um x, y, … zu tun, nachhaltig zu betreiben?
bekannte und neue Beschränkungen: Welche technischen, datenschutzrechtlichen, infrastrukturelle Beschränkungen sind bekannt und welche neuen könnten auftauchen?
Cash Flow: Welche finanziellen Konsequenzen hat das Vorhaben? Gibt es einen break even point, zu dem Geld verdient wird oder sich das Vorhaben amortisiert hat?
Konkurrenz: Wie könnten Konkurrenten auf das Vorhaben reagieren und welche Konsequenzen hat das, die man jetzt schon einbeziehen kann?
(…)
Das sind viele Fragen und Optionen. Vielleicht sind manche nicht relevant. Einige der Fragen werden nicht sofort im laufenden Impact Mapping Workshop zu beantworten sein.
Doch genau darum geht es in der Impact Analyse: um die Ecke denken, von der Zukunft zurück in die Gegenwart, sehen was ist, wenn das Projekt live gegangen sein wird.
Nicht die Augen verschliessen und auf Hoffnung fliegen: kein wishful thinking.
Warnhinweis: Es ist Zeitverschwendung, eine vielleicht vorhandene Wunsch-Featureliste durchzugehen. Das führt nicht zu divergierendem Denken und neuen Ideen, sondern zementiert bereits vorhandene.
Bis hierhin haben Sie mehr potenzielle Auswirkungen gesammelt als erwartet. Jetzt geht es um die Kategorisierung und Bewertung jedes einzelnen items.
Müssen alle, wirklich alle Items kategorisiert und bewertet werden? Aber ja. Sonst war der Aufwand bis hier vergebens.
Jedes item wird nun erneut angefasst und erhält 3 Fragen oder Labels:
(A) Aktion notwendig: Es ist etwas zu tun weil ohne Aktion das Vorhaben nicht gelingen kann. Was genau ist zu tun?
(B) Typ Konsequenz | Hindernis: Welcher Art ist ein item? Handelt es sich um eine nützliche und beabsichtigte Konsequenz oder ein Hindernis, das zuerst beseitigt werden muss?
(C) Risiko | Mitigation: Wurde ein Risiko entdeckt, dessen Eintritt unwahrscheinlicher gemacht werden soll oder dessen Kosten/Folgen/Schaden geringer gehalten werden müssen?
Runden Sie das Impact Mapping und einen anstrengenden Tag ab mit einem Debriefing:
Was haben wir heute gemacht, was ist erreicht?
Einmal die Runde machen — jeder soll so lange sprechen, wie ein Zündholz brennt.
Ist allen klar, welche Parkplatz-Aufgaben bis wann zu bearbeiten sind und wie dir Lieferung an die Beteiligten geschehen soll?
Zwei diabolische Frage stellen Sie sich selbst und auch gleich allen Mitarbeitenden:
Dann haben Sie es schon geschafft.
Das war ein anstrengender Tag — doch lohnend:
keine Impact Analyse zu machen ist ebenso fahrlässig wie immanente und latente Risiken zu ignorieren.
Vereinbaren Sie zum Ende einen Folgetermin in sinnvollem zeitlichem Abstand. Bitten Sie die Teilnehmenden auch bei diesem Termin dabei zu sein. Es wird um das Review gehen: wachen Auges prüfen, ob sich Randbedingungen geändert haben oder neue Informationen vorliegen.
Wenn das Projekt in deterministischer Form, nach konventionellem Projektmanagement durchgeführt wird, dann muss spätestens jetzt der Projektplan angepasst werden. Sehr wahrscheinlich gibt es nach der Veranstaltung neue Abhängigkeiten, neue Risiken und einen neuen kritischen Pfad. Wenn sich nichts verändert hat — dann war es kein Impact Mapping.
Geschieht die Umsetzung in einer agilen Form … dann auch: die Ergebnisse der Impact Analyse fliessen als items zurück ins Backlog und werden dort priorisiert und eines nach dem anderen abgearbeitet.
Diese oder ähnliche Fragen stellen sich:
Welche dieser Strukturierungshilfen Sie verwenden, ob Sie bei einer einzigen bleiben oder sich Ihre Best-Of passend remixen ist egal. Wichtig ist nur, Sie verwenden ein Schema zu Gliederung, haben es durchgängig verstanden und können es sicher anwenden.
7S:
4P:
6M:
4S:
Analyse von Risiken nach …
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/
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.