Stakeholder-Management in der IT: So bringst du Fachbereiche, Management und Entwickler zusammen

Ein IT-Projekt beginnt häufig mit einer scheinbar einfachen Aufgabe: Eine neue Software soll eingeführt, ein bestehender Geschäftsprozess optimiert oder eine Anwendung um zusätzliche Funktionen erweitert werden. Das Management erwartet einen wirtschaftlichen Nutzen, der Fachbereich möchte seine täglichen Probleme lösen, die IT benötigt eine technisch tragfähige Umsetzung und die Anwender wünschen sich eine Lösung, die ihre Arbeit tatsächlich erleichtert.

Wenn alle dasselbe wollen, aber jeder etwas anderes meint

Auf den ersten Blick verfolgen alle Beteiligten dasselbe Ziel. Schließlich möchten sie eine erfolgreiche Lösung. In der Praxis zeigt sich jedoch schnell, dass jeder Erfolg anders definiert. Während das Management möglichst rasch messbare Ergebnisse sehen möchte, legt der Fachbereich Wert auf einen möglichst großen Funktionsumfang. Die IT achtet auf Architektur, Sicherheit, Wartbarkeit und verfügbare Kapazitäten. Die Anwender wiederum interessiert vor allem, ob sie ihre Aufgaben anschließend einfacher erledigen können.

Genau an dieser Stelle entscheidet sich häufig, ob ein Vorhaben erfolgreich wird oder in endlosen Abstimmungen, gegenseitigen Vorwürfen und immer neuen Anforderungen versandet. Nicht unbedingt, weil die Beteiligten unfähig wären, sondern weil ihre unterschiedlichen Perspektiven nicht systematisch zusammengeführt werden.

Erfolgreiches Stakeholder-Management bedeutet deshalb nicht, es allen recht zu machen. Es bedeutet, unterschiedliche Interessen sichtbar zu machen, Zielkonflikte konstruktiv zu bearbeiten und tragfähige Entscheidungen herbeizuführen.

Für Product Owner, Business Engineers, IT-Projektverantwortliche und Requirements Engineers gehört diese Fähigkeit zu den entscheidenden Kompetenzen. Sie verbindet fachliches Verständnis, analytisches Denken, Kommunikation und unternehmerische Verantwortung.

Was Stakeholder-Management wirklich bedeutet

Stakeholder sind Personen, Gruppen oder Organisationen, die ein Vorhaben beeinflussen können, von ihm betroffen sind oder ein berechtigtes Interesse an seinem Ergebnis haben. Im IT-Umfeld reicht das Spektrum von der Geschäftsführung über Fachbereiche und Entwicklungsteams bis hin zu Anwendern, Informationssicherheit, Datenschutz, Einkauf und externen Dienstleistern.

Stakeholder-Management umfasst die systematische Identifikation dieser Beteiligten, die Analyse ihrer Interessen und Erwartungen, die Gestaltung der Kommunikation sowie den Umgang mit Konflikten und Veränderungen. Ziel ist es, die relevanten Personen angemessen einzubinden und sicherzustellen, dass Entscheidungen auf einer möglichst belastbaren Grundlage getroffen werden.

Dabei geht es ausdrücklich nicht darum, sämtliche Wünsche zu erfüllen. Das wäre in vielen Organisationen schon deshalb unmöglich, weil Interessen miteinander konkurrieren. Ein Fachbereich möchte eine zusätzliche Funktion, das Management will das Budget begrenzen und die IT muss gleichzeitig technische Risiken reduzieren. Erfolgreiches Stakeholder-Management macht solche Widersprüche transparent und hilft dabei, sie nachvollziehbar aufzulösen.

Stakeholder sind nicht automatisch Auftraggeber

Ein häufiger Fehler besteht darin, Stakeholder mit Auftraggebern gleichzusetzen. Tatsächlich können auch Personen ohne formale Entscheidungsbefugnis erheblichen Einfluss auf den Erfolg eines Projekts haben.

Ein erfahrener Mitarbeiter kennt beispielsweise zahlreiche Besonderheiten eines Geschäftsprozesses. Werden diese bei der Entwicklung einer neuen Anwendung ignoriert, kann das Ergebnis trotz einer formal korrekten Umsetzung am betrieblichen Alltag scheitern. Umgekehrt kann ein Sicherheitsverantwortlicher eine Lösung verhindern, wenn wesentliche Risiken ungeklärt bleiben.

Deshalb reicht es nicht, lediglich die Personen zu berücksichtigen, die ein Projekt offiziell beauftragen. Entscheidend ist, wer relevante Informationen besitzt, Entscheidungen beeinflusst, die Umsetzung ermöglicht oder durch das Ergebnis wesentlich betroffen ist.

Ein guter Stakeholder-Ansatz berücksichtigt sowohl die formale Organisationsstruktur als auch die tatsächlichen Einflussverhältnisse. Erst aus dieser Kombination entsteht ein realistisches Bild der Organisation.

Warum unterschiedliche Interessen ganz normal sind

Konflikte zwischen Stakeholdern werden häufig als persönliches Problem interpretiert. Dabei sind unterschiedliche Interessen zunächst ein normaler Bestandteil arbeitsteiliger Organisationen.

