Stakeholder Management – More than a list

In einer Studie, durchgeführt von Suzanne Robertson und Ian Alexander im Jahre 2004 (Understanding Project Sociology by Modeling Stakeholders)  wurden Beteiligte nach dem aus Ihrer Sicht größten Problem im Kontext der Stakeholder befragt. Die Ergebnisse reichen von unzulänglichem Budget und Zeit für die Arbeit mit Anforderungen für die Stakehoder, den nicht vorhandenen Fähigkeiten bei den Stakeholdern Anforderungen möglichst lösungsneutral zu formulieren, wie auch der Schwierigkeit die richtigen Stakeholder zu definieren. Weitere Punkte sind Kommunikationsprobleme zwischen der Entwicklung und der Tatsache, dass Stakeholder im Laufe der Entwicklung nicht durchgehend mitarbeiten.

Aufgrund meiner Erfahrungen in Entwicklungen aller Arten (SW, HW, Systeme etc.) stellen die Stakeholder eine wichtige Grundlage dar, um wichtige Anforderungen nicht zu vergessen und um sicherzustellen, dass auch wirklich die richtigen Anforderungen umgesetzt werden. Damit nicht nur die Anforderungen der direkten Anwender, sondern auch die, die das Produkt warten, in Betrieb nehmen, ändern oder zulassen, erfüllt werden.

Deshalb ist es erforderlich das Thema Stakeholder-Management näher zu betrachten.  Dies nicht nur am Anfang, sondern während des kompletten Lebenszyklus eines Produktes. Wie das ablaufen könnte bzw. was hierbei wichtig ist, wird im Folgenden nun andiskutiert.

Um erste Antworten auf einige dieser Fragen bzw. Gedanken geben zu können, wurde ein Prozess definiert, der den Umgang mit Stakeholdern detaillierter beschreiben soll. Demgegenüber wird den genannten Aktivitäten der konkrete Nutzen gegenübergestellt, um die Notwendigkeit der Aktivitäten zu verdeutlichen. Dies kann auch Grundlage sein, um den Prozess aufgrund konkreter Bedürfnisse bzw. gewünschtem Nutzen anpassen zu können (siehe folgende Abbildung)..

Abbildung 1 – Nutzen – Prozess

In der nächsten Abbildung werden zur Durchführung der Stakeholder-Analyse mögliche Methoden benannt. Wichtig ist, dass die Stakeholder-Analyse Informationen für die definierten Prozessaktivitäten generiert. Somit stellt die Stakeholder-Analyse eine Unterstützung der definierten Prozessaktivitäten dar und generiert somit auch konkreten Nutzen. Zur Durchführung der Stakeholder-Analyse gibt es weitreichende Methoden wie z. B. Kraftfeld-Analyse, Onion-Modell etc. die eingesetzt werden können. Selbstverständlich verbergen sich hinter den einzelnen Aktivitäten, wie „Stakeholder erheben“, „Erhebungsplan definieren“ etc. auch Best-Practices bzw. auch konkrete Methoden.

Abbildung 2 – Stakeholder Management-Aktivitäten und Methoden

Der Prozess startet mit einer Aktivität, die das Ziel hat für die nächste definierte Iteration die relevanten Stakeholder zu identifizieren. Hier gibt es ähnliche Erhebungstechniken, wie bei der Erhebung von Anforderungen selbst. Unterstützend können hier z. B. Organigramme, wie Organisationsstrukturen, Checklisten, Vorlagen, wie auch Scope-Diagramme (Umfeldanalysen) behilflich sein. In einem Erhebungsplan werden zu den einzelnen Stakeholdern Aktivitäten zur Erhebung von Anforderungen geplant. Basierend auch auf der oben genannten Studie wird vorgeschlagen, hier spezifische Stakeholder-Risiken zu identifizieren und zu priorisieren. Klassische Risiken sind z. B. Stakeholder liefern aus Gründen, fehlender Verfügbarkeit, geografischer Standort, Kulturunterschiede oder Sprachprobleme keine Anforderungen. Diese Risiken sollten der Projektleitung frühestmöglich kommuniziert werden und kontinuierlich, während des Projekts, beobachtet werden. In einem Abstimmungsplan wird definiert, welche Stakeholder bei welchen Anforderungsfreigaben in welcher Form beteiligt sind. Die Kommunikation der Anforderungen im Projekt an die Stakeholder ist Teil des Kommunikationsplans, in dem definiert wird, wer welche Anforderungen in welchem Freigabezustand erhält. Dies zur reinen Informationszwecken oder als Grundlage für wichtige Abstimmungs- bzw. Freigabesitzungen.

Eine wichtige Frage ist auch, wie sich das Thema im Rahmen von agilen Vorgehensweisen darstellt. Denn schließlich muss das Backlog auch mit irgendetwas befüllt werden. Wir bleiben am Thema dran und melden uns bald wieder.

Zu dem Thema wird auf der Reconf 2014 ein Workshop durchgeführt, der dieses Thema hier weiter detailliert und auch veranschaulicht. Siehe http://www.hood-group.com/reconf/reconf-2014/programm/workshops/gtws-d1/

Frank Stöckel

Kontaktieren Sie Frank Stöckel

Herr Frank Stöckel ist als Principal Consultant im Bereich Requirements Engineering (RE) tätig. Seine Schwerpunkte liegen in der Einführung von Requirements Engineering in Entwicklungsunternehmen mit Hilfe von Assessments, Seminaren, Workshops und Coaching. Fokus hierbei stellen wichtige initiale Pilotprojekte dar, die dann in unternehmensweite Prozessverbesserungsmaßnahmen führen, um RE langfristig in Entwicklungsunternehmen zu etablieren. Herr Stöckel führt Werkzeugauswahlverfahren für RM Tools durch, erarbeitet Konzepte zur Realisierung und Einführung von DV-Lösungen unter Einbindung von Werkzeugen des gesamten Entwicklungsprozesses. Darüber hinaus hat er in den letzten Jahren insbesondere in der Automobilindustrie Produktivstellungen (Roll-Outs) sowie Prozessentwicklungen von Anforderungsmanagement inkl. angrenzenden Prozessdisziplinen wie Projekt- und Testmanagement, Änderungsmanagement, Systemmodellierung, Lieferantendatenaustausch etc. erfolgreich geleitet. Kenntnisse in Modellierungstechniken runden sein Profil ab. Als erfahrener Trainer gibt er sein vielfältiges Wissen weiter, z.B. auch als akkreditierter Trainer für den Kurs „Certified Professional Requirements Engineering - Foundation Level".