6 typische Probleme im Umgang mit Stakeholdern

Ich gehe davon aus, dass du Stakeholder in deinem Projekt hast. Ich gehe auch davon aus, dass die Zusammenarbeit mit Ihnen nicht immer reibungslos ist. Zumindest ist das eine Beobachtung, die ich bei anderen Product Ownern und bei mir selbst immer wieder mache. Daher möchte ich an dieser Stelle 6 typische Probleme und mögliche Lösungen mit dir teilen. 

Vorneweg noch eine ganz kurze (und vermutlich unvollständige) Begriffsklärung: Wenn ich im Folgenden von “Stakeholdern” spreche, meine ich Führungskräfte im Unternehmen, die einen signifikanten Einfluss auf deine Produktentwicklung nehmen könnten, in der Regel die erste und zweite Führungsebene im Unternehmen. 

Los geht’s, was sind denn nun die 6 typischen Probleme? In keiner bestimmten Reihenfolge: 

1. Es gibt mehr Stakeholder, als du auf dem Radar hast 
2. Stakeholder kommunizieren nur einen Teil Ihrer Erwartungen explizit 
3. Stakeholder kennen dich nicht und vertrauen dir nicht 
4. Stakeholder haben unterschiedliche und teils widersprüchliche Anforderungen 
5. Stakeholder haben keine Zeit und sind nicht erreichbar 
6. Stakeholder arbeiten nicht mit, obwohl sie betroffen sind 

Lass uns jetzt noch tiefer einsteigen. Was genau verbirgt sich hinter diesen Überschriften und vor allem – was kannst du beim jeweiligen Problem tun? 

Es gibt mehr Stakeholder, als du auf dem Radar hast 

Normalerweise hast du einen oder zwei Sponsoren, die dein Thema überhaupt losgetreten haben. Hinzu kommen ein bis drei weitere Stakeholder, die direkt von der zukünftigen Anwendung betroffen sind. Mit diesen Menschen bist du mehr oder regelmäßig in Kontakt, du weißt, dass sie betroffen sind. 

Unter Umständen gibt es aber weitere Stakeholder, die du noch nicht auf dem Schirm hast und die dir deine Produktentwicklung gehörig durcheinander wirbeln können. Weil du die Stakeholder nicht kennst, kennst du logischerweise auch nicht ihre Wünsche, Erwartungen und Anforderungen und kannst sie nicht in der Produktentwicklung berücksichtigen. 

Ein paar Beispiele wären der Chief Information Security Officer (CISO), die Personalabteilung, die Rechtsabteilung oder der Betriebsrat. Ihr entwickelt eine grandiose Anwendung, seid kurz vor der Einführung, und dann stellt der CISO fest, dass ihr die Sicherheitsrichtlinien des Unternehmens nicht einhaltet. Schöne Scheiße. Ihr entwickelt eine formidable Erleichterung für eure Anwender und kurz vor dem Go-Live stellt der Betriebsrat fest, dass die Oberfläche mitbestimmungspflichtig sei. Ihr entwickelt eine perfekte App für eure Kunden und kurz nach der Einführung gibt es rechtliche Bedenken. The list goes on and on... 

Lass mich das explizit sagen: Die Hinweise dieser Stakeholder sind in der Regel berechtigt. Was sie so unangenehm macht, ist der Zeitpunkt. Wenn du die Hinweise oder Anforderungen von Anfang an kennst, kannst du sie auch berücksichtigen und es gibt gar keine Probleme. 

Damit liegt die Lösung des Problems auf der Hand. Du schnappst dir ein Org-Chart deines Unternehmens und gehst auf der zweiten Führungsebene quer durch. Da sind sie, deine Stakeholder. Wenn ein Thema aus Unternehmenssicht so relevant ist, dass es dafür einen Leiter gibt, dann betrifft es vermutlich auch dich. Vielleicht nicht in unbedingt in der initialen Entwicklungsphase, aber dann später in der Nutzungsphase. Vielleicht musst du nicht täglich mit allen Stakeholdern sprechen, sondern kannst die Intensität des Austauschs variieren. Wichtig ist nur, dass du niemanden vergisst, bzw. die Anforderungen, die diese Person stellen könnte.  

Um auch dies noch einmal explizit auszusprechen: Wir sind nicht bei Wünsch-Dir-Was. Du musst nicht jeden abstrusen Wunsch umsetzen. Aber die Dinge, die dein Produkt objektiv verhindern, die musst du berücksichtigen. 