Ein Fachbereich wird beispielsweise an der Qualität und Geschwindigkeit seiner operativen Arbeit gemessen. Die IT muss dagegen unter anderem Stabilität, Sicherheit, Wartbarkeit und Betriebskosten berücksichtigen. Beide Seiten können daher zu unterschiedlichen Schlussfolgerungen gelangen, obwohl sie jeweils nachvollziehbare Ziele verfolgen.

Problematisch wird es erst dann, wenn diese unterschiedlichen Ziele nicht transparent sind oder wenn die Beteiligten versuchen, ihre Interessen ohne gemeinsame Entscheidungsgrundlage durchzusetzen.

Beispiel: Der Fachbereich benötigt eine neue Funktion

Ein Fachbereich fordert eine zusätzliche Funktion in einer bestehenden Geschäftsanwendung. Die Funktion soll einen manuellen Arbeitsschritt beseitigen und dadurch Zeit sparen. Der Product Owner bewertet die Anforderung zunächst als sinnvoll.

Bei der technischen Analyse stellt sich jedoch heraus, dass die Umsetzung mehrere Schnittstellen betrifft, zusätzliche Berechtigungen erforderlich macht und umfangreiche Tests benötigt. Gleichzeitig arbeiten die Entwickler an einer anderen Funktion, die für einen strategisch wichtigen Prozess benötigt wird.

Der Fachbereich erwartet eine kurzfristige Umsetzung. Die IT empfiehlt, zunächst die bestehende Schnittstellenarchitektur zu verbessern. Das Management wiederum möchte innerhalb des laufenden Quartals erste Einsparungen nachweisen.

Alle drei Positionen können sachlich begründet sein. Eine erfolgreiche Lösung entsteht deshalb nicht dadurch, dass eine Seite ihren Willen durchsetzt. Sie entsteht, wenn die Beteiligten die jeweiligen Auswirkungen verstehen und anhand gemeinsamer Kriterien eine Entscheidung treffen.

Möglicherweise ist eine vereinfachte Zwischenlösung sinnvoll. Vielleicht lässt sich der manuelle Arbeitsschritt vorübergehend durch einen standardisierten Prozess reduzieren. Oder die Funktion wird umgesetzt, während eine andere Anforderung zurückgestellt wird.

Welche Variante richtig ist, hängt vom konkreten Kontext ab. Entscheidend ist, dass die Wahl bewusst und nachvollziehbar getroffen wird.

Die Stakeholder-Analyse: Erst verstehen, dann kommunizieren

Bevor ein Product Owner oder Business Engineer eine Lösung entwickelt, sollte er wissen, mit wem er es zu tun hat. Das klingt selbstverständlich, wird im Alltag aber häufig auf eine Teilnehmerliste für das nächste Meeting reduziert.

Eine fundierte Stakeholder-Analyse untersucht dagegen die Interessen, Erwartungen, Einflussmöglichkeiten und möglichen Auswirkungen eines Vorhabens. Sie schafft damit eine Grundlage für die weitere Zusammenarbeit.

Schritt 1: Relevante Stakeholder identifizieren

Im ersten Schritt werden alle Personen und Gruppen erfasst, die für das Vorhaben wichtig sein könnten. Dabei hilft es, die Organisation aus unterschiedlichen Perspektiven zu betrachten.

Auf der Managementebene sind beispielsweise Geschäftsziele, Budget, Risiken und strategische Prioritäten relevant. Fachbereiche interessieren sich für Prozessqualität, Funktionsumfang und operative Effizienz. Die IT betrachtet Architektur, Integrationsaufwand, Sicherheit und Wartbarkeit. Anwender können wiederum wertvolle Informationen über tatsächliche Arbeitsabläufe und wiederkehrende Probleme liefern.

Je nach Vorhaben kommen weitere Beteiligte hinzu. Dazu gehören Datenschutz, Informationssicherheit, Einkauf, Recht, Betriebsrat, externe Dienstleister oder andere technische Teams.

Wichtig ist, nicht automatisch alle Beteiligten in jede Entscheidung einzubeziehen. Eine möglichst vollständige Identifikation dient zunächst dazu, relevante Perspektiven nicht zu übersehen. Der tatsächliche Einbindungsgrad wird anschließend festgelegt.

Schritt 2: Interessen und Erwartungen verstehen

Im nächsten Schritt wird untersucht, was die jeweiligen Stakeholder erreichen möchten und welche Befürchtungen sie mit dem Vorhaben verbinden.

Ein Fachbereich könnte beispielsweise eine neue Software fordern, weil ein bestehender Prozess zu viel manuelle Arbeit verursacht. Ein IT-Team könnte die Einführung kritisch beurteilen, weil bereits mehrere Anwendungen mit ähnlichen Funktionen vorhanden sind. Das Management möchte möglicherweise die Kosten reduzieren, während die Anwender vor allem eine einfachere Bedienung erwarten.

Die Kunst besteht darin, hinter einer konkreten Forderung das zugrunde liegende Bedürfnis zu erkennen.

