Veröffentlicht am

Stakeholder — von guten und von pathologischen Vertretern ihrer Zunft

Stakeholder Management ist eine der spannendsten Disziplinen im Requirements Engineering. Wenn man es mal kurz und sarkastisch formulieren will, geht es um nichts anderes als herauszufinden, wen ich wie ernst nehmen muss von den zig Leuten, die mit mir (in meiner Rolle als Requirements Autor) reden wollen.

Bei vielen davon bin ich mir natürlich sicher, dass ich ihren Input in jedem Fall ernst nehmen muss. Bei anderen wiederum weiß ich, dass sie sich nur mit nett gemeinten Hinweisen an mich wenden.

Auch die umgekehrte Frage ist spannend: Welcher Stakeholder hat sich bei mir noch gar nicht gemeldet und ich muss aktiv auf ihn zugehen?

Wie für so vieles gibt es natürlich auch hier eine Norm, die uns bei der Suche nach den Stakeholdern weiterhilft, hier ist es die DIN ISO 100006, die folgendes dazu zu sagen hat:

Stakeholder eines Projektes sind alle Personen, die ein Interesse am Projekt haben oder von ihm in irgendeiner Weise betroffen sind.

Bin ich als Requirements Manager auf der Suche nach meinen Stakeholdern — also nach denjenigen Personen oder Parteien, denen ich Einfluss auf meine Spezifikationsdokumente geben möchte, dann wähle ich meist einen Ansatz nach diesen beiden Checklisten:

Checkliste 1: Wer ist direkt betroffen von den Konsequenzen dessen, was ich spezifiziere?

Wenn es um die Spezifikation eines Software-Produkts geht, lässt sich anhand der folgenden Liste relativ schnell das Gros der Stakeholder bestimmen:

  1. Kunden: Diejenigen Organisationen, die das Produkt abnehmen werden. (Kunden werden ggf. durch Produktmanager geproxied.)
  2. Finanzier: Derjenige, der die Entwicklung des Produkts bezahlt.
  3. Anwender (Benutzer): Diejenigen Personen, die beim Kunden das Produkt verwenden werden.
  4. Entwickler: Die das Produkt entwickeln.
  5. Tester: Die das testen, was die Entwickler entwickelt haben.
  6. Betreiber: Diejenigen Personen beim Kunden, die dafür verantwortlich sind, dass das Produkt auch läuft, wenn es geliefert und installiert worden ist.
  7. Zulassung: In hoch regulierten Branchen wie Pharma, Energie, Defence, Luftfahrt, Medizintechnik o.ä. sind dies die Abteilungen, die später dafür sorgen müssen, dass das entwickelte Produkt auch in den Zielmärkten verkauft und verwendet werden darf. (In anderen Branchen gibt es diese Rolle nicht oder wenigstens nicht explizit; in wenig regulierten Branchen wird die Verantwortlichkeit für gesetzeskonforme Produkte gängigerweise vom Produktmanagement, vom Vertrieb und/oder vom Product Owner übernommen.)

Diese Liste erhebt nicht den Anspruch auf Vollständigkeit und häufig ist nicht jede Rolle explizit durch eine Person oder eine Unternehmenseinheit 1:1 hinterlegt. Des weiteren findet man natürlich Überschneidungen in den Zuständigkeiten. Im Grunde gilt aber: auf der Suche nach den legitimen Stakeholdern fährt man gut damit, sich zu überlegen, wer die o.g. Rollen einnimmt.