Insofern: Schau dir das Org-Chart an und sei sehr vorsichtig, potenzielle Stakeholder zu früh als “nicht relevant” zu klassifizieren. 

Stakeholder kommunizieren nur einen Teil Ihrer Erwartungen explizit 

Lass es mich mal so ausdrücken: Nicht alle Stakeholder sind in der Lage, ihre Erwartungen und Anforderungen vollständig und auf einem geeigneten Abstraktionsniveau zu kommunizieren. Du hast hier die volle Bandbreite: Teilweise diskutieren sie mit dir im Detail über die Formulierung von Hinweistexten und die Position von Buttons. Teils formulieren sie derartig globalgalaktische Anforderungen, dass du getrost darauf verzichtet hättest. Und manchmal vergessen sie kritische Erwartungen. 

Zu viel oder zu wenig Detail ist zwar anstrengend in der Arbeit und Kommunikation, aber machbar. Kritisch sind die Erwartungen, die es zwar gibt, die du aber gar nicht kennst. Ignorieren ist keine Option, du hast vielleicht formal Recht, aber geändert werden muss es trotzdem. 

Insofern: fragen, ableiten, vorschlagen, zuhören. 

Deine Fragen sollten in die Zukunft gerichtet sein.  

• “Wenn unser Produkt fertig ist, wie verändert sich die Arbeit deiner Mitarbeiter?”  
• “Was geht dann einfacher / schwieriger?”  
• “Welche Arbeit fällt weg / kommt hinzu?”  
• “Welche Prozesse verändern sich wie?”  

Je konkreter du die Fragen formulierst, desto einfach wird deinem Gegenüber die Antwort fallen. Das Ziel dieser Fragen ist ja, dass sich der Stakeholder inhaltlich mit den Veränderungen befasst, die auf ihn zukommen, und mögliche Lücken selbst erkennt. 

“Ableiten” und “vorschlagen” geht in die gleiche Richtung. Du stellst dir selbst diese Fragen und versuchst, sie zu beantworten. Wenn du über Lücken oder Ungereimtheiten stolperst, sprichst du über diese Punkte mit dem Stakeholder und fragst nach seiner Einschätzung. 

Und schließlich: Spitz die Ohren! Hör genau zu! Insbesondere dann, wenn ihr gar nicht über Erwartungen oder Anforderungen sprecht. Stakeholder sprechen über dein Produkt. Sie erzählen, was sich verändert. Sie kommunizieren die Verbesserungen. Sie knüpfen ihre Zielerreichung an das Produkt. Und du hast die Gelegenheit, das Verständnis deines Stakeholders in eigenen Worten zu hören und einen Abgleich zu machen, ob du das gleiche Verständnis hast. Was meine ich damit? 

• “Die Daten aus System X werden automatisch übernommen”. Hmm... bislang ist kein Datenimport vorgesehen... 
• “Unsere Arbeitsweise ändert sich nicht”. Hmm... der Prozess und die Schnittstellen zu anderen Abteilungen verändern sich komplett... 

Wunderbare Gelegenheiten, um die Erwartungen deiner Stakeholder zu extrahieren und explizit zu formulieren. Nicht alle Erwartungen mögen in deinem Sinne sein, aber es ist besser, die Erwartungen zu kennen, als später überrascht zu werden. 

Stakeholder kennen dich nicht und vertrauen dir nicht 

Dieses Problem betrifft dich ggf. etwas mehr oder auch gar nicht, je nachdem, ob du neu im Unternehmen / in dieser Rolle / in diesem Thema bist. Ich vermute aber, dass es mindestens einen Stakeholder gibt, der dich noch nicht kennt. Daraus resultiert das niedrige Vertrauen. Das muss auch gar nicht böse gemeint sein, es entspringt schlicht der Tatsache, dass du den Stakeholder, seine Interessen, seine Probleme noch nicht kennst und daher auch nicht in seinem Interesse agieren kannst. 

Was also tun? Nun, ganz einfach, lerne ihn kennen! Sprich mit ihm. Hör zu. Finde heraus, was die Aufgaben und Ziele in seinem Bereich sind. Identifiziere die Themen, die seine volle Aufmerksamkeit haben. Die Mittel und Wege sind vielfältig... vielleicht gibt es eine formale Aufgabenbeschreibung. Vielleicht erstellst du eine Art Interviewleitfaden. Vielleicht trefft ihr euch zum Mittagessen oder Kaffeetrinken. Vielleicht nicht nur einmal, sondern regelmäßig und immer wieder.  