Wenn ein Fachbereich eine zusätzliche Anwendung verlangt, bedeutet das nicht zwangsläufig, dass er genau diese Software benötigt. Vielleicht fehlt ihm lediglich eine Funktion, die bereits in einer bestehenden Plattform verfügbar ist. Möglicherweise lässt sich das eigentliche Problem sogar durch eine Prozessänderung lösen.

Wer nur Forderungen sammelt, verwaltet Wünsche. Wer ihre Ursachen versteht, kann bessere Lösungen entwickeln.

Schritt 3: Einfluss und Betroffenheit bewerten

Nicht jeder Stakeholder benötigt dieselbe Aufmerksamkeit. Eine Person kann stark vom Ergebnis betroffen sein, aber nur begrenzten formalen Einfluss besitzen. Eine andere kann wesentliche Entscheidungen treffen, ohne täglich mit der Anwendung zu arbeiten.

Zur strukturierten Bewertung eignet sich eine einfache Matrix mit zwei Dimensionen:

Diese Einordnung ist bewusst nur ein Ausgangspunkt. Die tatsächlichen Verhältnisse unterscheiden sich von Unternehmen zu Unternehmen. Auch kann ein einzelner Stakeholder mehrere Rollen einnehmen.

Die Matrix sollte deshalb nicht als starre Klassifizierung verstanden werden. Sie ist ein Arbeitsinstrument, das bei Bedarf aktualisiert wird.

Kommunikation ist keine Informationsverteilung

Eine der häufigsten Fehlannahmen im Projektmanagement lautet, dass Stakeholder ausreichend eingebunden seien, sobald sie regelmäßig Statusberichte erhalten.

Information ist jedoch nicht dasselbe wie Verständigung. Ein Bericht kann korrekt sein und trotzdem die entscheidende Frage unbeantwortet lassen: Welche Konsequenz ergibt sich aus den dargestellten Informationen?

Das Management benötigt möglicherweise eine Entscheidung über zusätzliche Ressourcen. Ein Entwicklerteam muss wissen, welche Anforderung Vorrang hat. Ein Fachbereich muss verstehen, warum eine gewünschte Funktion nicht sofort umgesetzt wird.

Die Kommunikation sollte deshalb an den tatsächlichen Aufgaben und Entscheidungen der jeweiligen Empfänger ausgerichtet werden.

Kommunikation an die jeweilige Zielgruppe anpassen

Eine technische Architekturentscheidung muss nicht für jeden Stakeholder in allen Details erläutert werden. Umgekehrt reicht eine Aussage wie „Die Umsetzung ist technisch zu komplex“ nicht aus, wenn ein Fachbereich verstehen soll, warum sich ein gewünschter Nutzen verzögert.

Ein Business Engineer muss technische Sachverhalte deshalb in betriebliche Auswirkungen übersetzen können. Statt lediglich auf einen hohen Implementierungsaufwand hinzuweisen, kann er beispielsweise erklären, dass eine Änderung mehrere Schnittstellen betrifft, zusätzliche Tests benötigt und dadurch die geplante Bereitstellung einer anderen Funktion gefährdet.

Damit wird aus einer technischen Einschätzung eine nachvollziehbare Entscheidungsgrundlage.

Gleichzeitig muss die Kommunikation in die andere Richtung funktionieren. Geschäftsziele und fachliche Anforderungen sollten so konkret formuliert werden, dass technische Teams deren Zweck, Priorität und Erfolgskriterien verstehen.

Gute Kommunikation bedeutet somit nicht, jede Information für alle gleich aufzubereiten. Sie bedeutet, die richtigen Informationen in der richtigen Form bereitzustellen.

Verbindlichkeit statt endloser Abstimmung

Kommunikation verliert ihren Wert, wenn unklar bleibt, was aus einem Gespräch folgt. Deshalb sollten wichtige Abstimmungen mit konkreten Ergebnissen enden.

Dazu gehören insbesondere die getroffenen Entscheidungen, offene Fragen, Verantwortlichkeiten und vereinbarten nächsten Schritte. Ebenso wichtig ist die Unterscheidung zwischen einer verbindlichen Entscheidung, einer vorläufigen Einschätzung und einer noch offenen Hypothese.

Ein kurzes Entscheidungsprotokoll kann dafür ausreichen. Es sollte die Entscheidung, ihre wesentliche Begründung, den Verantwortlichen und gegebenenfalls die noch bestehenden Risiken festhalten.

Das schafft Transparenz und reduziert spätere Diskussionen darüber, was angeblich vereinbart wurde. Außerdem ermöglicht es neuen Beteiligten, den Entscheidungsverlauf nachzuvollziehen.

Konflikte konstruktiv lösen, statt sie zu vermeiden

Konflikte lassen sich in komplexen IT-Vorhaben nicht vollständig verhindern. Sie sind auch nicht grundsätzlich negativ. Unterschiedliche Perspektiven können dazu beitragen, Risiken früher zu erkennen und bessere Entscheidungen zu treffen.

Problematisch werden Konflikte vor allem dann, wenn sie persönlich werden, wichtige Informationen zurückgehalten werden oder Entscheidungen dauerhaft blockiert bleiben.

Ein professioneller Umgang beginnt deshalb mit einer klaren Trennung zwischen Personen, Positionen und Interessen.

