Inhalt : Stakeholderanalyse

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. 

Eine Diskussion zur Stakeholderanalyse in einem XING-Forum: https://www.xing.com/app/forum?op=showarticles;seoparsed=1;id=41462028;sc_o=as_g

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

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.

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

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)

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!

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.

Sehr gerne. Du meinst hier?

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.

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.

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.

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

Etwas verspätet, war zwischendurch beim Abendessen, mein Stakeholder hat gerufen , 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.

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

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.

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

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.

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.