Viele IT-Projekte scheitern nicht an der Technik, sondern an Menschen: Der Fachbereich fühlt sich übergangen, der Betriebsrat wird zu spät gefragt, die IT-Sicherheit legt kurz vor dem Go-live ihr Veto ein. Gutes Stakeholder-Management in IT-Projekten sorgt dafür, dass solche Überraschungen gar nicht erst entstehen. Dieser Artikel zeigt in fünf Schritten, wie Sie Stakeholder identifizieren, bewerten und gezielt einbinden – und welche Fehler Sie vermeiden sollten.
Stakeholder sind alle Personen und Gruppen, die ein Projekt beeinflussen können oder von seinem Ergebnis betroffen sind. Stakeholder-Management ist der systematische Umgang mit ihnen: herausfinden, wer betroffen ist, verstehen, was diese Gruppen erwarten und befürchten, und die Zusammenarbeit so gestalten, dass das Projekt Unterstützung statt Widerstand erfährt. Der PMBOK Guide des Project Management Institute führt das Thema seit seiner fünften Ausgabe als eigenen Wissensbereich – ein Zeichen dafür, wie stark der Projekterfolg von den Beteiligten abhängt.
Wichtig ist die Abgrenzung zur reinen Kommunikation. Ein Statusbericht per E-Mail ist Information. Stakeholder-Management geht weiter: Es fragt, wessen Zustimmung das Projekt braucht, wessen Wissen es nutzen muss und wessen Bedenken ernst genommen werden müssen, bevor sie zum Hindernis werden.
Am Anfang steht eine möglichst vollständige Liste. Sie entsteht am besten im Projektteam und gemeinsam mit dem Auftraggeber, etwa in einem kurzen Workshop während der Projektinitiierung. In IT-Projekten tauchen typischerweise diese Gruppen auf:
Eine hilfreiche Kontrollfrage lautet: Wer könnte das Projekt stoppen, verzögern oder entscheidend verbessern? Wer auf diese Frage einfällt, gehört auf die Liste.
Nicht jeder Stakeholder braucht die gleiche Aufmerksamkeit. Bewährt hat sich eine Stakeholder-Matrix, die Einfluss und Interesse gegenüberstellt. Daraus ergeben sich vier Felder mit unterschiedlicher Strategie:
Zusätzlich lohnt ein Blick auf die Haltung: Wer unterstützt das Projekt, wer ist neutral, wer ist skeptisch – und warum? Halten Sie diese Einschätzung zusammen mit Erwartungen, Befürchtungen und Ansprechpartnern in einem Stakeholderregister fest. Da die Haltungsbewertung sensibel ist, sollte das Register nur einem kleinen Kreis im Projekt zugänglich sein.
Aus der Analyse folgt, wie Sie mit jeder Gruppe arbeiten. Der Kommunikationsplan beantwortet für jeden wichtigen Stakeholder fünf Fragen: Welche Information braucht er? In welcher Tiefe? Wie oft? Über welchen Kanal? Und wer im Projekt ist verantwortlich? Die Geschäftsführung braucht einen kompakten Überblick über Termine, Budget und Entscheidungsbedarf. Key User brauchen Details zu Funktionen und Terminen für Tests und Schulungen. Der IT-Betrieb braucht frühzeitig technische Rahmenbedingungen.
Planen Sie dabei nicht nur Berichte, sondern auch Entscheidungsformate: Lenkungsausschuss, Abnahmetermine, Review-Meetings. Ein Kommunikationsplan, der nur festlegt, wer welchen Bericht erhält, reicht nicht aus.
Am meisten Wirkung hat Beteiligung an den Stellen, an denen das Projekt Entscheidungen braucht. Drei Momente sind in IT-Projekten besonders wichtig:
Wer Anforderungen nur einsammelt, bekommt Wunschlisten. Wer sie mit Fachbereich, Endanwendern und IT gemeinsam erarbeitet und priorisiert, bekommt tragfähige Ergebnisse. Wie das gelingt, beschreibt unser Artikel Saubere Anforderungen in IT-Projekten.
Prototypen, Demos und Sprint Reviews geben Stakeholdern die Chance, früh zu reagieren. Eine Korrektur nach der ersten Demo ist deutlich günstiger als nach der Abnahme.
Wenn Fachbereich und Auftraggeber schon zu Projektbeginn festlegen, woran sie ein gutes Ergebnis erkennen, wird die Abnahme zum Abgleich statt zum Streit. Mehr dazu in Abnahmetests: So gelingt die Softwareabnahme sicher.
Die Stakeholder-Landschaft verändert sich: Verantwortliche wechseln, Abteilungen werden umorganisiert, ein bisher unbeteiligter Bereich ist plötzlich betroffen. Prüfen Sie das Stakeholderregister deshalb regelmäßig, etwa zu jedem Meilenstein oder alle paar Sprints. Signale wie ausbleibende Rückmeldungen, abgesagte Termine oder Kritik über informelle Kanäle sind Hinweise, dass eine Gruppe nicht mehr mitzieht. Solche Entwicklungen gehören auch ins Risikomanagement in IT-Projekten, denn fehlende Unterstützung ist eines der häufigsten Projektrisiken.
Widerstand ist kein Störfaktor, den man wegmoderieren sollte, sondern eine Information. Hinter Ablehnung stecken oft nachvollziehbare Sorgen: mehr Arbeit während der Umstellung, Verlust von Know-how oder Einfluss, Angst vor Überwachung oder schlicht schlechte Erfahrungen mit früheren Projekten. Bewährt hat sich ein direktes Gespräch, in dem Sie die Bedenken konkret erfragen und prüfen, welche davon das Projekt lösen kann – etwa durch Schulungen, eine angepasste Einführungsreihenfolge oder klare Regeln zur Datennutzung. Wo Interessen tatsächlich gegeneinander stehen, braucht es eine Entscheidung durch Auftraggeber oder Lenkungsausschuss. Wichtig ist, dass diese Entscheidung offen getroffen und begründet wird. Wenn ein Projekt Arbeitsweisen grundlegend verändert, lohnt sich zusätzlich ein strukturiertes Change Management.
In Scrum ist der Product Owner die zentrale Schnittstelle zu den Stakeholdern: Er sammelt Bedürfnisse, priorisiert das Backlog und lädt Stakeholder zum Sprint Review ein, in dem das Inkrement gemeinsam begutachtet wird. Das macht Stakeholder-Management nicht überflüssig, verlagert es aber. Wenn der Product Owner kein Mandat hat oder wichtige Gruppen nie zu den Reviews erscheinen, entstehen dieselben Probleme wie im klassischen Projekt – nur später sichtbar. In hybriden Projekten kommt hinzu, dass Lenkungsausschuss und Team unterschiedliche Rhythmen haben. Mehr zu den Unterschieden lesen Sie in Agiles vs. klassisches Projektmanagement.
Stakeholder-Management in IT-Projekten ist keine Zusatzaufgabe, sondern Teil der Projektsteuerung. Wer früh klärt, wer betroffen ist, die Gruppen nach Einfluss und Interesse priorisiert, Kommunikation und Beteiligung gezielt plant und das Bild regelmäßig aktualisiert, vermeidet viele Verzögerungen und Konflikte, bevor sie entstehen. Wie Sie darüber hinaus Termine und Budget im Griff behalten, lesen Sie in IT-Projekte im Zeit- und Budgetplan: So geht es wirklich.
So früh wie möglich, idealerweise bereits in der Projektinitiierung, bevor Umfang und Vorgehen festgelegt werden. Danach sollte die Analyse regelmäßig überprüft werden, etwa zu jedem Meilenstein, weil sich Zuständigkeiten und Interessen im Projektverlauf ändern.
In klassischen Projekten liegt die Verantwortung bei der Projektleitung, unterstützt durch Auftraggeber und Teilprojektleiter. In Scrum übernimmt vor allem der Product Owner die Abstimmung mit den Stakeholdern. Einzelne Beziehungen können an Teammitglieder delegiert werden, der Gesamtüberblick sollte aber an einer Stelle liegen.
Kommunikationsmanagement regelt, wer welche Information wann und über welchen Kanal erhält. Stakeholder-Management ist umfassender: Es analysiert Einfluss, Interessen und Haltung der Beteiligten und legt fest, wie sie in Entscheidungen eingebunden werden. Der Kommunikationsplan ist damit ein Werkzeug des Stakeholder-Managements.
30 Minuten Erstgespräch — kostenlos und unverbindlich. Wir schauen gemeinsam auf Ihr Vorhaben und zeigen, wie Sie Beteiligte und Entscheider wirksam einbinden.
Jetzt Erstgespräch vereinbarenMehr zu unserer Leistung: IT-Projektmanagement in Hamburg →
Passend dazu: Change Management in Hamburg →