Stakeholder-Mapping ermittelt Personen oder Gruppen, die ein Projekt beeinflussen oder von ihm betroffen sind, und macht ihre Beziehungen und Beteiligungsbedürfnisse sichtbar. Eine nützliche Map hilft bei der Frage, wer gehört werden muss, wer entscheiden kann und wer beitragen muss, bevor die Arbeit weitergeht. Sie ordnet nicht, wessen Interessen am wichtigsten sind.
Die Leitlinien zur Stakeholder-Beteiligung der Association for Project Management beziehen Menschen innerhalb und außerhalb einer Organisation ein, die ein Interesse, eine Rolle oder eine Betroffenheit von Projektergebnissen haben. Der praktische Mapping-Prozess unten berücksichtigt diese Betroffenheit neben formaler Zuständigkeit.
Mit einer Entscheidung statt einer leeren Fläche beginnen
Schreiben Sie das Projektergebnis und die nächste wichtige Entscheidung oben auf die Map. „Einen neuen Dienst starten“ ist weit gefasst. „Entscheiden, wie bestehende Kunden in den neuen Abrechnungsprozess wechseln“ macht leichter erkennbar, wer beitragen muss.
Legen Sie die Grenze fest: ein ganzes Programm, eine Lieferphase oder eine konkrete Änderung. Eine Map für eine technische Migration braucht möglicherweise andere Details als eine Map für eine Änderung der Kundenrichtlinien. Versuchen Sie nicht, jedes Anliegen in einem einzigen riesigen Diagramm abzubilden.
Stellen Sie anschließend vier Fragen:
- Wer erlebt die Änderung unmittelbar?
- Wer betreibt, unterstützt oder wartet das Ergebnis?
- Wer kann eine Entscheidung genehmigen, blockieren, finanzieren oder einschränken?
- Wer verfügt über Informationen, die dem Team noch fehlen?
Beziehen Sie Menschen mit geringer formaler Macht ein. Eine Person an der Front kann eine Ausnahme kennen, von der abhängt, ob ein vorgeschlagener Prozess überhaupt nutzbar ist.
Eine Map passend zur Frage wählen
| Map-Typ | Beste Frage | Einschränkung |
|---|---|---|
| Beziehungs-Map | Wer ist von wem abhängig? | Kann visuell überladen werden |
| Einfluss-Interessen-Matrix | Wer benötigt welche Beteiligung? | Kann Menschen mit wenig Macht zu gering gewichten |
| Mit einer Journey verknüpfte Map | Wer wirkt in welcher Phase eines Erlebnisses mit? | Kann Governance außerhalb dieser Journey übersehen |
| Rollen- und Entscheidungs-Map | Wer berät, entscheidet und liefert? | Bildet nicht alle informellen Beziehungen ab |
Verwenden Sie mehrere Ansichten nur dann, wenn jede eine andere Entscheidung unterstützt. Eine kompakte Beziehungs-Map und eine kurze Beteiligungstabelle sind oft nützlicher als ein kompliziertes Bewertungsmodell.
Einen Stakeholder-Mapping-Workshop durchführen
Laden Sie Menschen aus Umsetzung und Betrieb sowie aus dem Umfeld der betroffenen Nutzer ein. Geben Sie den Teilnehmenden ein paar Minuten, mögliche Stakeholder still aufzuschreiben, bevor Namen diskutiert werden. So wird verhindert, dass die Liste der ersten Person den Rahmen für die ganze Gruppe vorgibt.
Gruppieren Sie die Vorschläge nach Rolle oder Beziehung und hinterfragen Sie die Gruppen anschließend. „Kunden“ können Administratoren, gelegentliche Nutzer und Menschen umfassen, die Unterstützung benötigen. „Betrieb“ kann Teams mit unterschiedlichen Schichten, Zuständigkeiten oder Zugriffsrechten enthalten.
Zeichnen Sie nur bedeutsame Beziehungen ein. Beschriften Sie den Pfeil mit dem, was zwischen den Beteiligten fließt: Genehmigung, Information, Geld, Service oder Abhängigkeit. Eine unbeschriftete Linie lässt die Map verbunden aussehen, erklärt aber nicht die Verbindung.
Kennzeichnen Sie zum Schluss Einträge als bestätigt oder angenommen. Benennen Sie, wer jede wichtige Annahme überprüft. Eine vom Projektteam erstellte Map sollte vorläufig bleiben, bis betroffene Menschen Gelegenheit hatten, sie zu korrigieren.
Ausgearbeitetes Beispiel: einen Prozess zur Kontoschließung ändern
Hypothetisches Beispiel: Ein Team plant, die Kontoschließung zu vereinfachen. Auf seiner ersten Liste stehen Produkt, Entwicklung, Projekt-Sponsor und Kundensupport. Diese Liste bildet die Umsetzungsorganisation ab, übersieht aber mehrere Folgen.
Ein gemeinsamer Prozessdurchlauf ergänzt Kontoadministratoren, Nutzer, die den Zugriff verlieren, das Finanzteam für offene Gebühren und die Verantwortlichen für Aufbewahrungsregeln. Außerdem zeigt sich, dass ein externer Dienst Schließungsereignisse empfängt und weiter Benachrichtigungen versenden kann, wenn das Ereignis verspätet eintrifft.
Die Map verändert eine Gestaltungsentscheidung. Statt die Schließung als einzelne Schaltfläche mit Bestätigungsbildschirm zu behandeln, muss das Team eine Folge von Pflichten und Mitteilungen verstehen. Vor der Vereinbarung des Umsetzungsumfangs plant es Gespräche mit den zuständigen Verantwortlichen.
Das Team geht nicht davon aus, dass alle Stakeholder an jedem Workshop teilnehmen müssen. Das Finanzteam bestätigt die Bedingungen für Gebühren. Der Support prüft die Erklärung für Nutzer. Die verantwortliche Person des externen Dienstes validiert den Ereignisvertrag. Jeder Beitrag ist an eine konkrete Entscheidung geknüpft.
Die Map in ein Beteiligungsprotokoll überführen
Eine Stakeholder-Map wird nützlich, wenn sie die Arbeitsweise des Teams ändert. Führen Sie ein kurzes Protokoll:
| Feld | Einzutragende Information |
|---|---|
| Stakeholder oder Rolle | Wer beteiligt werden muss |
| Betroffenes Interesse | Was sich für diese Person verbessern oder verschlechtern könnte |
| Entscheidung oder Abhängigkeit | Warum ihre Beteiligung jetzt wichtig ist |
| Beteiligungsform | Interview, Prüfung, Test, Genehmigung oder Information |
| Zuständigkeit | Wer die Beziehung pflegt |
| Zeitpunkt | Vor welcher Entscheidung oder welchem Ereignis |
| Validierung | Wann der Eintrag zuletzt geprüft wurde |
Erheben Sie keine personenbezogenen Daten, die das Projekt nicht benötigt. Sensible Einschätzungen zu Einfluss oder Konflikten gehören nicht auf ein öffentliches Kollaborations-Board. Beschreiben Sie ein betriebliches Anliegen neutral, statt eine Person als „schwierigen Stakeholder“ zu bezeichnen.
Fragen stellen, die fehlende Stakeholder sichtbar machen
Fragen Sie am Ende jedes Interviews, wer die Arbeit sonst erledigt, ihre Ergebnisse erhält oder Ausnahmen bearbeitet. Vergleichen Sie die Antworten mit der Map. Eine regelmäßig fehlende Rolle ist ein Hinweis darauf, dass die Projektgrenze zu eng sein könnte.
Fragen Sie, was außerhalb der normalen Arbeitszeit, bei einem Ausfall und dann passiert, wenn ein Kunde den vorgesehenen Kanal nicht nutzen kann. Solche Fragen decken oft Anforderungen an Support, Barrierefreiheit, Beschaffung oder Partner auf, die im Plan für den Normalfall fehlen.
Fragen Sie außerdem, wer bei widersprüchlichen Interessen entscheidet. Beratung und Entscheidungsbefugnis sind nicht dasselbe. Ein Team kann viele Stimmen anhören und trotzdem klar benennen, wer die endgültige Wahl trifft und wie abweichende Meinungen festgehalten werden.
Die Map während der Umsetzung aktuell halten
Prüfen Sie die Map, wenn sich der Umfang ändert, eine Abhängigkeit sichtbar wird, eine Schlüsselperson ausscheidet oder eine neue Gruppe betroffen ist. Eine regelmäßige Kalenderprüfung kann helfen, doch ereignisbezogene Aktualisierungen sind wichtiger als das Datum auf einem veralteten Diagramm.
Nutzen Sie eine agile Retrospektive, um zu fragen, wessen Beteiligung zu spät kam und welche Annahmen das Team zur Verfügbarkeit getroffen hat. Verbessern Sie den Beteiligungsprozess, ohne die Retrospektive zu einer Beurteilung einzelner Stakeholder zu machen.
Ein einfaches Retrospektiven-Format kann Beobachtungen zu Übergaben sammeln. Bewahren Sie das maßgebliche Stakeholder-Protokoll in der gemeinsamen Projektdokumentation auf und nutzen Sie den Verbesserungsprozess zur Nachverfolgung, um neue Beteiligungspraktiken zu überprüfen.
Häufige Fehler beim Mapping
Mit Jobtiteln beginnen und dort aufhören. Titel helfen, Zuständigkeit zu erkennen, zeigen aber nicht, wer die Änderung erlebt. Nehmen Sie betroffene Rollen und Arbeitsbedingungen auf.
Geringen Einfluss mit geringer Bedeutung gleichsetzen. Eine Gruppe kann ein Projekt kaum blockieren und dennoch erhebliche Folgen tragen. Berücksichtigen Sie die Auswirkungen ausdrücklich.
Annehmen, dass eine Vertretung für alle spricht. Halten Sie fest, welche Perspektive gehört wurde und welche ungeprüft bleibt. Eine einzelne Administration kann nicht jeden Kundenkontext bestätigen.
Eine Map ohne nächste Aktion erstellen. Jede wichtige Beziehung sollte zu einem konkreten Gespräch, einer Entscheidung oder einem Prüfschritt führen.
Häufig gestellte Fragen
Was ist der Unterschied zwischen Stakeholder-Mapping und Stakeholder-Analyse?
Mapping macht Stakeholder und Beziehungen sichtbar. Eine Analyse untersucht ihre Interessen, ihren Einfluss, ihre Betroffenheit und ihren Beteiligungsbedarf. In der Praxis wechseln Teams beim Erstellen eines Beteiligungsplans häufig zwischen beidem.
Sollten Kunden in einer Stakeholder-Map enthalten sein?
Ja, wenn Kunden oder Nutzer betroffen sind. Unterscheiden Sie relevante Gruppen, statt anzunehmen, alle Kunden hätten dieselben Aufgaben, Einschränkungen oder Auswirkungen.
Wie oft sollten wir eine Stakeholder-Map aktualisieren?
Aktualisieren Sie sie, wenn sich das Projekt oder seine Beziehungen ändern. Prüfen Sie sie vor wichtigen Entscheidungen und regelmäßig, um Veränderungen zu erkennen, die kein offensichtliches Ereignis ausgelöst haben.