Was ist Stakeholdermanagement?
Stakeholdermanagement ist die geplante und laufende Zusammenarbeit mit allen Personen, Gruppen und Organisationen, die auf ein Projekt Einfluss nehmen können, von seinen Ergebnissen betroffen sind oder sich betroffen fühlen. Die Norm ISO 21502 behandelt die Einbindung von Stakeholdern als eigene Managementpraxis und betont, dass auch die wahrgenommene Betroffenheit zählt [1]. Das ist praktisch bedeutsam: Wer sich übergangen fühlt, verhält sich wie ein Betroffener, auch wenn er formal keine Rolle im Projekt hat.
Der Begriff geht auf die Managementforschung der 1980er-Jahre zurück. R. Edward Freeman beschrieb Unternehmen als Geflecht von Anspruchsgruppen, deren Interessen eine Führung ausbalancieren muss, statt nur Eigentümerinteressen zu bedienen [3]. Das Projektmanagement hat diesen Gedanken übernommen: Ein Projekt ist erfolgreich, wenn es den vereinbarten Nutzen für seine Stakeholder stiftet, nicht schon dann, wenn Termin und Budget eingehalten sind.
Der PMBOK Guide in der siebten Ausgabe führt Stakeholder als eigenen Leistungsbereich und beschreibt das Ziel als produktive Zusammenarbeit über das gesamte Projekt, nicht als einmalige Analyse zu Beginn [2]. Genau hier liegt der häufigste Fehler in der Praxis: Die Stakeholderanalyse wird im Kick-off erstellt, abgelegt und nie wieder angeschaut.
- Stakeholder
- Person, Gruppe oder Organisation, die eine Entscheidung oder Tätigkeit im Projekt beeinflussen kann, von ihr betroffen ist oder sich betroffen fühlt.
- Stakeholdermanagement
- Laufender Prozess, Stakeholder zu identifizieren, ihre Erwartungen und ihren Einfluss zu verstehen und sie gezielt einzubinden, damit das Projekt seinen Nutzen erreicht.
Wie läuft Stakeholdermanagement ab?
Stakeholdermanagement folgt einem Kreislauf aus vier Schritten, der im Projektverlauf mehrfach durchlaufen wird. Die Reihenfolge entspricht der Logik im PMBOK Guide und in ISO 21502, die Benennung ist für den Projektalltag vereinfacht [2] [1].
| Schritt | Leitfrage | Ergebnis | Zeitpunkt |
|---|---|---|---|
| Identifizieren | Wer ist betroffen, wer entscheidet, wer kann blockieren? | Stakeholderliste mit Rollen und Ansprechpersonen | Initialisierung, danach bei jeder Phase |
| Analysieren | Wie gross sind Einfluss und Interesse, wie ist die Haltung heute? | Stakeholder-Matrix, Engagement-Bewertung | nach dem Identifizieren, bei Veränderungen |
| Strategie festlegen | Wie binden wir wen ein, mit welchem Ziel? | Strategie pro Gruppe, Kommunikationsplan, RACI | vor dem Kick-off |
| Einbinden und überprüfen | Wirkt die Strategie? Hat sich die Haltung bewegt? | aktualisierte Matrix, Massnahmen, Eskalationen | laufend, mindestens pro Meilenstein |
Der vierte Schritt ist der wichtigste und der am häufigsten vernachlässigte. Haltungen verändern sich, wenn Entscheide fallen, Budgets gekürzt werden oder Personen wechseln. Eine Stakeholder-Matrix, die älter als ein Meilenstein ist, beschreibt meist die Vergangenheit. In vielen Projekten genügt es, die Matrix in der Steuerungssitzung als festen Traktandenpunkt zu führen und Veränderungen in einem Satz zu begründen.
Wer gehört zu den Stakeholdern eines Projekts?
Zu den Stakeholdern gehören nicht nur Auftraggeber und Projektteam, sondern alle, deren Arbeit, Budget, Daten oder Entscheidungsrechte das Projekt berührt. Bewährt hat sich, die Liste aus mehreren Quellen zu speisen, statt sie in einer Sitzung aus dem Gedächtnis zu erstellen.
| Quelle | Was sie zeigt | Typische Funde |
|---|---|---|
| Organigramm und Projektorganisation | formale Entscheidungs- und Weisungswege | Auftraggeber, Linienvorgesetzte, Lenkungsausschuss |
| Prozesslandkarte | wer Inputs liefert und Outputs nutzt | vor- und nachgelagerte Teams, Kundendienst |
| Verträge und Lieferantenliste | externe Abhängigkeiten | Lieferanten, Dienstleister, Lizenzgeber |
| Datenflüsse | wer Daten besitzt, verarbeitet oder schützt | Datenschutzberatung, Informatiksicherheit, Archiv |
| Recht und Aufsicht | wer Vorgaben macht oder prüft | Aufsichtsbehörde, Revision, Arbeitnehmervertretung |
| Gespräche mit ersten Stakeholdern | wen die Beteiligten selbst für wichtig halten | informelle Meinungsführer, frühere Projektleitende |
Die letzte Quelle ist die ergiebigste. Die Frage «Wer könnte dieses Projekt unbemerkt aufhalten?» bringt regelmässig Personen zutage, die in keinem Organigramm als Entscheidungsträger erscheinen, etwa die erfahrene Sachbearbeiterin, deren Excel-Liste heute den ganzen Prozess zusammenhält. Für die Dokumentation eignet sich eine einfache Stakeholderanalyse-Vorlage; in HERMES-Projekten heisst das Ergebnis Stakeholderliste.
Welche Modelle eignen sich für die Stakeholderanalyse?
Für die Analyse haben sich drei Modelle durchgesetzt, die sich ergänzen: die Macht-Interesse-Matrix für die grobe Einteilung, das Salienzmodell für die Priorisierung und die Engagement-Bewertung für die Steuerung. Wer nur ein Modell nutzt, übersieht meist eine Dimension.
Macht-Interesse-Matrix
Die Matrix ordnet jede Gruppe nach ihrem Einfluss auf das Projekt und ihrem Interesse an seinem Ergebnis in vier Felder. Daraus folgen Grundstrategien: eng einbinden, zufriedenstellen, informiert halten oder beobachten. Der Vorteil ist die Einfachheit, der Nachteil die fehlende Aussage über die Haltung. Ein mächtiger Stakeholder mit hohem Interesse kann Förderer oder Gegner sein. Eine Stakeholder-Matrix ist deshalb immer nur der erste Schritt.
Salienzmodell
Mitchell, Agle und Wood haben 1997 vorgeschlagen, Stakeholder nach drei Merkmalen zu bewerten: Macht, Legitimität und Dringlichkeit [4]. Wer alle drei Merkmale vereint, verlangt die grösste Aufmerksamkeit. Das Modell erklärt, warum eine Gruppe ohne formale Macht plötzlich wichtig wird: Eine Arbeitnehmervertretung mit legitimem Anliegen und hoher Dringlichkeit gewinnt Einfluss, sobald sie das Thema öffentlich macht oder rechtliche Mittel nutzt.
Engagement-Bewertung
Der PMBOK Guide beschreibt eine Bewertung, die für jeden Stakeholder die heutige und die gewünschte Haltung festhält, zum Beispiel ahnungslos, ablehnend, neutral, unterstützend oder führend [2]. Die Differenz zwischen heute und Ziel ist der eigentliche Arbeitsauftrag. Sie macht sichtbar, wo das Projekt Überzeugungsarbeit leisten muss und wo Information genügt.
| Modell | Dimensionen | Stärke | Grenze |
|---|---|---|---|
| Macht-Interesse-Matrix | Einfluss, Interesse | schnell, gut kommunizierbar | sagt nichts über die Haltung |
| Salienzmodell | Macht, Legitimität, Dringlichkeit | erklärt Prioritätsverschiebungen | aufwendiger, subjektiv |
| Engagement-Bewertung | Haltung heute und Ziel | macht den Handlungsbedarf messbar | braucht regelmässige Aktualisierung |
Praxisbeispiel: Eine Treuhand führt eine Projektsoftware ein
Ein Beispiel zeigt, wie die Modelle zusammenspielen. Eine Treuhandgesellschaft mit 25 Mitarbeitenden ersetzt Excel-Listen für Mandate, Fristen und Aufwände durch eine Projektsoftware. Die Geschäftsleitung ist Auftraggeberin, ein Partner leitet das Projekt.
| Stakeholder | Einfluss | Interesse | Haltung heute | Ziel | Strategie |
|---|---|---|---|---|---|
| Geschäftsleitung | hoch | hoch | unterstützend | führend | eng einbinden, Entscheide an Meilensteinen |
| Mandatsleitende Partner | hoch | mittel | neutral | unterstützend | zufriedenstellen, Nutzen für Fristenkontrolle zeigen |
| Sachbearbeitung mit Excel-Wissen | mittel | hoch | ablehnend | unterstützend | einbinden, Pilotrolle, Excel-Logik übernehmen |
| Lernende | niedrig | mittel | neutral | neutral | informiert halten, Schulung |
| Externe Lohnbuchhaltung | niedrig | niedrig | ahnungslos | neutral | beobachten, Schnittstelle früh klären |
| Datenschutzverantwortliche | mittel | hoch | neutral | unterstützend | früh einbinden, Auftragsverarbeitung prüfen |
Die wichtigste Erkenntnis liefert die dritte Zeile. Die Sachbearbeitung hat formal wenig Macht, aber ihr Wissen steckt in den heutigen Listen. Lehnt sie die Software ab, wird die Datenübernahme lückenhaft und die Akzeptanz im Team sinkt. Die Strategie lautet deshalb nicht «informieren», sondern «zur Mitgestalterin machen»: Die bisherigen Kontrolllogiken werden in die neue Lösung übernommen, und die Sachbearbeiterin testet als Erste. Wie sich solche Haltungen ändern lassen, beschreibt das Kapitel Widerstand in Veränderungsprojekten.
Welche Strategie passt zu welchem Stakeholder?
Die Strategie leitet sich aus Einfluss und Haltung ab und wird im Kommunikationsplan konkret: wer, was, wann, über welchen Kanal, mit welchem Ziel. Ein Kommunikationsplan ohne Ziel pro Gruppe ist nur ein Verteiler.
| Lage | Strategie | Typische Massnahmen |
|---|---|---|
| hoher Einfluss, unterstützend | als Fürsprecher nutzen | Sponsoring sichtbar machen, Entscheide gemeinsam vertreten |
| hoher Einfluss, ablehnend | Interessen klären, Einwände ernst nehmen | Einzelgespräch, Varianten prüfen, Betroffenheit reduzieren |
| geringer Einfluss, stark betroffen | beteiligen | Workshops, Pilotgruppen, Feedbackschlaufen |
| geringer Einfluss, wenig betroffen | effizient informieren | Newsletter, Intranet, Projektseite |
Zur Strategie gehört die Klärung der Rollen. Eine RACI-Matrix hält fest, wer verantwortlich ist, wer entscheidet, wer konsultiert und wer informiert wird. Sie verhindert die häufigste Ursache für Stakeholder-Konflikte: Eine Person erwartet, gefragt zu werden, und erfährt die Entscheidung aus einer Rundmail. Für den Kommunikationsplan selbst hilft die Checkliste Kommunikationsplan.
Welche Mitwirkungsrechte gelten in der Schweiz, in Deutschland und in Österreich?
Führt ein Projekt neue Software, Arbeitsabläufe oder Kontrollmöglichkeiten ein, haben Arbeitnehmende und ihre Vertretungen gesetzliche Rechte. Diese Rechte machen sie zu Stakeholdern mit rechtlich abgesichertem Einfluss. Die Unterschiede zwischen den drei Ländern sind erheblich.
| Land | Rechtsgrundlage | Kerninhalt | Folge für das Projekt |
|---|---|---|---|
| Schweiz | Art. 26 ArGV 3; Art. 9 und 10 Mitwirkungsgesetz | Systeme, die das Verhalten am Arbeitsplatz überwachen sollen, sind verboten; Informations- und Mitspracherechte bei Gesundheitsschutz | Auswertungen auf Personenebene vermeiden oder begründen; Arbeitnehmervertretung informieren |
| Deutschland | § 87 Abs. 1 Nr. 6 und § 90 BetrVG | Mitbestimmung bei technischen Einrichtungen, die Verhalten oder Leistung überwachen können; Unterrichtung bei neuen Arbeitsverfahren | ohne Zustimmung des Betriebsrats kein Rollout; früh einbinden, Betriebsvereinbarung einplanen |
| Österreich | §§ 96 und 96a ArbVG | Zustimmung des Betriebsrats für Kontrollsysteme, die die Menschenwürde berühren, und für bestimmte Personaldatensysteme | Zustimmung als Meilenstein im Terminplan |
In der Schweiz verbietet Art. 26 ArGV 3 Überwachungs- und Kontrollsysteme, die das Verhalten der Arbeitnehmenden am Arbeitsplatz überwachen sollen; sind sie aus anderen Gründen nötig, müssen sie so gestaltet sein, dass Gesundheit und Bewegungsfreiheit nicht beeinträchtigt werden [5]. Das Mitwirkungsgesetz gibt der Arbeitnehmervertretung Informationsrechte und besondere Mitspracherechte, unter anderem in Fragen des Gesundheitsschutzes [6].
In Deutschland hat der Betriebsrat nach § 87 Abs. 1 Nr. 6 BetrVG mitzubestimmen bei Einführung und Anwendung technischer Einrichtungen, die dazu bestimmt sind, Verhalten oder Leistung zu überwachen [7]. Nach der Rechtsprechung genügt die objektive Eignung zur Überwachung; die Absicht des Arbeitgebers ist nicht entscheidend. Praktisch betrifft das fast jede Projekt- und Zeiterfassungssoftware. § 90 BetrVG verlangt zusätzlich, den Betriebsrat rechtzeitig über die Planung neuer Arbeitsverfahren zu unterrichten [8].
In Österreich bedürfen Kontrollmassnahmen und technische Systeme, die die Menschenwürde berühren, nach § 96 ArbVG der Zustimmung des Betriebsrats; für Personaldatensysteme, die über allgemeine Angaben und fachliche Voraussetzungen hinausgehen, sieht § 96a ArbVG ebenfalls eine Zustimmung vor, die durch die Schlichtungsstelle ersetzt werden kann [9].
Warum gehören Stakeholdermanagement und Change-Management zusammen?
Stakeholdermanagement fragt, wer betroffen ist und wie er eingebunden wird; Change-Management fragt, wie Menschen eine Veränderung tatsächlich vollziehen. Beides lässt sich nicht trennen, weil Akzeptanz das Ergebnis aus Einbindung und erlebter Veränderung ist. Projekte, die ihre Stakeholder gut informieren, aber den Übergang im Alltag nicht begleiten, erreichen Zustimmung in Sitzungen und Ablehnung am Arbeitsplatz.
Für die Gestaltung des Übergangs gibt es mehrere Modelle mit unterschiedlicher Perspektive: Lewin beschreibt Veränderung als Auftauen, Verändern und Stabilisieren, Kotter als Folge von Führungsaufgaben, ADKAR als individuelle Lernschritte. Der Vergleich und die Auswahl für Ihr Projekt stehen im Kapitel Change-Management-Modelle. Wie Widerstand entsteht und warum er oft wertvolle Information enthält, behandelt das Kapitel Widerstand. Für die Vertiefung bietet die Akademie den Kurs Change-Management.
Wie führt man Stakeholder ohne Weisungsbefugnis?
Projektleitende haben gegenüber den meisten Stakeholdern keine Weisungsbefugnis. Sie führen über Verständigung, Vertrauen und gezielt eingesetzte Machtquellen wie Fachwissen oder Zugang zu Entscheidungsträgern. Dieses Konzept heisst laterale Führung und ist im Kapitel Laterale Führung mit Beispielen beschrieben.
Zwei Situationen verlangen besondere Aufmerksamkeit. Erstens Stakeholder, die blockieren, ausweichen oder Entscheide nachträglich infrage stellen; dafür gibt es das Kapitel Umgang mit schwierigen Stakeholdern. Zweitens Konflikte im Team oder zwischen Gruppen, die sich verhärten; das Kapitel Konfliktmanagement nach Glasl zeigt, auf welcher Eskalationsstufe welche Intervention noch wirkt. Viele Stakeholder-Probleme sind übrigens versteckte Projektrisiken; es lohnt sich, sie zusätzlich im Risikomanagement zu führen.
Wie misst man den Erfolg des Stakeholdermanagements?
Erfolg zeigt sich darin, dass sich die Haltung der wichtigen Stakeholder in Richtung Ziel bewegt und Entscheide ohne Verzögerung fallen. Messbar wird das über wenige, regelmässig erhobene Indikatoren statt über einmalige Umfragen.
| Indikator | Messung | Warnsignal |
|---|---|---|
| Engagement-Lücke | Anzahl wichtiger Stakeholder, deren Haltung vom Ziel abweicht | Lücke wächst über zwei Meilensteine |
| Entscheidungsdauer | Tage zwischen Antrag und Entscheid im Lenkungsausschuss | Entscheide werden wiederholt vertagt |
| Beteiligung | Teilnahme an Workshops, Tests und Reviews | sinkende Teilnahme der Fachbereiche |
| Rückmeldungen | Anzahl und Art der Einwände im Feedbackkanal | Einwände verschwinden plötzlich ganz |
| Nutzung nach Einführung | aktive Nutzende im Verhältnis zur Zielgruppe | Parallelbetrieb alter Werkzeuge |
Das vierte Warnsignal wirkt paradox, ist aber verlässlich: Wenn Einwände plötzlich ausbleiben, haben Stakeholder oft resigniert oder suchen andere Wege. Schweigen ist keine Zustimmung, wie das Abilene-Paradoxon eindrücklich zeigt.
Wer übernimmt welche Aufgabe im Stakeholdermanagement?
Stakeholdermanagement ist keine Einzelaufgabe der Projektleitung. Die wirksamste Arbeitsteilung verbindet die Steuerung durch die Projektleitung mit der sichtbaren Verantwortung des Auftraggebers und der Beziehungsarbeit einzelner Teammitglieder. ISO 21502 ordnet dem Sponsor ausdrücklich die Verantwortung dafür zu, dass das Projekt seinen Nutzen für die Organisation erreicht [1].
| Rolle | Aufgabe | Typischer Beitrag |
|---|---|---|
| Auftraggeber oder Sponsor | vertritt das Projekt gegenüber Geschäftsleitung und wichtigen Stakeholdern | begründet die Veränderung, entscheidet Zielkonflikte, ist für Betroffene sichtbar |
| Projektleitung | steuert den Prozess, hält Analyse und Kommunikationsplan aktuell | moderiert, eskaliert, berichtet im Lenkungsausschuss |
| Teilprojektleitende und Fachverantwortliche | pflegen die Beziehung zu ihren Fachbereichen | holen Rückmeldungen ab, erklären Lösungen in der Fachsprache |
| Lenkungsausschuss | entscheidet über Prioritäten und Konflikte zwischen Bereichen | vertritt die Interessen der Linie verbindlich |
| Change- oder Kommunikationsfachleute | gestalten Botschaften, Formate und Trainings | sorgen für Konsistenz über alle Kanäle |
Die Zuordnung gehört in die RACI-Matrix. Besonders wichtig ist, dass jede Beziehung zu einem einflussreichen Stakeholder eine benannte Person im Projekt hat. Wenn alle zuständig sind, kümmert sich in der Praxis niemand, und der Kontakt läuft nur noch über Rundmails.
Wie behandeln HERMES, PRINCE2 und Scrum Stakeholder?
Die verbreiteten Projektmethoden setzen Stakeholdermanagement unterschiedlich um, verfolgen aber dasselbe Ziel. HERMES 2022 verlangt in der Initialisierung eine Stakeholderliste und eine Analyse der Stakeholderinteressen als Ergebnisse; die Methode ordnet die Arbeit dem Modul Projektführung zu. PRINCE2 bündelt die Einbindung in einer Kommunikationsstrategie, die regelt, wer welche Information wann erhält. Der PMBOK Guide behandelt Stakeholder als eigenen Leistungsbereich über den ganzen Lebenszyklus [2].
Scrum kennt keinen eigenen Stakeholderprozess, verankert die Einbindung aber in den Events: Im Sprint Review prüfen Stakeholder das Inkrement und geben Rückmeldung, der Product Owner vertritt ihre Interessen im Backlog. Der Vorteil ist die regelmässige, konkrete Rückmeldung am Ergebnis statt an Dokumenten. Die Grenze zeigt sich bei Stakeholdern, die nicht an Reviews teilnehmen, etwa Aufsicht, Arbeitnehmervertretung oder Finanzen. Für sie braucht auch ein agiles Projekt eine bewusste Strategie; Hinweise dazu stehen im Leitfaden Agiles Projektmanagement und für HERMES-Projekte in der Stakeholderliste nach HERMES.
Welche Fehler machen Projekte im Stakeholdermanagement?
Die typischen Fehler sind gut bekannt und trotzdem verbreitet. Sie haben eine gemeinsame Ursache: Stakeholdermanagement wird als Dokument verstanden statt als Führungsaufgabe.
- Die Analyse entsteht einmal im Kick-off und wird nie aktualisiert.
- Stakeholder werden nach Hierarchie priorisiert, nicht nach Einfluss auf den Projekterfolg.
- Betroffene werden informiert, wo sie hätten beteiligt werden müssen.
- Einwände werden als Störung behandelt statt als Information über Risiken.
- Die Arbeitnehmervertretung wird erst kurz vor dem Rollout einbezogen, obwohl sie Mitbestimmungsrechte hat.
- Der Auftraggeber delegiert das Sponsoring vollständig an die Projektleitung und ist für Betroffene unsichtbar.
Ein siebter Fehler betrifft die Sprache. Projekte beschreiben Nutzen gern in ihren eigenen Begriffen, etwa Durchlaufzeit, Datenqualität oder Medienbrüche. Betroffene fragen dagegen, was sich an ihrem Arbeitstag ändert, ob sie mehr oder weniger Kontrolle haben und wer ihnen hilft, wenn etwas nicht funktioniert. Wer die Kommunikation pro Gruppe in deren Sprache übersetzt, spart sich viele Missverständnisse, die später als Widerstand erscheinen. Wer diese Fehler vermeidet, braucht kein aufwendiges Instrumentarium. Eine aktuelle Matrix, ein Kommunikationsplan mit Zielen pro Gruppe, eine RACI für die Entscheide und ein fester Traktandenpunkt in der Steuerung reichen in den meisten Projekten aus. Im Kurs Stakeholder-Kommunikation lässt sich das Vorgehen an Fallbeispielen üben.