Positionen hinterfragen, Interessen erkennen

Angenommen, ein Fachbereich fordert die Einführung einer bestimmten Software. Die IT lehnt die Lösung ab, weil bereits eine ähnliche Plattform vorhanden ist.

Die Positionen sind zunächst eindeutig: Der Fachbereich möchte die neue Software, die IT möchte sie nicht einführen.

Die eigentlichen Interessen können jedoch ganz anders aussehen. Der Fachbereich benötigt vielleicht eine einfache Möglichkeit, gemeinsam an Konzepten zu arbeiten. Die IT möchte zusätzliche Lizenzkosten, neue Schnittstellen und weitere Sicherheitsprüfungen vermeiden.

Sobald diese Interessen sichtbar werden, entstehen neue Lösungsoptionen. Vielleicht reicht eine bereits vorhandene Funktion aus. Vielleicht ist die vorhandene Plattform für den konkreten Anwendungsfall tatsächlich ungeeignet. Möglicherweise lässt sich die zusätzliche Software unter klar definierten Bedingungen sinnvoll integrieren.

Die entscheidende Frage lautet daher nicht nur, welche Seite recht hat. Sie lautet: Welche Lösung erfüllt die wesentlichen Anforderungen bei vertretbaren Kosten und Risiken?

Sachliche Kriterien statt persönlicher Überzeugung

Damit Konflikte nicht von Hierarchie, Lautstärke oder persönlicher Durchsetzungsfähigkeit entschieden werden, benötigen die Beteiligten nachvollziehbare Bewertungskriterien.

Für eine Softwareentscheidung können dies beispielsweise sein:

• Fachlicher Nutzen und tatsächliche Anwenderbedürfnisse
• Einführungs- und Betriebskosten
• Integrationsaufwand und technische Machbarkeit
• Sicherheits- und Datenschutzanforderungen
• Wartbarkeit und langfristige Weiterentwicklung
• Verfügbarkeit von Ressourcen
• Strategische Bedeutung und zeitliche Dringlichkeit

Nicht jedes Kriterium muss gleich gewichtet werden. Bei sicherheitskritischen Vorhaben können bestimmte Anforderungen zwingend sein. Bei anderen Entscheidungen steht möglicherweise der kurzfristige Geschäftsnutzen im Vordergrund.

Wichtig ist, dass die Kriterien vor der abschließenden Bewertung transparent gemacht werden und nicht nachträglich so verändert werden, dass eine bereits bevorzugte Lösung gewinnt.

Wenn keine Einigung möglich ist

Nicht jeder Konflikt lässt sich durch bessere Kommunikation auflösen. Manchmal stehen Interessen tatsächlich im Widerspruch, oder die Beteiligten verfügen nicht über die notwendige Entscheidungsbefugnis.

In solchen Fällen sollte die offene Entscheidung strukturiert eskaliert werden.

Eine gute Eskalation ist keine persönliche Beschwerde. Sie beschreibt das Problem, stellt die verfügbaren Optionen gegenüber, erläutert deren Auswirkungen und benennt die erforderliche Entscheidung.

Beispielsweise könnte ein Product Owner darlegen, dass innerhalb der vorhandenen Kapazitäten entweder eine sicherheitsrelevante Verbesserung oder eine neue fachliche Funktion umgesetzt werden kann, aber nicht beides im gewünschten Zeitraum.

Die Entscheidung über eine zusätzliche Finanzierung, eine Verschiebung oder eine veränderte Priorisierung gehört dann an die Stelle, die über die entsprechenden Befugnisse verfügt.

Professionelles Stakeholder-Management bedeutet auch, zu erkennen, wann eine Entscheidung nicht mehr auf der eigenen Ebene getroffen werden kann.

Priorisierung: Warum nicht jede Anforderung gleich wichtig ist

Eine der anspruchsvollsten Aufgaben an der Schnittstelle zwischen Fachbereich, Management und IT ist die Priorisierung konkurrierender Anforderungen. In vielen Organisationen werden Wünsche zunächst gesammelt und anschließend nach Dringlichkeit sortiert. Das Problem dabei ist, dass fast jeder Stakeholder seine eigene Anforderung für besonders wichtig hält. Wenn alle Anforderungen als dringend bezeichnet werden, entsteht daraus noch keine sinnvolle Reihenfolge.

Eine belastbare Priorisierung benötigt deshalb gemeinsame Kriterien und eine klare Vorstellung davon, welchen Beitrag eine Anforderung zu den Unternehmenszielen leistet.

Eine nachvollziehbare Bewertungsmethode entwickeln

Ein pragmatisches Modell kann Anforderungen anhand von fünf Kriterien bewerten:

Für jedes Kriterium kann eine Skala verwendet werden, beispielsweise von eins bis fünf. Die Kriterien können anschließend gewichtet werden, sofern die Gewichtung nachvollziehbar festgelegt wurde.

Ein solcher Score ist allerdings keine objektive Wahrheit. Er strukturiert die Diskussion und macht Annahmen sichtbar. Er ersetzt weder fachliches Urteilsvermögen noch notwendige Sicherheits- oder Compliance-Prüfungen.

