Stakeholder-Management: Die verborgenen Kosten nicht abgestimmter Erwartungen

Die verborgenen Kosten nicht übereinstimmender Erwartungen

Projekte können aus technischen Gründen scheitern. Eine schlechte Architektur, schwache Umsetzung, unzureichende Tests und fragile Infrastruktur spielen alle eine Rolle. Doch viele Projekte, die wie technische Fehlschläge aussehen, begannen als Abstimmungsfehler. Verschiedene Stakeholder hatten unterschiedliche Vorstellungen von Erfolg, diese Unterschiede wurden nie ausdrücklich gemacht, und das Umsetzungsteam entwickelte schließlich auf ein Ziel hin, das sich ständig verschob.

Dies ist eines der kostspieligsten Probleme bei der Entwicklung von Produkten und Software, weil es sich oft bis spät im Prozess verbirgt. Frühe Meetings wirken produktiv. Anforderungen erscheinen vernünftig. Backlogs werden gefüllt. Sprint-Planung findet statt. Status-Updates zeigen Fortschritt. Dann nähert sich das Team der Auslieferung und stellt fest, dass Vertrieb, Betrieb, Compliance, Führungsebene, Nutzer und Engineering nicht alle dasselbe Ergebnis vor Augen hatten.

Zu diesem Zeitpunkt bemisst sich der Aufwand nicht mehr an einem unangenehmen Meeting. Er zeigt sich in Nacharbeit, verpassten Terminen, belastetem Vertrauen, ständig wechselndem Umfang, Budgetdruck und Software, die zwar technisch die schriftliche Anforderung erfüllt, aber den geschäftlichen Bedarf verfehlt.

Die Anatomie fehlender Abstimmung

Stakeholder liegen normalerweise nicht falsch damit, dass ihnen unterschiedliche Dinge wichtig sind. Eine Vertriebsleitung kann sich um Zusagen gegenüber dem Markt kümmern. Eine Entwicklungsleitung kann Wert auf technische Machbarkeit und Wartbarkeit legen. Eine Compliance-Beauftragte kann Nachvollziehbarkeit und Risiken priorisieren. Eine Betriebsleitung kann sich um Unterbrechungen der Arbeitsabläufe sorgen. Eine Finanzleitung kann Budget, Zeitplan und messbare Rendite im Blick haben.

Jede Perspektive kann berechtigt sein. Das Problem beginnt, wenn diese Perspektiven so behandelt werden, als bestünde bereits Einigkeit.

Ein Product Owner oder Projektleiter kann in einer Planungssitzung breite Zustimmung wahrnehmen und annehmen, dass Einigkeit besteht. Doch Zustimmung auf hoher Ebene ist billig. Die meisten Stakeholder können sich darauf einigen, dass ein Produkt schneller, einfacher zu bedienen, sicherer, besser integriert und bis zu einem bestimmten Datum bereit sein sollte. Die schwierige Aufgabe besteht darin, zu entscheiden, was geschieht, wenn diese Ziele miteinander konkurrieren.

Soll das Team früher mit einem kleineren Funktionsumfang ausliefern? Sollte es die Veröffentlichung verschieben, um das Betriebsrisiko zu verringern? Sollte Engineering technische Schulden eingehen, um ein Marktfenster zu erreichen? Sollten Compliance-Anforderungen die Benutzererfahrung verändern? Sollte die Anfrage eines besonders wertvollen Kunden die Roadmap-Prioritäten außer Kraft setzen?

In diesen Momenten wird Stakeholder-Management konkret. Abstimmung bedeutet nicht, Meinungen zu sammeln. Es bedeutet, konkurrierende Prioritäten in Entscheidungen zu überführen, die das Umsetzungsteam tatsächlich nutzen kann.

Tools können Arbeit nachverfolgen, aber keine Klarheit schaffen

Moderne Delivery-Teams haben keinen Mangel an Tools. Jira-Boards, Backlog-Systeme, Sprint-Rituale, Dashboards, Produkt-Roadmaps, gemeinsam genutzte Dokumente und Kollaborationsplattformen helfen Teams dabei, ihre Arbeit zu koordinieren. Sie sind nützlich. Ebenso leicht kann man sie jedoch mit tatsächlicher Abstimmung verwechseln.