Hier gibt es meiner Erfahrung nach keine Abkürzung. Wenn du eine Person kennen möchtest, wenn du möchtest, dass dir eine Person vertraut, musst du Zeit investieren. Es ist allerdings eine sehr lohnenswerte Investition.  

Ach, uns wenn du mehr zum Thema Vertrauen wissen möchtest, schau dir mal die Vertrauensformel an. Ja, es gibt eine mathematische Formel für Vertrauen. Ich verlinke dir einen Beitrag. 

Stakeholder haben unterschiedliche und teils widersprüchliche Anforderungen 

Jetzt kommen wir zu einem meiner Lieblinge. Du stellst fest, dass deine Stakeholder widersprüchliche Anforderungen haben. “Der Knopf muss rot sein!” “Dieser Knopf muss blau sein!” Ja, wie denn nun? Für dich als Product Owner ist das eine knifflige Situation, weil du in die Rolle des Schiedsrichters gedrängt wirst und mindestens einer deiner Stakeholder enttäuscht sein wird. Nimm diese Rolle nicht an! 

Mach dir bewusst, dass es normal ist, dass deine Stakeholder unterschiedliche Anforderungen bzw. Prioritäten haben. Marketing braucht möglichst viele “shiny new festures”. Für den Vertrieb ist time-to-market entscheidend. Die Produktion braucht Stabilität und Verlässlichkeit. Controlling will so wenig Geld wie möglich ausgeben. Jeder dieser Stakeholder hat aus seinem Blickwinkel recht, jeder dieser Blickwinkel hat seine Berechtigung. Es geht darum, die unterschiedlichen Sichtweisen auszutarieren. 

Meiner Erfahrung nach funktioniert das am besten in einer frühen Phase der Entwicklung. Lass deine Stakeholder über Ziele, Rahmenbedingungen und Prioritäten entscheiden. Du brauchst vermutlich ein paar Tage oder Wochen, um dich in das Thema einzuarbeiten und dir eine Meinung zu bilden. Danach solltest du in der Lage sein, die kritischen Eckpunkte zu benennen und einen Vorschlag zu unterbreiten. “Wir sollten unsere Anwendung im ersten Schritt auf Nutzergruppe X fokussieren, weil...” und dann kommen von dir gute Argumente. Vermutlich trittst du damit eine Diskussion bei deinen Stakeholdern los. “Nutzer Y sind doch genauso wichtig” oder “wir müssen beides gleichzeitig machen” oder “was ist denn mit Z”. Das Schöne an Software ist, dass so gut wie alles möglich ist – aber alles auch Konsequenzen hat. Natürlich können wir alle Nutzergruppen gleichzeitig beglücken - dauert dann halt länger. Natürlich können wir eine Verfügbarkeit von 99,9999% garantieren – wird dann halt teurer. Die Stakeholder müssen Entscheidungen treffen und die Konsequenzen ihrer Entscheidungen kennen. Am Ende dieser Diskussion hast du so etwas wie ein Zielbild, einen Auftrag, Rahmenbedingungen – du kannst es nennen wie du willst. 

Danach ist das Leben für dich einfacher. Bei der nächsten Diskussion “der Knopf muss rot oder blau sein” verweist du auf die Rahmenbedingungen, aus denen man ableiten kann, dass der Knopf blau wird. Neue, großartige Ideen bewertest du an Hand der Rahmenbedingungen und nimmst sie gerne in die Entwicklung auf oder lehnst sie begründet ab. Für diese Detailentscheidungen brauchst du keine Stakeholder mehr, du kannst die jeweils richtige Entscheidung aus den Zielen und Rahmenbedingungen ableiten. 

Es ist daher entscheidend, dass deine Stakeholder untereinander ausdiskutieren, was die richtigen Ziele, Prioritäten und Rahmenbedingungen sind. An dieser Stelle müssen sich die Stakeholder einmal selbst “die Köpfe einschlagen”. Du musst sie dazu bringen, ansonsten läufst du immer von Pontius zu Pilatus und kannst es keinem recht machen. 

Stakeholder haben keine Zeit und sind nicht erreichbar 

“Ich würde ja gerne, aber meine Stakeholder haben nie Zeit!” Stimmt, das ist ein weitverbreitetes Problem. Die Kalender der meisten Stakeholder sind randvoll. Lass uns hier zwei unterschiedliche Aspekte beleuchten: eher formelle Gespräche und eher informelle Gespräche. 