Besonders wichtig ist, die Ergebnisse nicht mechanisch zu interpretieren. Eine regulatorisch zwingende Maßnahme darf beispielsweise nicht allein deshalb zurückgestellt werden, weil sie bei einer allgemeinen Nutzenbewertung weniger Punkte erzielt als eine neue Komfortfunktion.

Priorisierung braucht Entscheidungsbefugnisse

Auch die beste Bewertungsmethode hilft wenig, wenn niemand verbindlich entscheiden darf. Deshalb sollte geklärt sein, wer Anforderungen priorisiert, wer über Budgets entscheidet und wer bei Zielkonflikten zwischen Geschäftsbereichen vermittelt.

Der Product Owner verantwortet beispielsweise im Scrum-Kontext die Wertmaximierung des Produkts und die wirksame Verwaltung des Product Backlogs. Daraus folgt jedoch nicht automatisch, dass er sämtliche Budget-, Personal- oder Sicherheitsentscheidungen eines Unternehmens allein treffen darf.

Die tatsächlichen Entscheidungsbefugnisse hängen von der Organisation und dem jeweiligen Mandat ab.

Ein professioneller Ansatz macht diese Grenzen transparent. Er schafft Klarheit darüber, welche Entscheidungen selbstständig getroffen werden können und wann andere Verantwortliche eingebunden werden müssen.

Stakeholder-Management im agilen Umfeld

Agile Arbeitsweisen verändern die Zusammenarbeit zwischen Stakeholdern und Entwicklungsteams. Sie beseitigen unterschiedliche Interessen jedoch nicht, im Gegenteil. Wenn Anforderungen schrittweise entwickelt und regelmäßig überprüft werden, benötigen die Beteiligten einen verlässlichen Austausch über Ziele, Prioritäten und neue Erkenntnisse. Ein Product Owner muss dabei insbesondere sicherstellen, dass das Team die fachlichen Zusammenhänge versteht und Rückmeldungen aus dem Geschäft in die Produktentwicklung einfließen können.

Product Owner als Vermittler zwischen Geschäft und Umsetzung

Der Product Owner ist nicht einfach der Postbote zwischen Fachbereich und Entwicklungsteam. Seine Aufgabe besteht darin, Produktziele zu vermitteln, Anforderungen zu strukturieren und Prioritäten so festzulegen, dass das Team an den wichtigsten Themen arbeitet.

Dazu gehört auch, Erwartungen zu korrigieren. Wenn eine Anforderung nicht den erwarteten Nutzen erzeugt oder erhebliche Risiken mit sich bringt, muss der Product Owner diese Erkenntnisse in die Entscheidungsfindung einbringen.

Gleichzeitig muss er die technischen Einschätzungen des Teams ernst nehmen. Eine fachlich attraktive Idee ist noch keine gute Produktentscheidung, wenn ihre Umsetzung unverhältnismäßig teuer wäre oder die langfristige Weiterentwicklung erheblich erschweren würde.

Gute Zusammenarbeit entsteht deshalb nicht dadurch, dass eine Seite der anderen Vorgaben macht. Sie entsteht durch ein gemeinsames Verständnis der Ziele und eine transparente Abwägung der Möglichkeiten.

Regelmäßiges Feedback statt Überraschungen am Projektende

Ein weiterer Vorteil agiler Arbeitsweisen besteht darin, dass Ergebnisse frühzeitig überprüft werden können. Anstatt monatelang im Verborgenen zu entwickeln und erst am Ende eine fertige Lösung vorzustellen, können Teams schrittweise nutzbare Ergebnisse präsentieren. Stakeholder erhalten dadurch die Möglichkeit, Annahmen zu überprüfen und frühzeitig auf neue Erkenntnisse zu reagieren.

Das funktioniert allerdings nur, wenn Feedback gezielt eingeholt wird und die Beteiligten wissen, welche Entscheidungen tatsächlich offen sind.

Eine Demonstration sollte deshalb nicht ausschließlich dazu dienen, Fortschritt zu präsentieren. Sie sollte auch klären, ob das Ergebnis die erwarteten Anforderungen erfüllt, welche Erkenntnisse sich daraus ergeben und welche Anpassungen erforderlich sind.

So wird Stakeholder-Management zu einem kontinuierlichen Bestandteil der Produktentwicklung und nicht zu einer zusätzlichen Verwaltungsaufgabe.

Anforderungen, Erwartungen und Entscheidungen sauber dokumentieren

Dokumentation wird häufig als lästige Begleiterscheinung von Projekten betrachtet. Dabei kann sie ein wesentliches Instrument für die Zusammenarbeit sein.

Wenn Anforderungen, Annahmen und Entscheidungen nicht nachvollziehbar festgehalten werden, entstehen leicht unterschiedliche Erinnerungen an frühere Gespräche. Besonders problematisch ist das, wenn sich Beteiligte ändern oder ein Vorhaben über einen längeren Zeitraum läuft.

Eine gute Dokumentation muss allerdings nicht umfangreich sein. Entscheidend ist, dass sie die Informationen enthält, die für die Zusammenarbeit und spätere Entscheidungen tatsächlich benötigt werden.

Was dokumentiert werden sollte

Bei relevanten Entscheidungen sollten mindestens folgende Informationen nachvollziehbar sein:

• Welche Frage musste entschieden werden?
• Welche Lösungsoptionen wurden betrachtet?
• Welche Kriterien waren ausschlaggebend?
• Welche Entscheidung wurde getroffen?
• Wer war für die Entscheidung verantwortlich?
• Welche Annahmen und Risiken bestehen weiterhin?
• Welche nächsten Schritte wurden vereinbart?

Für Anforderungen sind zusätzlich der fachliche Hintergrund, der erwartete Nutzen, die Akzeptanzkriterien und gegebenenfalls Abhängigkeiten wichtig.

Nicht jede Diskussion muss vollständig protokolliert werden. Eine Dokumentation sollte den Entscheidungsverlauf verständlich machen, ohne die Organisation mit unnötigem Formalismus zu belasten.

Auch hier gilt: Der Umfang sollte sich am Risiko, an der Komplexität und an den Anforderungen des jeweiligen Vorhabens orientieren.

Typische Fehler im Stakeholder-Management

Selbst erfahrene Fachkräfte können in wiederkehrende Muster geraten, die die Zusammenarbeit erschweren.

Fehler 1: Allen Beteiligten alles versprechen

Wer versucht, jede Erwartung zu erfüllen, erzeugt häufig unrealistische Zusagen. Spätestens wenn Zeit, Budget und Ressourcen nicht ausreichen, müssen diese Versprechen zurückgenommen werden.

Besser ist es, frühzeitig transparent zu machen, welche Optionen bestehen und welche Konsequenzen mit den jeweiligen Entscheidungen verbunden sind.

Fehler 2: Die lauteste Stimme mit der höchsten Priorität verwechseln

Eine besonders dominante Person kann Meetings beherrschen und ihre Anforderungen regelmäßig nach vorne bringen. Das bedeutet aber nicht, dass diese Anforderungen den größten Geschäftsnutzen erzeugen.

Eine nachvollziehbare Priorisierung schafft hier einen sachlichen Gegenpol. Sie stellt sicher, dass auch weniger durchsetzungsstarke Stakeholder gehört werden und wichtige Anforderungen nicht untergehen.

Fehler 3: Die Anwender zu spät einbeziehen

Wenn eine Lösung bereits weitgehend entwickelt wurde, bevor die späteren Nutzer sie ausprobieren können, werden grundlegende Probleme häufig erst spät erkannt.

Frühe Interviews, Prozessbeobachtungen, Prototypen und Tests helfen dabei, Annahmen zu überprüfen, bevor hohe Umsetzungskosten entstehen.

Fehler 4: Konflikte vermeiden, bis sie eskalieren

Nicht angesprochene Zielkonflikte verschwinden selten von selbst. Sie zeigen sich später als Verzögerungen, unerwartete Zusatzanforderungen oder gegenseitige Schuldzuweisungen.

Besser ist es, unterschiedliche Interessen frühzeitig offenzulegen und gemeinsam nach tragfähigen Lösungen zu suchen.

Fehler 5: Entscheidungen ohne klare Verantwortlichkeit treffen

Wenn nicht feststeht, wer entscheiden darf, werden Fragen immer wieder diskutiert, ohne dass sich etwas bewegt.

Deshalb müssen Rollen, Verantwortlichkeiten und Eskalationswege geklärt sein. Eine Diskussion kann noch so konstruktiv verlaufen: Ohne eine verbindliche Entscheidung bleibt sie häufig folgenlos.

Fehler 6: Kommunikation mit Zustimmung verwechseln

Ein Stakeholder, der eine Präsentation erhalten oder an einem Meeting teilgenommen hat, muss die Entscheidung nicht automatisch verstanden oder akzeptiert haben.

Es lohnt sich deshalb, wichtige Entscheidungen aktiv zu erläutern und Rückfragen zu ermöglichen. Dabei geht es nicht darum, jede Entscheidung nachträglich zur Abstimmung zu stellen, sondern um ein gemeinsames Verständnis der Gründe und Konsequenzen.

10. Erfolg messen: Woran erkennt man gutes Stakeholder-Management?

Stakeholder-Management wird häufig als weicher Erfolgsfaktor betrachtet. Tatsächlich lassen sich einige seiner Auswirkungen anhand konkreter Beobachtungen und Kennzahlen untersuchen.

Allerdings gibt es keine einzelne Kennzahl, die zuverlässig beweist, dass Stakeholder-Management gut funktioniert. Ergebnisse hängen immer auch von der Komplexität des Vorhabens, der Qualität der technischen Umsetzung und den organisatorischen Rahmenbedingungen ab.

Sinnvoll ist deshalb eine Kombination aus Prozessindikatoren, Ergebniskennzahlen und qualitativen Rückmeldungen.

Mögliche Kennzahlen und Beobachtungspunkte

Entscheidungsdauer: Wie lange benötigen wesentliche Entscheidungen vom Zeitpunkt der vollständigen Entscheidungsgrundlage bis zur verbindlichen Festlegung? Eine sinkende Dauer kann auf bessere Entscheidungsprozesse hindeuten. Sie darf allerdings nicht dadurch erkauft werden, dass notwendige Prüfungen übersprungen werden.

