Stakeholderanalyse

Beschreibung

Die Stakeholderanalyse ist eine Ausprägung der Umfeldanalyse. Sie fokussiert auf die Ermittlung von »Interessenträger« (englisch: stakeholder) einer Sache, sowie der Art ihrer Beziehung zu dieser Sache. Typische Stakeholder eines Unternehmens sind beispielsweise Lieferanten, Kunden, Mitarbeiter, Management, Eigentümer, Behörden, Konkurrenten, etc.

Im Kontext von Projekten haben Stakeholder ein Interesse an diesem Projekt oder sind von diesem Projekt in irgendeiner Weise betroffen. 

Die Stakeholder können geordnet werden nach:

  • Ihrem Einfluss auf andere Stakeholder
  • Ihrem Entscheidungspotenzial (finanziell, technisch, politisch, etc.)
  • Ihrer Einstellung zum Projekt (Gegner, Konkurrent, Befürworter, neutral,...)
  • Ihrer Rolle im Projekt
  • Ihren Beziehungen untereinander

Die Stakeholderanalyse ist die Grundlage dafür, Stakeholder gezielt in einem Kommunikationsplan adressieren zu können, die Kommunikation mit den Stakeholdern zu verbessern und verbessert das Verständnis ihrer Interessen. Offensichtliche, schwelende oder bislang unbekannte Konflikte können mittels Stakholderanalyse früher erkannt werden.

Wie externe Stakeholer zu informieren sind ist sorgfältig zu überlegen. PRINCE2 und der PMBOK-Guide sehen einen Kommunikationsmanagementplan vor, denn nicht jeder Stakeholder benötigt die gleichen Informationen und schon gar nicht in der gleichen Aufbereitung.

Stakeholderanalyse ist immer nur eine Momentaufnahme und muss (wie das Risikomanagement) im Lauf der Zeit aktualisiert werden, um wirksam zu bleiben.

Vorgehen

  1. Identifizierung der Stakeholder
  2. Analyse der Stakeholder inkl. Kraftfeldanalyse
  3. Aus (1) und (2) die Frage beantworten: Wer kann wie das Projekt zum Scheitern bringen?
  4. Ableitung von Konsequenzen für das Stakeholdermanagement und Maßnahmen für das Risikomanagement definieren.

Tool & Templates

Stakeholder Identity Matrix Card 

Beispiel nach [Gregorc/Weiner]

Name...
Position 
Rolle im Projekt 
Einstellung zum Projekt 
Beziehungen zu 

 

Stakeholderdiagramm
Gliffy Zoom Zoom

Stakeholderanalyse mittels EXCEL (Bubble-Diagramm)

Ausgang ist die Tabelle mit der Identifikation der Stakeholder. Darin werden Einfluß/Macht, Konfliktpotential, Projektnähe und andere Einflußfaktoren bewertet.

Beispiel:

 

Die Größe der Blase ergibt sich aus der Gewichtung aller Faktoren (einfache Multiplikation)

Beispiel:

Am Beispiel sieht man, dass zwar die Nähe zum Projekt beim BUND nicht für dessen Einflußgröße und Risikopotential maßgeblich ist.

(ist nur ein Beispiel)

Einflußfaktoren als Netzgrafik

Beispiel eines Schichtenmodells (Nähe der Stakeholder zum Projekt - Stakeholdergruppen)

 

Alternative Stakeholderanalyse mittels EXCEL

Frédéric Jordan nutzt folgende Stakeholder-Liste in seinem Fallbeispiel Ideenmanagement. Den Umgang und die Erfahrungen damit beschreibt er hier inkl. Excel-Vorlage.

Stakeholderanalyse mittels Value-Proposition Canvas

Marcus Raitner berichtet in seinem Blog-Artikel Kunden und Nutzen External Link über das Value-Proposition Canvas zur Stakeholder Analyse: 

Im Kontext von Projekten, insbesondere zu Projektbeginn, halte ich dieses Value-Proposition Canvas für eine ausgezeichnete Methode, um die wesentlichen Stakeholder zu analysieren (Job, Pain, Gain) und ihnen mit dem Projekt einen attraktiven Nutzen zu bieten. Die Stärke der Canvas-Methode liegt eindeutig in der Übersichtlichkeit und der Aufforderung zum gemeinsamen interaktiven Arbeiten daran (ganz im Gegensatz zu einer unübersichtlichen Stakeholderliste). Gerade in Workshops zur Projektinitialisierung erreicht man damit schnell einen guten ersten Einblick in die „Seele“ der Stakeholder.

 