Ein paar der am häufigsten anzutreffenden Überschneidungen sollen hier kurz betrachtet werden:

  • Kunde und Finanzier: In Projekthäusern und Unternehmen, die auf Kundenauftrag arbeiten, ist der Finanzier immer auch gleichzeitig auch der Kunde — in klassischen Produkthäusern verantwortet jedoch meist ein interner Entscheidungsträger die Freigabe der Entwicklungskosten und diese werden erst später über den Preis des Produkts auf den Kunden umgelegt.
  • Kunde und Anwender: Ich finde es immer hilfreich zu wissen, wer denn auf Kundenseite das Produkt, das ich spezifiziere, verwenden wird — es ist in der Regel nicht derselbe, mit dem man in Gesprächen zusammen sitzt. Und was der eine gut findet, findet der andere noch lange nicht gut.
  • Entwickler und Tester: Nicht immer gibt es klar abgegrenzte Rollen, gerade in kleineren Unternehmen testen die Entwickler. Jedoch ist die Sicht auf eine Spezifikation häufig sehr unterschiedlich, jenachdem, aus welcher Warte man sie betrachtet: Manches mag einfach zu entwickeln sein — aber es ist schwierig zu testen. Bei manchem ist es anders herum.

Checkliste 2: Wer hat die Möglichkeit, das ganze vor die Wand fahren zu lassen?

Ich habe einige Male erlebt, dass bestimmte Personen zu Stakeholdern wurden, die ich bei der Betrachtung über die Checkliste 1 alleine niemals auf dem Radar gehabt hätte. Daher pflege ich in Projekten eine Liste gängiger illegitimer Stakeholder. Ich nenne sie die pathologischen Stakeholder:

  1. Betroffene zweiten Grades: Parteien, die legitimen Stakeholdern (meist: den Anwendern) direkt zusammenarbeiten und deren Befürchtung es ist, dass sich ihre Arbeitsweise ohne Abstimmung ändern wird. Zum Beispiel die Abteilung, die ab sofort nicht erst um 10 Uhr anfangen muss zu arbeiten, sondern schon um 7 Uhr, weil das neue System drei Stunden früher Output erzeugt, der dann über die Weiterberarbeitungskette auch dementsprechend früher entgegengenommen werden muss.
  2. Strategisch Betroffene: Einführungen von Produkten oder Systemen zementieren eine Unternehmensstrategie. Leitende Angestellte, die für eine andere Strategie stehen, werden ihren Unmut gerne ausleben, indem Sie versuchen, alles in ihrer Macht stehende zu tun, die ungeliebte Strategie aufzuhalten.
  3. Durch Karriereauswirkungen Betroffene: Dies hängt eng zusammen mit Punkt Nr. 2. Nicht selten ändert die Einführung von Produkten politische Einflussbereiche. Während der Fertigungsleiter mit seinen 200 Mitarbeitern vorher noch ein wichtiges Wort mitzureden hatte, ist er nach der Einführung der Automatisierung mit seinen verbleibenden 7 Mitarbeitern nur noch ein kleines Licht. Sie dürfen erwarten, dass er das nicht automatisch super findet.
  4. Durch Kompetenzverlust Betroffene: Nicht selten bedeutet die Einführung eines neues Produkts, dass ein Kompetenzaufbau geschehen muss, damit das Produkt überhaupt eingesetzt werden kann. Mitarbeiter können einfach Angst davor haben, überfordert zu sein. Solche Ängste können sich in einer Blockadehaltung niederschlagen.
  5. Trittbrettfahrer: Frisch budgetierte Projekte ziehen einen bestimmten Typ unwiderstehlich an, den Trittbrettfahrer. Auf dem kleinen Dienstweg bittet der darum, dass das Projekt (obwohl das eigentlich nicht sein Auftrag ist) bestimmte kleinere Probleme am Rande (unter der Hand) mit erledigt. Wenn das verweigert wird, dann kann es schon mal sein, dass der Trittbrettfahrer unverhohlen eine Blockadehaltung ankündigt.

Wie man mit den verschiedenen pathologischen Stakeholdern umgeht, dafür gibt es sicherlich kein Patentrezept. Es gibt einige grundsätzliche Möglichkeiten, welche Reaktionen denkbar sind. Dazu später ein weiterer Blogeintrag.

Wichtig ist in jedem Fall zu verstehen, woher bestimmte Blockaden kommen können.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.