Anforderungsänderungen: Wie häufig müssen bereits abgestimmte Anforderungen nachträglich wesentlich verändert werden? Viele Änderungen können auf unklare Anforderungen oder fehlende Abstimmung hinweisen. Sie können aber auch das Ergebnis sinnvoller neuer Erkenntnisse sein und sind deshalb nicht automatisch negativ.

Nacharbeit: Wie viel Aufwand entsteht, weil Ergebnisse die tatsächlichen fachlichen Erwartungen nicht erfüllen? Eine systematische Auswertung kann zeigen, ob Anforderungen ausreichend verstanden und frühzeitig überprüft werden.

Stakeholder-Zufriedenheit: Wie bewerten die relevanten Beteiligten Transparenz, Zusammenarbeit und Nachvollziehbarkeit der Entscheidungen? Kurze, regelmäßig durchgeführte Befragungen können Verbesserungsmöglichkeiten sichtbar machen.

Nutzung und Geschäftsergebnis: Werden eingeführte Lösungen tatsächlich verwendet? Verbessern sich die relevanten Prozesse? Hier zeigt sich, ob die Zusammenarbeit zu einem Ergebnis geführt hat, das über die reine Fertigstellung einer Software hinausgeht.

Die Kennzahlen sollten nicht isoliert betrachtet werden. Eine sinkende Zahl von Anforderungsänderungen ist beispielsweise wenig wertvoll, wenn gleichzeitig wichtige Anwenderbedürfnisse ignoriert werden.

Ziel ist nicht, möglichst schöne Projektberichte zu erzeugen. Ziel ist, die Qualität der Zusammenarbeit und der daraus entstehenden Entscheidungen zu verbessern.

Die praktische Umsetzung: Ein Stakeholder-Management-Plan in sieben Schritten

Wer Stakeholder-Management im Arbeitsalltag verbessern möchte, benötigt kein umfangreiches Handbuch. Ein überschaubarer, regelmäßig überprüfter Plan reicht für viele Vorhaben aus.

Schritt 1: Ziel und Entscheidungsbedarf definieren. Beschreibe, welches Problem gelöst werden soll, welches Ergebnis erwartet wird und welche wesentlichen Entscheidungen anstehen.

Schritt 2: Stakeholder erfassen. Identifiziere relevante Personen und Gruppen, ihre Rollen sowie ihre mögliche Bedeutung für den Projekterfolg.

Schritt 3: Interessen und Erwartungen analysieren. Kläre, welche Ziele, Bedürfnisse, Risiken und Befürchtungen die Beteiligten haben. Unterscheide dabei zwischen ausdrücklich genannten Forderungen und den dahinterliegenden Interessen.

Schritt 4: Entscheidungsbefugnisse festlegen. Bestimme, wer fachliche Prioritäten festlegt, wer technische Entscheidungen verantwortet, wer Budgets freigibt und wann eine Eskalation erforderlich ist.

Schritt 5: Kommunikationswege vereinbaren. Lege fest, welche Informationen benötigt werden, wie häufig Abstimmungen stattfinden und wie Entscheidungen dokumentiert werden.

Schritt 6: Konflikte und Zielkonflikte strukturiert bearbeiten. Verwende nachvollziehbare Kriterien, um Optionen zu vergleichen und Auswirkungen sichtbar zu machen. Wenn keine Einigung möglich ist, bereite eine klare Entscheidungsvorlage vor.

Schritt 7: Zusammenarbeit regelmäßig überprüfen. Prüfe, ob Entscheidungen rechtzeitig getroffen werden, Anforderungen verstanden sind und Rückmeldungen tatsächlich in die Umsetzung einfließen. Passe den Plan bei Bedarf an.

Dieser Ablauf ist bewusst pragmatisch gehalten. Bei kleinen Vorhaben können wenige Gespräche und eine kompakte Übersicht ausreichen. Bei komplexen, sicherheitskritischen oder organisationsübergreifenden Projekten sind möglicherweise umfangreichere Abstimmungen und formale Entscheidungsprozesse notwendig.

Entscheidend ist nicht die Menge der Dokumentation, sondern die Qualität der Zusammenarbeit.

Fazit: Gute Ergebnisse entstehen nicht durch möglichst viele Abstimmungen, sondern durch bessere Entscheidungen

Stakeholder-Management ist weit mehr als Kommunikation und Beziehungspflege. Es ist eine zentrale Fähigkeit, um unterschiedliche Interessen in einer Organisation so zusammenzuführen, dass daraus tragfähige Entscheidungen und wirksame Lösungen entstehen.

Gerade in der IT treffen unterschiedliche Perspektiven aufeinander: Geschäftsziele, operative Anforderungen, technische Rahmenbedingungen, Sicherheitsrisiken und wirtschaftliche Grenzen. Wer diese Perspektiven ignoriert, riskiert Lösungen, die zwar formal umgesetzt werden, im Alltag aber nicht den erwarteten Nutzen liefern.