Ein Value Proposition Canvas besteht also aus zwei Teilen: rechts der Kunde (Customer Profile) und links das Werteangebot (Value Proposition). Es ist damit eine Detailaufnahme zweier Bereiche (Customer Profile und Value Proposition) aus dem bekannten Business Model Canvas von Alexander Osterwalder External Link.

 


Erfahrungsberichte

Quellen

  • Stakeholderanalyse (Wikipedia)
  • Kraftfeldanalyse (Wikipedia)
  • W. Gregorc, K. L. Weiner, Claim Management. Ein Leitfaden für Projektmanager und Projektteam, Publicis, Erlangen 2005
  • Stakeholder sind Kommunikationsadressen des sozialen Systems Projektorganisation

Weitere Beiträge auf openPM zu Stakeholder

Found 5 search result(s) for Stakeholder.

Page: 2) Stakeholder-Analyse (Inhalt)
... Darstellung ist derzeit nicht vorgesehen.   Grundlegende Informationen zur StakeholderAnalyse auf openPM.   Verwendetes ExcelFile StakeholderAnalyse.xls stakeholder stakeholdermanagement stakeholderanalyse analyse
05. Dec 2012
Labels: stakeholder, stakeholdermanagement, stakeholder-analyse, analyse
Page: Stakeholdermanagement (Inhalt)
... Strategien, Massnahmen und Handlungsempfehlungen Eine weitere Aufgabe besteht darin Vertrauen und Kooperation zwischen Unternehmung und Stakeholder sowie zwischen den Stakeholdern untereinander aufzubauen. Einteilungsformen von Stakeholdern Die Literatur schlägt diverse Einteilungsformen von Stakeholdern vor. An dieser Stelle zwei grobe Ausrichtungen: Interne und Externe Stakeholder In früheren Zeiten
02. Nov 2012
Labels: stakeholder, stakeholdermanagement, management
Page: Projektmanagement Automotive (Inhalt)
... gpm kontingenz lean methoden performance prognose selbstorganisation selbstmanagement steuerung strategie stakeholder technik theorie vertrauen globalisierung socialmedia weltgesellschaft vision vda wert daimler ...
08. Feb 2014
Labels: wert, organisationsgestaltung, tier, steuerung, socialmedia ... 48 more labels.
Page: Product Backlog Item (Inhalt)
... wem Weg zu einem Ziel? Meist wird Arbeit hinsichtlich ROI (Return On Invest) für einen oder mehrere Stakeholder optimiert. In vielen Fällen muss ein Gleichgewicht zwischen den Stakeholderinteressen erzielt werden. Einflüsse zu viel/zu wenig Fokus auf einen einzelnen ...
11. Jul 2013
Labels: product, scrum, pattern, backlog
Page: Projektmarketing (Inhalt)
... falsch“ an die Öffentlichkeit. Ziele des Projektmarketings Ein wesentliches Ziel des Projektmarketings ist die aktive Gestaltung der Beziehungen zu den Stakeholdern. Durch eine kooperative Miteinbeziehung der Forderungen aus dem Umfeld (Stakeholder), können deren Interessen mit den Interessen des Projekts in Einklang gebracht werden. Dadurch werden Streitpunkte minimiert und Verständnis ...
16. Mar 2014

Autoren

Twittern

