Stakeholder – wen hole ich mit ins Boot?
In mehreren Beiträgen, etwa zum Thema Requirements Engineering, war bereits von Stakeholdern die Rede. Grund genug, diesen Begriff etwas genauer unter die Lupe zu nehmen.
Das Konzept des Stakeholders kommt nicht nur im Requirements Engineering vor, sondern beispielsweise auch in der Betriebswirtschaftslehre oder im Projektmanagement. Manchmal wird dafür auch eine andere Bezeichnung benutzt, etwa Anspruchsgruppe oder etwas Vergleichbares. Gemeint sind aber immer Personen oder auch ganze Organisationen und Gruppen, die schon während der Planungsphase Einfluss auf ein Projekt oder Produkt nehmen können, wollen oder müssen.
Stakeholder und Einflussnahme
Als Dienstleister oder Auftragnehmer könntest du es dir eigentlich recht leicht machen: Wer die Rechnung zahlt, schafft an. Sagen wir, du bekommst den Auftrag, für eine Firma ein Produkt herzustellen. Dabei soll es nun keine Rolle spielen, ob es sich um ein physisch greifbares Gadget handelt oder um neu programmierte Software. Wenn dein Kunde ein kleineres Unternehmen ist, kann es sein, dass du dafür direkt mit der Geschäftsführung persönlich sprichst. Vielleicht aber auch mit einer Abteilungsleiterin oder einem Abteilungsleiter. Doch erschöpft sich damit bereits der Pool an Leuten, mit denen du sprechen solltest? Oder, anders gesagt: Würde so ein Produkt entstehen, mit dem alle zufrieden sind und mit dem du dir einen guten Ruf erwirbst?
Vielleicht, wenn du Glück hast. Aber meistens eher nicht. Bei Firmen als Kunden kann sich ein Blick auf deren Organigramm lohnen. So kannst du einerseits feststellen, für wen du eigentlich tätig bist (im Sinne von: Wessen Auftrag erledigst du?), andererseits aber auch, für wen du tatsächlich arbeitest (im Sinne von: Wer nutzt dein Produkt eigentlich?) Diese Frage solltest du dir stellen, ehe du an der ersten Schraube drehst oder die erste Zeile Code schreibst.
Wer schafft’s an, wer badet’s aus?
Auf Basis des Organigramms kannst du zumindest einen Teil der Stakeholder erkennen, die du für die Planung und Vorbereitung ins Boot holen solltest. Dabei lassen sich idealerweise zwei Faktoren zueinander in Beziehung setzen. Einerseits, wie groß der Einfluss einer Person einer Gruppe auf die Art ist, wie das Produkt realisiert ist. Und andererseits, wer denn das fertige Produkt eigentlich nutzen wird. Daraus ergibt sich eine zweidimensionale Darstellung, deren Achsen diese beiden Faktoren abbilden.
Personen oder Gruppen, die als Stakeholder in Frage kommen, lassen sich irgendwo in dieser Darstellung platzieren. Dabei ist die vertikale Position meist recht einfach. Die Geschäftsleitung wird im Normalfall ganz oben platziert, Abteilungs- und Teamleitungen jeweils ein Stück darunter, bis hin zu den normalen Arbeitern und Angestellten. Die spannende Frage ist nun, wie die horizontale Ausrichtung aussieht, denn die bildet die Nutzung deines Produkts ab. Beispielsweise würden jene Personen oder Gruppen, die dein Produkt voraussichtlich kaum oder gar nicht nutzen, eher links positioniert, während die intensiven Anwenderinnen und Anwender nach rechts gerückt werden. Auf dieser Basis kannst du entscheiden, wie du mit den einzelnen Personen und deren Wünschen und Vorstellungen umgehst.
Natürlich wäre es kontraproduktiv, die maßgeblichen Entscheidungsträger (Geschäftsführung und Co) vor den Kopf zu stoßen, nur weil sie in der Grafik weiter links positioniert sind. Aber während der Prophet im eigenen Land nichts gilt, hast du als Externer zumindest die Möglichkeit, behutsame Einflussnahme zu versuchen. Vorausgesetzt, die beteiligten Leute hängen nicht einer autoritären Top-Down-Philosopie an, kannst du bewirken, dass auch jene gehört werden, die in der Hierarchie weiter unten stehen.
Zum Beispiel …
Das dargestellte Bild zeigt etwa die Situation, dass die Geschäftsleitung ein Produkt nicht sehr intensiv nutzen würde. Das Gleiche trifft etwa auch auf die Abteilungsleitung A zu, während die Position von Abteilungsleitung B auf zumindest geringfügige Nutzung schließen lässt. Da diese, ungeachtet der Nutzung alle einen großen Einfluss haben, sollten sie auf jeden Fall mit ins Boot geholt werden. Je nachdem, um welchen Menschenschlag es sich dabei handelt, braucht es dann möglicherweise ein gewisses Fingerspitzengefühl, was den Umgang mit ihren Wünschen und Vorstellungen angeht.
Die Teamleitung, die bereits weniger Einfluss hat, ist als vergleichsweise aktiver Nutzer eingetragen. Das kann sich bei der Planung als Glücksfall erweisen, da sie zumindest noch einen gewissen Einfluss nehmen kann. Dies ist bei den Angestellten kaum mehr der Fall. Angestellter A sollte aber als voraussichtlicher »Power User« auf jeden Fall mit ins Boot geholt werden. Guten Gewissens außen vor gelassen werden kann hingegen Angestellter B.
Außerhalb der horizontalen Achse
Damit ist die Menge an potentiellen Stakeholdern jedoch noch nicht voll ausgeschöpft. Denn auch außerhalb der waagrechten Achse kannst du fündig werden. Denn es ist möglich, dass es weitere Menschen oder Gruppierungen gibt, die zwar Einfluss auf dein Produkt nehmen können, ohne dass sich die Frage stellt, ob sie ein Produkt aktiv nutzen oder nicht.
In vielen Fällen lässt sich diese Frage nach solchen Stakeholdern durch einen Blick auf die Rechtslage klären. Gewerkschaften, Betriebsräte oder andere Arten von Arbeitnehmervertretungen können Beispiele dafür sein. Wenn dein Produkt beispielsweise in irgendeiner Art Arbeitszeiten aufzeichnet oder die Arbeitsleistung in einer anderen Form misst, wird es ohne Betriebsrat nicht gehen. Falls du ein physisches Produkt herstellst, könnten Fragen nach Ergonomie oder Gesundheit aufkommen. Damit öffnet sich die Tür für weitere Stakeholder, die nicht übergangen werden dürfen.
Indirekte Einflussnahme
Nicht bei allen Menschen oder Gruppen, die definitionsgemäß Einfluss auf ein Produkt haben, passiert dies auf unmittelbarem oder direktem Wege. Bei der Planung eines Projekts oder beim Requirements Engineering muss auch in Betracht gezogen werden, dass es indirekte Einflüsse geben kann. Bei einem physischen Produkt wird, technisch gesehen, ein Lieferant von Einzelteilen zum Stakeholder, obwohl er eigentlich gar kein Interesse daran hat. Nichtsdestotrotz ist der Einfluss auf das Ergebnis nicht zu übersehen: Ohne Lieferung gibt es kein Produkt.
Aber auch bei Software gibt es Einflüsse, die nicht notwendigerweise unter deiner direkten Kontrolle oder jener deines Kunden liegen. Beispielsweise könnte es notwendig sein, dass du etwas entwickelst, das mit einer weiteren Komponente kompatibel sein muss, die aber von Dritten stammt oder vielleicht noch gar nicht existiert. Auch ist es denkbar, dass die nötige Hardware und Architektur erst geschaffen werden muss (wo wir wieder bei den Lieferanten wären). So oder so, ergeben sich Stakeholder, die nicht ignoriert werden dürfen.
Solche indirekten oder externen Stakeholder müssen natürlich nicht bei jedem Projektmeeting dabei sein. Und schon gar nicht sind sie in der Position, Wünsche bezüglich deines Produkts zu äußern – vermutlich haben sie auch gar kein Interesse daran. Trotzdem dürfen sie nicht vergessen werden. Denn für eine vernünftige Planung ist es unerlässlich, sich auch mit ihnen abzustimmen und zu koordinieren.
Das könnte dich auch interessieren
Günter Gerstbrein
Günter Gerstbrein, Jahrgang 1977, studierte technische Mathematik an der TU Wien und war etwa 13 Jahre in der Software-Entwicklung tätig. Als „Texter, der aus der Technik kam“ ist es sein Ziel, komplizierte Sachverhalte leicht verständlich und ohne viel Techno-Babble zu vermitteln.