Ein guter Product Owner, Business Engineer oder Requirements Engineer versteht deshalb nicht nur Anforderungen. Er untersucht ihre Ursachen, macht Zielkonflikte transparent, entwickelt Lösungsoptionen und schafft eine belastbare Grundlage für Entscheidungen. Dabei muss er nicht jeden Konflikt selbst lösen und auch nicht jede Entscheidung eigenständig treffen. Er muss jedoch erkennen, welche Fragen geklärt werden müssen, wer dafür verantwortlich ist und welche Konsequenzen die verfügbaren Optionen haben.

Die wichtigste Erkenntnis lautet: Erfolgreiches Stakeholder-Management bedeutet nicht, möglichst viele Menschen zufriedenzustellen. Es bedeutet, die richtigen Menschen zur richtigen Zeit an den richtigen Entscheidungen zu beteiligen.

Wenn das gelingt, werden Anforderungen klarer, Konflikte produktiver und Ressourcen gezielter eingesetzt. Davon profitieren nicht nur einzelne Projekte, sondern die gesamte Organisation.

Denn am Ende gewinnt nicht derjenige, der sich in Meetings am besten durchsetzt. Es gewinnt die Organisation, die unterschiedliche Perspektiven in bessere Entscheidungen übersetzen kann.

Jetzt bist du gefragt!

Was ist deine größte Herausforderung im Stakeholder-Management?

Sind es unrealistische Erwartungen des Managements, unterschiedliche Interessen zwischen Fachbereich und IT, endlose Abstimmungsschleifen oder Stakeholder, die zwar mitreden, aber keine Entscheidungen treffen wollen?

Teile deine Erfahrungen in den Kommentaren! Was hat dir geholfen, solche Situationen zu lösen und was funktioniert deiner Meinung nach überhaupt nicht?

Häufig gestellte Fragen zum Stakeholder-Management

Was ist Stakeholder-Management einfach erklärt?

Stakeholder-Management bezeichnet die systematische Identifikation und Einbindung aller relevanten Personen und Gruppen eines Vorhabens. Dazu gehören die Analyse ihrer Interessen, die Abstimmung von Erwartungen, die Gestaltung der Kommunikation und der Umgang mit Konflikten. Ziel ist es, tragfähige Entscheidungen zu ermöglichen und den Erfolg eines Projekts oder Produkts zu unterstützen.

Warum ist Stakeholder-Management in IT-Projekten so wichtig?

IT-Projekte verbinden häufig unterschiedliche Fachbereiche, technische Teams und Managementebenen. Diese Gruppen verfolgen teilweise unterschiedliche Ziele und bewerten Erfolg anhand verschiedener Kriterien. Professionelles Stakeholder-Management hilft dabei, Anforderungen zu klären, Zielkonflikte frühzeitig zu erkennen und Entscheidungen nachvollziehbar zu treffen.

Welche Aufgaben hat ein Product Owner im Stakeholder-Management?

Ein Product Owner vermittelt Produktziele, analysiert Anforderungen, priorisiert das Product Backlog und fördert den Austausch zwischen relevanten Stakeholdern und dem Entwicklungsteam. Er muss unterschiedliche Interessen berücksichtigen und Entscheidungen auf den erwarteten Produktnutzen ausrichten. Seine konkreten Befugnisse hängen vom organisatorischen Mandat ab.

Welche Methoden eignen sich für eine Stakeholder-Analyse?

Häufig verwendete Methoden sind Stakeholder-Matrizen, Einfluss-Betroffenheits-Analysen, strukturierte Interviews und Kommunikationspläne. Ergänzend können Entscheidungs- und Verantwortlichkeitsmodelle helfen, Rollen und Zuständigkeiten zu klären. Die Auswahl sollte sich an der Komplexität und den Risiken des jeweiligen Vorhabens orientieren.

Wie geht man mit schwierigen Stakeholdern um?

Zunächst sollte geklärt werden, welche Interessen, Erwartungen oder Befürchtungen hinter dem Verhalten stehen. Sachliche Bewertungskriterien, transparente Kommunikation und klare Verantwortlichkeiten helfen dabei, Konflikte zu bearbeiten. Wenn keine Einigung möglich ist, sollte die offene Entscheidung mit nachvollziehbaren Optionen und Konsequenzen an die zuständige Stelle eskaliert werden.

Wie unterscheidet sich Stakeholder-Management von Anforderungsmanagement?

Stakeholder-Management beschäftigt sich mit den relevanten Personen, ihren Interessen, Erwartungen und ihrer Einbindung. Anforderungsmanagement konzentriert sich darauf, Anforderungen zu ermitteln, zu dokumentieren, zu bewerten, zu priorisieren und über ihren Lebenszyklus hinweg zu steuern. Beide Disziplinen ergänzen sich: Ohne Verständnis der Stakeholder bleiben Anforderungen häufig unvollständig oder widersprüchlich.

Wie lässt sich der Erfolg von Stakeholder-Management messen?

Mögliche Indikatoren sind die Dauer wichtiger Entscheidungsprozesse, der Umfang vermeidbarer Nacharbeit, die Verständlichkeit von Anforderungen, die Zufriedenheit der Beteiligten und die tatsächliche Nutzung eingeführter Lösungen. Einzelne Kennzahlen sollten immer im Kontext betrachtet werden, da beispielsweise häufige Anforderungsänderungen auch aus wertvollen neuen Erkenntnissen entstehen können.