Willkommen zum zweiten Teil unserer Stakeholder-Blogserie! Nun wollen wir auf die Identifikation der Stakeholder eingehen.

Wie wir bereits im ersten Teil erläutert haben, liefern Ihnen Stakeholder wertvolle Informationen über das zu entwickelnde System. Werden Stakeholder vergessen oder nicht berücksichtigt, kann das für Ihr Projekt fatale Folgen haben – Ihr System läuft nicht performant, findet weniger Absatz als geplant oder wird am Ende womöglich nicht abgenommen.

Spätestens im laufenden Betrieb des Systems entstehen dann Änderungsanträge um fehlende Funktionalitäten zu ergänzen oder Fehler zu beheben. Dies kostet viele Ressourcen und sollte daher vermieden werden. Der Schlüssel zum Erfolg ist eine gewissenhafte Systemanalyse und diese beinhaltet immer eine Stakeholderanalyse.

Doch wie komme ich eigentlich an meine Stakeholder?
Den ersten Schritt können Sie dabei gehen, indem Sie sich fragen: Wen betrifft mein System? Das sind nicht nur Personen, die es entwickeln, wie etwa Programmierer. Sie sollten vielmehr weiterdenken: Wer arbeitet später mit dem System? Wer steht mir bei der Umsetzung eventuell im Weg? Welche (ggf. gesetzlichen) Vorgaben muss ich beachten?

Bei diesen beispielhaften Fragen fallen Ihnen sicher bereits Antworten ein – und all diese Rollen, Personen oder Institutionen können Ihnen wichtige Informationen geben, die entscheidend für das Ergebnis Ihres Projektes sind.

Aber… Was sind eigentlich Rollen von Stakeholdern?
Die Rolle eines Stakeholders, oder einer Gruppe von Stakeholdern, ist die Bezeichnung des zuständigen Bereiches oder der Stellung, welche sie inne haben, wie beispielsweise das Management, die Käufer eines Systems oder Gegner eines Systems. Sie vertreten bestimmte Ansichten oder haben Ihrer Rolle entsprechende Wünsche.

Abb.1: Der REler und die Stakeholder

Ein Entwickler hat andere Anforderungen an das System, als der Nutzer. Der Nutzer möchte einfach „nur“, dass ein System das tut, wofür er es gekauft hat – und das am besten möglichst schnell. Dem Entwickler hingegen sind zum Beispiel Dinge wie „welche Programmiersprache kann/soll/muss ich verwenden“ wichtig.

Ein systematischer Ansatz
Um sicherzustellen, dass Sie an alle Rollen denken, empfehlen wir Ihnen ein durchdachtes Vorgehen, das Sie in jedem Projekt anwenden können.

1. Vorhandene Stakeholderlisten aufspüren
In vielen Projekten gibt es bereits Stakeholderlisten – eventuell ja auch in Ihrem. Fragen Sie danach! Auch kann eine Stakeholderliste aus einem anderen Projekt in Ihrem Unternehmen schon Aufschluss darüber geben, wer Wissensträger für ein spezielles Fachgebiet ist. Vorhandene Stakeholderlisten bieten Ihnen die Möglichkeit, Informationen wiederzuverwenden.

2. Die Stakeholdercheckliste
Eine Stakeholdercheckliste ist eine Auflistung verschiedener Rollen und Rollengruppen, die in einem Projekt als Stakeholder in Frage kommen. Diese Liste kann Ihnen helfen, keine wichtigen Stakeholder zu vergessen. Sie können unsere Stakeholdercheckliste unter www.sophist.de/re6/kapitel5 herunterladen. Wir haben zu jeder Rolle eine kurze Beschreibung angefügt um den Informations- sowie Zuständigkeitsbereich genauer abzugrenzen. Hier ein exemplarischer Ausschnitt:

Abb.2: Ausschnitt aus der Stakeholdercheckliste

Gehen Sie diese Checkliste sorgfältig durch und überlegen Sie, welche der dort aufgeführten Rollen Sie in Ihrem Projekt befragen sollten. Markieren Sie diese Rollen und fragen Sie in Ihrem Projekt, z.B. beim Projektleiter, nach einem Ansprechpartner für jede relevante Rolle.

Falls Sie zu einer Rolle keinen Ansprechpartner zur Verfügung haben, müssen Sie nicht verzagen. „Basteln“ Sie sich Ihre Anforderungsquelle einfach selbst. Solche fiktiven Stakeholder nennt man dann Personas.

Damit sind Sie bereits gut auf das Projekt vorbereitet – aber noch immer nicht am Ende der Stakeholderanalyse.

3. Der Flurfunk
Wenn Sie in einem Projekt arbeiten werden Sie immer wieder auf neue Namen stoßen – ob in einem Meeting oder bei einem Gespräch an der Kaffeemaschine. Auch hier sollten Sie stets aufmerksam sein, denn hinter diesen Namen verbergen sich potentielle Wissensträger, die Sie bisher noch nicht berücksichtigt haben. Außerdem werden Ihre vorhandenen Ansprechpartner nicht immer Zeit für Sie haben – hier kann es sich positiv auswirken, wenn Sie weitere Optionen in der Hinterhand haben.

What’s next?
Nachdem Sie nun viele Stakeholder gesammelt haben, sollten Sie diese Daten auch schriftlich festhalten. Denn wie bereits Louis Fried, Projektmanager, feststellte: “If it is not documented, it doesn’t exist … As long information is retained in someone’s head, it is vulnerable to loss.”

Wie Sie Ihr erworbenes Wissen in einer geeigneten Form dokumentieren, verraten wir Ihnen in Teil 3 unserer Serie mit dem Thema „Stakeholder-Tabellen als ein Instrument zum dokumentieren“.

Wir freuen uns darauf, Sie bald wieder hier begrüßen zu dürfen.

Ihre SOPHISTen

————————————————–
Quellenangaben:
Requirements-Engineering und -Management, 6. Auflage, Kapitel 5

Teil 1: Ich kenn doch meine Pappenheimer!
Teil 3: Stakeholdertabellen als ein Instrument zum Dokumentieren
Teil 4: Stakeholder hegen, pflegen, gießen und ernten