Für Ersteres könntest du den Stakeholder einfach fragen, wie er am liebsten im Loop gehalten werden möchte. Möchte er zu Sprint Reviews kommen und sich dort beteiligen? Möchte er einen regelmäßigen Jour Fixe verabreden? Oder schafft er kurzfristig Platz im Kalender, wenn du Gesprächsbedarf hast? Alle Wege führen zum Ziel und ich sehe kein Problem, dass du dich nach ihm und seinen Präferenzen richtest. Ich habe übrigens noch keinen Stakeholder getroffen, der eine derartige Anfrage oder Verabredung rundheraus abgelehnt hat, die Notwendigkeit ist durchaus bewusst. 

Dann gibt es noch die informellen Gespräche, in denen du deinen Stakeholder und seine Sichtweisen und Prioritäten besser kennenlernen möchtest. Geschickterweise suchst du außerhalb des Kalenders. Die meisten Stakeholder arbeiten mehr als 9-5, also ruf sehr früh oder sehr spät an (oder geh vorbei). Ruf auf dem Handy an, falls das normale Telefon auf eine Assistenz umgeleitet ist. Ist der Stakeholder oft unterwegs, sei es auf Dienstreise oder der tägliche Weg zur Arbeit? Auch da kann man telefonieren. Schließlich machen die meisten Stakeholder auch eine Mittagspause – verabrede dich zum Essen. Du merkst, worauf ich hinaus will – sprich mit deinem Stakeholder außerhalb der üblichen Bürozeiten und richte dich ein wenig nach seinem Arbeitsrhythmus. 

Stakeholder arbeiten nicht mit, obwohl sie betroffen sind 

Manchmal versuchst du, mit deinem Produkt zentrale Probleme eines betroffenen Bereichs zu lösen. Aber ausgerechnet der betroffene Stakeholder arbeitet nicht mit. Es gäbe eine Million Dinge zu klären und zu besprechen, er müsste doch seine Vorstellungen einbringen, schließlich arbeitest du daran, SEINE Probleme zu lösen. Aber da kommt nichts. 

Normalerweise ist das kein böser Wille, sondern nur ein Anzeichen, dass eure Produktentwicklung (noch) nicht brennt, aber an anderen Stellen Feuer gelöscht werden müssen. Daher liegt die Aufmerksamkeit des Stakeholders auf den kurzfristigen und dringenden Problemen. Das kann man jetzt richtig oder falsch finden, in jedem Fall muss man mit der Situation umgehen. 

Anregung Nummer 1: Du versuchst ihn davon zu überzeugen, seine Prioritäten zu ändern. Zeig auf, welche Chancen er auf der Straße liegen lässt, wenn er sich nicht einbringt. 

Anregung Nummer 2: Du fragst, ob er eine “rechte Hand” hat, die in seinem Sinne mitarbeiten kann und sein Vertrauen hat. Wenn der Hinweis “habe ich mit Herrn Meier so abgestimmt” dazu führt, dass jede Diskussion beendet ist, dann hast du die richtige Person an Bord. 

Anregung Nummer 3: Du entscheidest als Product Owner im Sinne des Stakeholders. Oft wirst du richtig liegen, manchmal nicht. Insofern solltest du diesen Ansatz und die Konsequenzen explizit mit dem Stakeholder absprechen – du kannst schließlich keine Gedanken lesen. Dieser Ansatz funktioniert meiner Erfahrung nach immer dann gut, wenn es ein gewisses Vertrauensverhältnis gibt und wenn du fachlich in der Thematik fit bist. 

Fazit 

Wir haben jetzt über 6 typische Probleme im Umgang mit Stakeholdern gesprochen. Vielleicht hast du dich in der einen oder anderen Situation wiedergefunden. Vielleicht hast du die eine oder andere Anregung mitgenommen, was du tun kannst. Vermutlich habe ich eine ganze Reihe von Problemen nicht adressiert. Teile gerne deine Sichtweise und deine Erfahrungen. 

Du merkst aber, dass Stakeholder Management echt Arbeit ist und du echte Zeit investieren musst. Ja, das ist so. Aber es lohnt sich. Ein gutes, vertrauensvolles Verhältnis zu deinen Stakeholdern erleichtert euch die Arbeit ungemein. Die Kenntnis über die Zeile und Erwartungen vermeidet unangenehme Überraschungen und hektische Nacharbeiten.