19 Comments

  1. Hilfreich ist auch bei den ermittelten Stakeholdern zu vermerken wie groß deren Einfluss auf das Projekt ist. So kann man sich auf die wesentlichen Stakeholder konzentrieren. 

    Als gute Möglichkeit die Verknüpfung zwischen den einzelnen Plänen herzustellen und die Abdeckung sicher zu stellen schreibe ich zu den Stakeholdern deren Informationsbedarf dahinter und verlinke (evtl. mit Nr.) auf einen Eintrag im Kommunikationsplan. So kann man leicht sehen wie die Kommunikation zu den Stakeholdern ablaufen soll und ob es da evtl. ein "Loch" gibt. 

  2. Das genannte Vorgehen ist mir ein wenig zu "dünn". Vor allem fehlt mir die Kontrolle.

    Vorschlag für ein generisches Vorgehen:

    1) Identifikation - Auflistung möglicher Stakeholder
    2) Analyse - Charakterisierung (Interessen, Ansprüche)
    3) Planung - Ableitung und Planung von Massnahmen, ev. Prioritätensetzung
    4) Implementierung/Umsetzung - Aufbau von Vertrauen und Kooperation, Umsetzung der Massnahmen
    5) Kontrolle - Kontrolle der Wirksamkeit der einzelnen Massnahmen.

    Bei Punkt 1 wäre eine zusätzliche Strukturierung sinnvoll. Zum Beispiel:

    • Intern / Extern
    • Primär / Sekundär
    • Einzelne Personen / Gruppen
    • Key Stakeholder
    • usw.

    Bei Punkt 2 würde ich einfach nach Macht, Legitimität und Dringlichkeit unterscheiden. Daraus wird anschliessend die Relevanz der Stakeholder abgeleitet.

    Andere Meinungen?

    Zusätzliche Anmerkung:
    Eventuell sollte eine übergeordnete Seite für das "Stakeholder-Management" eingesetzt werden. Die Analyse ist ja nicht die einzige Tätigkeit. Das Ziel des Stakeholder-Management - weitgehend identische Ziele zwischen den Stakeholdern und den Projektzielen - fehlt mir gänzlich.

    Gruss
    Frédéric

     

  3. Bin jetzt nicht ganz sicher, wie beim Punkt 2 Legitimität und Dringlichkeit zu verstehen sind. Ich sehe da hauptsächlich drei Dimensionen: Einfluss/Macht (groß .. kein), Interesse (groß .. kein), Einstellung (positiv .. negativ). Diese drei Dimensionen sind grundsätzlich unabhängig voneinander. Die Dimensionen sollten auch so angelegt werden, dass es kein Zweifel an der Einordnung geben kann (zw. Stakeholder und bspw Projektleiter). Hier sehe ich u.U. bei der Legitimität eine Schwierigkeit. Kaum etwas ist schlimmer, wenn es hier unterschiedliche Bewertungen gibt (bspw. bei u.g. Projekten, wenn sich Demonstranten völlig im Recht zum Widerstand glauben, die "andere Seite" das aber völlig anders sieht und deshalb zur Ignoranz tendiert).

    Bzgl. dem fehlenden Ziel des Stakeholder-Managements stimme ich zu, allerdings glaube ich nicht, dass eine Ausrichtung der aller (edit 1.9.) Stakeholder an den Projektzielen möglich ist. Hier möchte ich auf Projekte wie Stuttgart 21 oder die früheren AKW- und Endlager-Projekte verweisen. Ziele des Stakeholder-Mgmt sind für mich:

    • Einbeziehung der positiven Stakeholder
    • Neutralisierung der negativen Stakeholder
    • Größtmögliche Effizienz im Stakeholder-Mgmt, d.h. vorallem die Interessierten und Mächtigen behandeln und keine Zeit an die Desinteressierten/Ohnmächtigen verschwenden. Das Ganze sollte natürlich trotzdem unter dem Aspekt der Humanität betrachtet werden, mindestens um zu verhindern, dass es irgend zur "Revolution" kommt (s. nächster Punkt).
    • Fortlaufende Kontrolle der Wirksamkeit der Maßnahmen und Überprüfung der Analyse (die drei Dimensionen bezogen auf einzelne Stakeholder oder auch neu entstehende Gruppen sind leider nicht konstant). Das hat dann wieder etwas mit Effektivität zu tun.
    1. Stakeholdermanagement ist auch Riskobegrenzung....grds. sollte man wissen wer ein Projekt torpedieren kann. Und da sollte man durchaus alle Möglichkeiten und "Unmöglichkeiten" in Betracht ziehen.

      Bei Projekten wie Stuttgart21 würde ich allerdings nicht mehr von "Stakeholdermanagement" sprechen wollen, das ist Politik. Politik ist per se schlecht für Projekte....(behaupte ich jetzt mal so) (smile)

    2. Die Gliederung einer Analyse beruht oft auf Erfahrung. Es gibt meines Erachtens kein Richtig oder Falsch, nur unterschiedliche Auslegungen. Um dem Leser eine möglichst breite Auswahl zu bieten, sei es nur für die gedankliche Auseinandersetzung mit dem Thema, würde ich eine Liste mit vielen Varianten vorschlagen.

      Wer hilft mit? Diese Liste wird später in die Seite integriert.

      Stakeholderziele und Projektziele zu 100 % zu vereinen ist sicher nahezu unmöglich, aber eine Annäherung sollte stattfinden. Gerade für die benötigte Überzeugungskraft sehe ich grosses Potential, wenn beide Sichten übereinander gelegt werden.

       

       

  4. anbei zwei Beispiele...(Anhänge als EXCEL-Dateien)...

  5. Ich freu mich ja über eure konstruktiven Anregungen, aber wir sind auch ein Wiki, da dürft ihr die Texte editieren. Wäre zu schade, wenn euer Input in den Kommentaren untergehen würde anstatt direkt den Beitrag zu verbessern!

    Frédéric Jordan: Klar ist der Artikel erstmal nur auf die Stakeholderanalyse beschränkt. Stakeholdermanagement ist mehr. Ich will nur nicht lauter leere Seiten anlegen. In der Übersicht ist ein eigener Punkt Stakeholdermanagement in den Prozessgruppen vorgesehen. Lege doch dort die Seite Steholdermanagement an und integriere die Stakeholderanalyse mit einer Verknüpfung. Wiki macht´s möglich!

    1. Sehr gerne. Du meinst hier?


      Werde mich in den nächsten Tagen dem annehmen.
  6. Irgendwie fehlt mir in der ganzen Diskussion der Aspekt des Anforderungsmanagements. In Software-Entwicklungsprojekte sind (die wichtigsten) Stakeholder die späteren Benutzer des Produktes. Das gleiche gilt wohl für jedes Entwicklungsprojekt. Die Erfassung der Anforderungen der Stakeholder in einem ersten Anforderungsworkshop ist m.E. wichtiger als die Überlegung wer hilft / wer torpediert. Denn wenn ein Produkt (ein Projektergebnis) nicht den Anforderungen möglichst vieler Stakeholder genügt ist es gescheitert. Terminziel hin, Kostenziel her.

    1. Anforderungsmanagement ist nicht Bestandteil der Stakeholderanalyse, aber Benutzer und Benutzervertreter sind Stakeholder.

      Ohne Stakeholderanalyse kein Kommunikationsplan, und in Folge kein Stakeholdermanagement.

      Und was das Scheitern von Projekten angeht: Irgendwann ist soviel Geld und Zeit in ein Projekt geflossen, da wird das Projekt per se ein Erfolg, Siehe Elbfilharmoinie in Hamburg und Flughafen in Berlin. Ich gehe jede Wettte ein, irgendwann steht in der Zeitung welch ein Erfolg diese Projekte waren.

    2. Es braucht beides. Und wenn man berücksichtigt, wie viele sinnvolle Projekte und Anforderungen gescheitert sind, weil es nicht gelungen ist die Gesamtheit der Stakeholder für das Projekt zu mobilisieren, sondern "nur" die Anforderer/Benutzer, dann wird klar, wie essentiell ein Stakeholdermanagement ist. Stakeholdermanagement muss ja auch nicht als formale Übung ablaufen. Bei vielen "alten Hasen" läuft das ganz intuitiv.

      1. Ich stelle das Stakeholdermanagement per se ja gar nicht in Frage. Mir kommen nur bei vielen Wasserfallern die Anwender manchmal etwas zu kurz. (wink) Schönes Wochenende

        1. Böse zurück gefragt: Kennt beispielsweise Scrum überhaupt Stakeholder? Ein Product Owner vertritt sicher nicht die Gesamtheit der Stakeholder.

          (Womit ich wieder in die Falle getappt bin, dass man mich fälschlicherweise für einen Anhänger des Wasserfalls hält.)

          1. Ich denke, es gibt in keinen PM-Modell wirklich jemand, der alle Stakeholder vertritt. Das ist ja das Vertrackte. Tw. sind Stakeholder halt aus einen Paralleluniversum, die manchmal durch ein Wurmloch bei einem auftauchen. Deshalb glaube ich auch nicht, dass es so einfach möglich ist, alle Stakeholder an den Projektzielen auszurichten. Klar kann/sollte das ein Metaziel sein, trotzdem braucht man hin und wieder einen Plan B.

          2. Nicht verwechseln. Ich rede von agilem Projektmanagement (APM). Scrum ist nur EIN  Framework im APM. Andere sind z.B. XP (Extreme Programming), OEP (Oose Engineering Process) etc.

            Das agile Projektmanagement kennt den initialen Anforderungsworkshop zu dem möglichst alle Stakeholder(-vertreter) eingeladen werden sollen. Noch einmal: Natürlich gibt es Stakeholder, die keine User sind und einem Projekt Steine in den Weg legen können. Aber die wichtigsten Stakeholder sind in ENTWICKLUNGSprojekten die späteren Anwender. Was nützt ein noch so glatt gelaufenes Projekt, wenn später die Anwender die Software, das Auto, das Smartphone (Nokia) nicht kaufen?

            Projekte sind betriebswirtschaftliche Investitionen, die ein innovatives Produkt mit einem schnellen ROI (Return on Investment) schaffen. (Das ist die agile Definition eines Projektes in Abweichung zum PMBoK, DIN 69901, ICB).

  7. Etwas verspätet, war zwischendurch beim Abendessen, mein Stakeholder hat gerufen (wink), deshalb "out of order".

    Durch die Stakeholder-Analyse werden oft spätere Nutzer erst erkannt. Anforderer sind nicht gleich Nutzer. Nutzer sind Stakeholder, aber nicht alle Stakeholder sind Nutzer. Es kommt immer mal wieder vor, dass Stakeholder gerade auch Nicht-Nutzer (nicht wollen, nicht dürfen, nicht können usw.) sind. Wehe, wenn man die übersieht. Deshalb erst Stakeholder-Analyse, dann Anforderungsanalyse, trotzdem die Augen nach weiteren Stakeholder offenhalten.

     

    1. Mir hilft dabei ein "Schichtenmodell", also welche Stakeholder haben welche Nähe zum Projekt. Das wird, je weiter der Bereich gespannt wird, immer mehr Stakeholder und diffuser. Sicher kann man nicht alles vordenken und muss ergänzen. Daraus läßt sich sehr gut dann die Einflussgrößen ableiten. Dabei ist der Gag an der Geschichte, dass nicht die Nähe zum Projekt die Größe und Auswirkung von Einfluss bestimmt, sondern der Machtfaktor. Das sind dann die berückitigten "Käfer" (Stuttgart21???) die aus "Wurmlöchern" kommen. (smile)

      1. Ja, der Juchtenkäfer ist ein herausragendes Beispiel für übersehene Stakeholder, speziell da diese dann von einer anderen vielbeinigen Gruppe von Stakeholdern instrumentalisiert wurden.

        Noch mal zur Klassifizierung zurück: Der wichtigste Aspekt ist m.E. der Einfluss- & Machtfaktor. Für mich ist der Vorteil dieser Betrachtungsweise, dass ich die Anwender/Nutzer hier nicht getrennt betrachten muss, weil sie natürlich einen erheblich Einfluss auf den späteren Nutzungserfolg haben. Gleichzeitig laufe ich nicht Gefahr die anderen Stakeholder zu vernachlässigen, z.B. innerbetriebliche Konkurrenten um Entwicklungsressourcen, externe Marktteilnehmer oder ganz andere Personen. Hier kommt mir spontan der Patentstreit zwischen Samsung und Apple in den Sinn. So ist der Gedanke sicher nicht verkehrt gewesen, Produktmerkmale von iPhones zu übernehmen, die bei den Anwendern gut ankommen. Samsung hat sicher bis zu einem gewissen Grad auch Apple (und deren Reaktion) in die Betrachtung einbezogen. Was sie aber wahrscheinlich unterschätzt haben, ist die Möglichkeit, dass amerikanische Patentgerichte im Zweifelsfall doch eine Stars-and-Stripes-Brille aufhaben könnten.

        Klar ist es wichtig, die Anwender zu berücksichtigen. Das würde ich aber immer als (offensichtliches) Plichtprogramm sehen, die Kür sind dann die anderen Stakeholder. Ich habe mehr (Entwicklungs-)Projekte daran scheitern sehen, als an der Einbeziehung der Anwender. Oder Fälle, bei denen die Produktmanager glaubten, die ultimative Weisheit bzgl. der Anwenderbedürfnisse zu besitzen und das mit eindrucksvollen Auftritten belegten (zu viele Möchte-gern-Steve-Jobs). Das kann dann ein Nachteil sein, wenn mit zu viel Überzeugungskraft gearbeitet wird.

Dieser Inhalt von openPM steht unter einer Creative Commons Lizenz (CC BY 3.0) und kann frei verwendet werden unter Namensnennung durch Link auf http://openpm.info. Unpassende Inhalte, insbesondere Verstöße gegen Urheberrechte, bitte via info@openpm.info melden. Weitere Informationen unter Nutzungsbedingungen