Ein gut organisiertes Backlog bedeutet nicht, dass die richtige Arbeit entwickelt wird. Eine sauber formatierte User Story bedeutet nicht, dass die Anforderung klar ist. Eine Roadmap bedeutet nicht, dass Stakeholder die Zielkonflikte verstehen. Ein wöchentlicher Statusbericht bedeutet nicht, dass ungelöste Risiken bearbeitet werden.

Mike Cohens Leitlinien zu User Stories machen einen wichtigen Punkt deutlich: User Stories sollen den Fokus vom Schreiben von Anforderungen auf Gespräche über diese Anforderungen verlagern. Die schriftliche Story ist nur ein Teil der Arbeit. Der eigentliche Wert entsteht durch die Diskussion, die klärt, was der Nutzer braucht, warum es wichtig ist und woran das Team erkennt, dass die Arbeit abgeschlossen ist. [oai_citation:1‡Mountain Goat Software](https://www.mountaingoatsoftware.com/agile/user-stories?utm_source=chatgpt.com)

Wenn Organisationen ihre Umsetzung skalieren, wird das Gesprächsproblem schwieriger. Mehr Teams, mehr Stakeholder, mehr Abhängigkeiten und mehr Genehmigungsebenen schaffen mehr Möglichkeiten, dass Annahmen auseinanderdriften. Die Tools zeigen möglicherweise, was zugewiesen, in Bearbeitung oder abgeschlossen ist. Sie können jedoch nicht beweisen, dass sich alle weiterhin darüber einig sind, was Erfolg bedeutet.

Kommunikationspläne brauchen Verantwortlichkeit, Eskalation und einen festen Rhythmus

Stakeholder-Kommunikation wird häufig als eine eher weiche Aufgabe des Projektmanagements betrachtet. In der Praxis ist sie Teil der Delivery-Architektur. Wenn Kommunikationswege schlecht gestaltet sind, leidet die Qualität der Entscheidungen.

Die Leitlinien von ITU Online zu Kommunikationsplänen für Stakeholder in agilen Projekten heben mehrere praktische Bestandteile hervor, die Teams definieren müssen, darunter Zweck, Stakeholder-Gruppen, Takt, Kanäle, Verantwortlichkeit und Eskalation. Gerade die letzten drei bereiten vielen Organisationen Schwierigkeiten. [oai_citation:2‡ITU Online IT Training](https://www.ituonline.com/blogs/creating-an-effective-stakeholder-communication-plan-in-agile-projects/?utm_source=chatgpt.com)

• Verantwortlichkeit: Wer bereitet die Kommunikation vor, übermittelt sie, dokumentiert Entscheidungen und verfolgt sie nach, wenn Maßnahmen erforderlich sind?
• Eskalation: Wie werden ungelöste Blockaden, Risiken, Meinungsverschiedenheiten oder fehlende Entscheidungen an die Führungsebene herangetragen?
• Takt: Wie oft sollten Stakeholder vom Team hören, und wie sollte sich diese Häufigkeit verändern, wenn sich Umfang, Risiko oder Dringlichkeit ändern?

Die Frage der Verantwortlichkeit ist wichtig, weil „wir haben darüber gesprochen“ nicht dasselbe ist wie „wir haben eine Entscheidung getroffen“. Eine Entscheidung, die nicht festgehalten, zugewiesen und nachverfolgt wird, ist lediglich ein Gespräch im besseren Gewand.

Eskalation ist wichtig, weil ungelöste Blockaden mit der Zeit nicht günstiger werden. Teams arbeiten oft weiter, während sie auf Klarheit warten, aber Bewegung in die falsche Richtung ist kein Fortschritt. Sie ist still anwachsende Nacharbeit.

Der Takt ist wichtig, weil sich der Kommunikationsbedarf mit dem Projekt verändert. Eine risikoarme Erkundungsphase benötigt möglicherweise nur knappe Updates. Eine risikoreiche Umsetzung mit externen Abhängigkeiten, regulatorischen Risiken oder hoher Aufmerksamkeit der Führungsebene kann einen engeren Rhythmus erfordern. Ein fester Kommunikationsplan, der das Projektrisiko ignoriert, ist keine Disziplin. Er ist Gewohnheit.

Der Product Owner als Instanz für Abstimmung

Product Ownership wird häufig anhand von Vision, Backlog-Management, Zusammenarbeit mit Stakeholdern und Lieferverantwortung beschrieben. Das sind alles reale Bestandteile der Rolle. Darunter liegt jedoch eine weniger klare Verantwortung: Der Product Owner muss nutzbare Klarheit schaffen.

Das bedeutet nicht, dass der Product Owner alles bekommt, was er möchte. Es bedeutet auch nicht, dass jeder Stakeholder bei jeder Entscheidung den gleichen Einfluss erhält. Gute Product Ownership ist kein Konsensmanagement. Sie ist Entscheidungsmanagement.

Ein starker Product Owner kann widersprüchliche Beiträge berücksichtigen und dem Team dennoch eine klare Antwort geben. Was entwickeln wir jetzt? Warum ist es wichtig? Was entwickeln wir nicht? Welchen Kompromiss haben wir akzeptiert? Welches Risiko tragen wir? Was würde uns dazu veranlassen, die Richtung zu ändern?

Hier wird Stakeholder-Management zu einer Führungsaufgabe. Der Product Owner leitet nicht einfach Nachrichten zwischen Geschäftsbereich und Engineering weiter. Er hilft der Organisation, Entscheidungen zu treffen, die konkret genug sind, damit das Team sie umsetzen kann.

Die Beschreibung der Udemy-Masterclass für Product Owner spiegelt das erwartete Spektrum moderner Product Ownership wider: Vision, Strategie, Zusammenarbeit mit Stakeholdern, Backlog-Organisation und Führung in agilen und Scrum-Umgebungen. Die praktische Herausforderung besteht darin, diese Verantwortlichkeiten zusammenzuführen, wenn Prioritäten miteinander kollidieren und die Zeit knapp ist. [oai_citation:3‡Udemy](https://www.udemy.com/course/product-owner-masterclass-vision-backlogs-leadership/?srsltid=AfmBOop78in_QjgRR-5XVf8hD2mt_0LVQ6tetEC0_38ciieaTaYMiMa5&utm_source=chatgpt.com)

Entscheidungsprotokolle sind nützlicher als Status-Inszenierungen

Viele Projektteams verbringen zu viel Zeit damit, Aktivitäten zu berichten, und zu wenig damit, Entscheidungen festzuhalten. Status-Updates haben ihren Platz, lösen Abstimmungsprobleme aber selten von selbst.

Ein entscheidungsorientiertes Dokument ist etwas anderes. Es hält fest, was entschieden wurde, wer die Entscheidung getroffen hat, welche Erkenntnisse oder Einschränkungen sie geprägt haben, welche Risiken akzeptiert wurden und welche Nachverfolgung erforderlich ist. Es gibt dem Team etwas an die Hand, worauf es zurückgreifen kann, wenn Erinnerungen verblassen, Stakeholder wechseln oder alte Meinungsverschiedenheiten wieder auftauchen.

Das muss nicht bürokratisch werden. Ein schlankes Entscheidungsprotokoll kann ausreichen:

• Entscheidung getroffen
• Datum
• Verantwortliche Person für die Entscheidung
• Konsultierte Stakeholder
• Kontext und Belege
• Akzeptierte Risiken oder Zielkonflikte
• Nachfolgende Maßnahmen

Diese kleine Gewohnheit kann eine große Menge an Verwirrung verhindern. Sie schafft außerdem eine gesündere Beziehung zwischen Stakeholdern und Delivery-Teams. Anstatt immer wieder darüber zu diskutieren, woran sich die Beteiligten erinnern, kann das Team zu dem zurückkehren, was entschieden wurde und warum.

Die teuerste Fehlanpassung besteht zwischen Priorität und Kapazität

Manche Stakeholder-Probleme sind in Wirklichkeit Führungsprobleme. Das häufigste Beispiel ist die Lücke zwischen der angegebenen Priorität und der tatsächlichen Kapazität.

Die Führungsebene kann sagen, dass ein Projekt höchste Priorität hat, aber jede konkurrierende Initiative weiterlaufen lassen. Ein Stakeholder kann darauf bestehen, dass eine Funktion dringend ist, aber vermeiden, an anderer Stelle Abstriche zu machen. Eine Abteilung kann eine schnellere Bereitstellung anstreben, aber nicht die für Discovery, Tests, Genehmigungen oder den Rollout erforderlichen Mitarbeitenden bereitstellen.

Wenn das geschieht, kann Stakeholder-Management das Problem nicht einfach wie durch Zauberhand lösen. Ein Product Owner kann moderieren, Klarheit schaffen, dokumentieren und eskalieren. Er kann jedoch keine Kapazität schaffen, die die Führungsebene tatsächlich nicht zugewiesen hat.

Gutes Stakeholder-Management macht den Widerspruch früher sichtbar. Es zwingt die Organisation, unangenehme Fragen zu beantworten: Hat dies wirklich Priorität? Was sind wir bereit, nicht mehr zu tun? Wer ist befugt, den Zielkonflikt zu entscheiden? Was geschieht, wenn wir keine Entscheidung treffen?

Diese Fragen können politisch wirken, aber sie zu vermeiden ist meist teurer.

Wie Ridiculous Engineering über Stakeholder-Abstimmung denkt

Bei Ridiculous Engineering betrachten wir die Abstimmung mit Stakeholdern als eine der grundlegenden Voraussetzungen für erfolgreiche Softwarebereitstellung. Sie ist nicht von der technischen Umsetzung getrennt. Sie prägt die technische Umsetzung.

Wenn Stakeholder abgestimmt sind, können Engineering-Teams bessere Architekturentscheidungen treffen, bessere Fragen stellen, die Arbeit effektiver priorisieren und vermeiden, auf Annahmen aufzubauen, die später verworfen werden. Wenn Stakeholder nicht abgestimmt sind, wird das technische Team oft zum Ort, an dem ungelöste geschäftliche Konflikte sichtbar werden.

Deshalb legen wir Wert auf Discovery, klare Anforderungen, einen regelmäßigen Kommunikationsrhythmus, Entscheidungsprotokolle, Eskalationswege und Verantwortlichkeiten. Das mag nach Prozessdetails klingen, wirkt sich aber direkt auf die Qualität der Bereitstellung aus. Diese Faktoren bestimmen, ob ein Projekt mit einem klaren Problem, einem realistischen Umfang und einem gemeinsamen Verständnis von Erfolg in die Entwicklung startet.

Für Kunden besteht unsere Rolle häufig darin, die unsichtbaren Teile der Bereitstellung sichtbar zu machen. Wo bleiben Entscheidungen stecken? Welche Stakeholder müssen früher einbezogen werden? Bei welchen Anforderungen handelt es sich tatsächlich um ungelöste Konflikte? Wo berichtet das Team über Fortschritt, ohne Risiken zu lösen? Wo muss die Führungsebene einen Zielkonflikt entscheiden, anstatt vom Delivery-Team zu verlangen, ihn aufzufangen?

Abstimmung ist eine Disziplin der Bereitstellung

Stakeholder-Management ist nicht nur Beziehungsmanagement. Es ist eine strukturelle Disziplin, die bestimmt, ob die Investition einer Organisation in die Bereitstellung das beabsichtigte Ergebnis hervorbringt.

Organisationen, die dies gut handhaben, überlassen die Abstimmung nicht dem Zufall. Sie gestalten Kommunikationsabläufe. Sie definieren Entscheidungsbefugnisse. Sie schaffen Eskalationswege. Sie dokumentieren wichtige Entscheidungen. Sie passen den Kommunikationsrhythmus an, wenn sich Risiken verändern. Sie behandeln Klarheit für Stakeholder mit derselben Ernsthaftigkeit wie technische Architektur.

Wenn Ihre Organisation mit häufigen Änderungen am Umfang, unklaren Anforderungen, verzögerten Entscheidungen, Stakeholder-Konflikten oder Softwareprojekten zu kämpfen hat, die immer wieder am tatsächlichen geschäftlichen Bedarf vorbeigehen, kann Ridiculous Engineering helfen. Wir arbeiten mit Kunden daran, Discovery zu verbessern, Anforderungen zu klären, die Stakeholder-Kommunikation zu strukturieren und die für eine bessere Bereitstellung erforderliche Entscheidungsdisziplin zu schaffen.

Die Kosten der Abstimmung werden früh in Gesprächen, Entscheidungen und Dokumentation bezahlt. Die Kosten der Fehlanpassung werden später in Nacharbeit, Verzögerungen und verlorenem Vertrauen bezahlt. Eines davon ist deutlich günstiger als das andere.

Quellen und weiterführende Literatur: ITU Online: Einen effektiven Stakeholder-Kommunikationsplan in agilen Projekten erstellen, Mountain Goat Software: User Stories und Beispiele für User Stories, Udemy: Masterclass für Product Owner, PMI: Kommunikation mit Stakeholdern und Kunden