Stakeholder Mapping

Zweck

In der idealen Entwickler-Welt gewinnt die technisch beste Architektur (Z.B. "Der Kubernetes-Umbau"). In der realen Welt gewinnt die Architektur, die nicht von einem einflussreichen Manager (Stakeholder) beim CIO blockiert oder budgetiert wird. "Stakeholder Mapping" zwingt Technologie-Leader, die Akteure ihres Unternehmens wie Spielfiguren auf einem Macht-Radar anzuordnen. Es diagnostiziert kaltblütig, wen du aufwärmen musst, wen du ignorieren darfst, und wer das absolute Veto-Vorrecht besitzt, dein Projekt zu beenden.

Einsatzkontext

Stakeholder Mapping ist Pflichtprogramm vor jeder großen Migration (z.B. Wechsel des Cloud-Providers, Umstellung von Scrum auf Kanban, Einführung von GraphQL). Es verhindert das tödliche Szenario, in dem dein 30-köpfiges Dev-Team nach 6 Monaten Arbeit vom Security-Officer eine rote Karte bekommt, weil er in der Architektur-Runde vergessen wurde.

Schritt für Schritt

Das gängigste Modell ist die *Power/Interest Matrix (Einfluss/Interesse Matrix)*:

1.Identifizieren: Liste alle Menschen und Rollen auf, die von deiner neuen Struktur berührt werden.

2.Die X-Achse (Interesse): Wie stark wird der Arbeitsalltag dieser Person durch deine Architektur tangiert?

3.Die Y-Achse (Power/Macht): Kann diese Person in ein Meeting stürmen und den Stecker ziehen (Geld drehen, Regulatorik ausspielen)?

4.Verorten in den 4 Quadranten:

Viel Macht + Viel Interesse: Der "Key Player". Halte ihn eng, manage ihn täglich. (CTO, Lead Developer der tangierten Nachbar-Plattform).

Viel Macht + Wenig Interesse: Der "Beobachter". Halte ihn zufrieden, langweile ihn nicht mit Code-Details, zeige ihm Budgets. (Finance-Vorstand).

Wenig Macht + Viel Interesse: Der "Leidtragende". Halte ihn informiert, gib ihm das Gefühl, gehört zu werden, bewahre ihn vor Frust. (Junior-Devs, Kundensupport).

Wenig Macht + Wenig Interesse: Der "Rand". Minimaler Aufwand.

Beispiel

Das Team plant den Rollout eines neuen Identity and Access Management (IAM) Systems. Der Projektleiter ignoriert das Stakeholder Mapping und beginnt sofort mit dem Code. Nach acht Wochen knallt es: Die Legal & Compliance Abteilung (Viel Macht / Wenig operatives Interesse) stoppt das Projekt, weil das externe Auth-Tool nicht ISO-zertifiziert ist. Ein vorheriges Stakeholder Mapping hätte sie im Quadrant "Keep Satisfied" verortet, was geheißen hätte: Das erste Meeting *überhaupt* hätte mit Compliance bezüglich ISO stattfinden müssen, und nicht mit Frontend wegen JSON Web Tokens.

Diagramm

Wie aus Diagnose Handlung wird

Software-Ingenieure bewerten Macht oft falsch. Du denkst vielleicht, der Enterprise-Architect im 5. Stock hat viel "Power". Oftmals zeigt das Mapping aber, dass der Senior-Release-Engineer, der seit 15 Jahren exklusiv die SSH-Schlüssel für die Produktions-Server hütet, im tatsächlichen Tagesgeschäft eine wesentlich höhere Veto-Macht besitzt. Stakeholder Mapping zwingt dich, "Formale Autorität" und "Wirksame Autorität" realistisch auf dein Radar zu zeichnen.

Wann diese Methode die richtige ist

*Stakeholder Mapping* ist eng verwandt mit *CATWOE*, ist aber deutlich taktischer und politischer für das Projekt-Management ausgelegt, da es die rein formale Dimension von "Geld und Veto-Macht" in 4 gnadenlose Action-Felder (Quadranten) konvertiert. Weitaus feingewebterer sozialer Einfluss wird über *Social Network Analysis (SNA)* abgefedert.

Wie du die Diagnose im Alltag einsetzt

Trau dich, die Matrix in der Strategie-Runde ehrlich anzuschauen. Eine der härtesten Lektionen für Techniker ist es, zu begreifen: Die Anwender deiner Software (Die "User") stecken oftmals gefangen im Quadrant "Hohes Interesse / Geringe Macht". Sie leiden unter deiner Architektur, aber sie können dich nicht stoppen. Nutze das Stakeholder Mapping, um aktiv die ethische Entscheidung zu treffen, als Architekt die "Key Player" Mängel (Manager Wünsche) auch mal abzublocken, um die "Leidtragenden" Anwender zu schützen.

Erste Analyse-Schritte

Verbinde Stakeholder Mapping mit Architekturdokumentation (ADRs). Wenn Stakeholder aus dem "Hohe Macht" Quadranten nicht auf dem Sign-Off des Dokuments stehen, ist dein ADR das Risiko nicht wert, programmiert zu werden. Stakeholder wandern im Laufe der Zeit. Jemand, der am Anfang "Geringes Interesse" hat, wird plötzlich zum "Key Player", sobald die Migration beginnt weh zu tun. Halte das Radar aktuell.

Woran du eine brauchbare Diagnose erkennst

Wurde beim Rollout der letzten "Developer Productivity Platform" der operative Plattform-Ingenieur, der in PagerDuty um 3 Uhr nachts die Incidents fixen muss, im Stakeholder Mapping nur als "Informieren" (Niedrige Macht), oder korrekterweise als "Manage Closely" eingestuft?

Quellen

R. Edward Freeman — Strategic Management: A Stakeholder Approach (Pitman, 1984)

Mendelow — Power/Interest Grid (1991)

Wikipedia: Stakeholder Analysis