digitalien.org — Stefan Knecht

Impact Mapping als Veranstaltungsformat planen und durchführen​

Open Impact Mapping Workshop​

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.

Penibel und hartnäckig sein: offene Fragen parken, dann lösen​

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: Wer will was? Und wer will was nicht?​

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?

Was ist die Produktvision. Was nicht?​

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.

Ein Framework oder Struktur wählen und die Analyse gliedern

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

Die richtigen Personen zusammenbringen und ständig neu mischen​

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.

Analysieren und Konsequenzen identifizieren, eine nach der anderen.​

Die Klarheit stiftende Arbeit in der Gruppe beginnt:

  • Es sind Stakeholder differenziert und Motive verstanden.
  • Das Scoping/Produktvision ist geschehen und es gibt keine konkurrierenden Sichten zum Projektziel.
  • Eine schematische Struktur/Gliederung ist gewählt, mit der Konsequenzen restlos betrachtet werden können.
  • Alle Teilnehmenden denken mit, bewerten und geben abweichende Sichten.
  • Ein:e Facilitator:in übernimmt die Dokumentation der Ergebnisse — Sie haben den Kopf frei für die Moderation des Prozesses.

Für jeden Aspekt wird das gewählte Schema angewendet.

Fragen, um Konsequenzen zu klären

Bei der Erforschung absehbarer Konsequenzen können diese Fragen behilflich sein:

KollisionsgefahrenGibt es grundlegende Anforderungen, die mit der Änderung kollidieren werden?

Nichts tunWas sind die Konsequenzen, wenn nichts geschieht und alles bleibt beim Alten?

beobachtbare VorteileWas sind mögliche positive Effekte der Änderung? (besserer Durchsatz, höhere Qualität, geringerer Aufwand, weniger befasste Rollen u.a.)

TouchpointsWelche Stakeholder werden wann und wodurch tangiert?

Domino-EffekteWie 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ähigkeitenHaben Mitarbeitende die notwendigen Kompetenzen um x, y, … zu tun, nachhaltig zu betreiben?

bekannte und neue BeschränkungenWelche technischen, datenschutzrechtlichen, infrastrukturelle Beschränkungen sind bekannt und welche neuen könnten auftauchen?

Cash FlowWelche finanziellen Konsequenzen hat das Vorhaben? Gibt es einen break even point, zu dem Geld verdient wird oder sich das Vorhaben amortisiert hat?

KonkurrenzWie 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.

Konsequenzen sortieren, kategorisieren und bewerten.​

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?

Debriefing und Close​

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?

One last thing: Zwei teuflische Fragen stellen​

Der Advocatus Diaboli: stellt unangenehme Fragen. Die sind notwendig.

Zwei diabolische Frage stellen Sie sich selbst und auch gleich allen Mitarbeitenden:

  1. Ist es besser, wir verschieben das Vorhaben bis mehr Klarheit ist und Hindernisse oder Risiken behoben oder eingegrenzt sind? 
  2. Ist das erkannte Risiko akzeptabel und sind alle sich bewusst, dass ein Plan keine Garantie für erfolgreiches Gelingen ist?

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.

 

Den Plan anpassen.​

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 assets fehlen und wie können Sie diese nutzbar machen?
  • Wie muss die Kommunikation angepasst werden?
  • Wen brauchen Sie als Unterstützer?
  • Welchen Plan B können Sie aufstellen, falls etwas Größeres unerwartet nicht eintritt oder schief läuft?
  • Wie kann der Projektplan angepasst werden ohne positive Konsequenzen zu verlieren?
  • Was müssen Sie sonst noch tun, um sich und die Beteiligten auf das Vorhaben vorzubereiten?

Strukturierungshilfen für Impact Maps: Frameworks, Gliederungen und Merkhilfen​

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:

  • Strategie
  • Struktur
  • Systeme
  • gemeinsame Werte
  • Skills, Fähigkeiten
  • Arbeitsstile
  • Mitarbeiter

4P:

  • Place, Ort
  • Procedure, Prozess
  • People, Mitarbeiter
  • Policies, Regeln

6M:

  • Maschinen
  • Materialien
  • Methoden
  • Mitarbeiter
  • Management
  • Milieu, Umgebungsbedingungen

4S:

  • Surroundings, Umgebung
  • Suppliers, Zulieferer
  • Systeme
  • Skills, Fähigkeiten

 

Analyse von Risiken nach …

  • Menschen, sind die Richtigen dabei?
  • Betrieb
  • Reputation
  • prozessuale Faktoren
  • Projektbedingungen
  • finanzielle Risiken
  • technische Risiken
  • natürliche Risiken
  • politische Risiken
  • strukturelle Risiken

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.