Stakeholder Management bei Software-Einführungen: Erfolgsfaktor für IT-Projekte

Software-Einführungen sind keine reinen IT-Projekte. Der Erfolg hängt davon ab, wie früh und wie klar Stakeholder eingebunden werden. IT-Projektverantwortliche, die Erwartungen klar verstehen und gezielt kommunizieren, schaffen Akzeptanz, verhindern Blockaden und sichern den Projekterfolg langfristig.

Warum ist das Stakeholder Management bei Softwareeinführungen so entscheidend?

Softwareeinführungen oder Systemwechsel greifen nicht nur in Prozesse und Strukturen ein, sondern auch in die persönlichen Arbeitsweisen und Präferenzen der Mitarbeitenden. Projektpläne konzentrieren sich oft einseitig auf Technik, Budgets und Deadlines. Das gezielte Management der Stakeholder ist oft ein unterschätzte Erfolgsfaktor.

Kernproblem: Wenn Stakeholder ihre Anforderungen nicht einbringen können oder sich übergangen fühlen, blockieren sie – aktiv oder passiv. Das führt zu:

• Widerstand: Offener oder verdeckter Protest gegen neue Tools und Prozesse
• Verzögerungen: Warten auf Entscheidungen, fehlende Tests oder fehlende Freigaben
• Kostensteigerung: Nachträgliche Anpassungen, Mehrarbeit in IT & Fachbereich
• Akzeptanzprobleme: Geringe Nutzung trotz technischer Verfügbarkeit

Mit frühzeitiger, klarer Kommunikation und einer abgestimmten Beteiligung lassen sich dagegen Effizienz, Akzeptanz und Nachhaltigkeit sichern.

Welche sind die wichtigsten Stakeholder-Gruppen in IT-Projekten?

In Softwareprojekten kommen verschiedene Gruppen mit unterschiedlichen Interessen zusammen:

• Management und Entscheider:innen
• IT-Teams und Administrator:innen
• Fachbereiche und Endanwender:innen
• externe Partner und Dienstleister sowie
• Compliance, Datenschutz und der Betriebsrat.

Jede dieser Gruppen hat eigene Erwartungen und Risiken – und sollte deshalb individuell adressiert werden.

Besonderheiten der einzelnen Stakeholder-Gruppen

Management & Entscheider:innen

Was zählt: Business-Mehrwert, ROI, strategischer Fit Diese Gruppe will Resultate sehen. Investitionen müssen sich rechnen, Prozesse sollen schlanker werden. Die Skepsis ist groß, wenn bestehende Systeme „noch laufen“. Ohne fundierten Business Case gibt’s kein Budget.

Typische Herausforderung: Entscheider:innen unterschätzen häufig den Umsetzungsaufwand oder sehen die Softwareeinführung nur als IT-Thema. Ohne greifbare Nutzenargumente bleibt die Zustimmung oberflächlich.

Kritischer Fehler: Kein belastbarer Business Case – dadurch kein echtes Commitment.

Empfehlungen:

• Klären Sie früh, welche Daten wie verarbeitet, überwacht oder protokolliert werden
• Bereiten Sie Genehmigungsunterlagen vor (z. B. Datenschutz-Folgenabschätzung)
• Sprechen Sie offen über mögliche Auswirkungen auf Mitarbeitende (z. B. Leistungstransparenz durch neue Systeme)
• Wenn der Betriebsrat eine entscheidende Rolle spielt, beziehen Sie ihn in Softwaretests ein

Methoden – Relevante Stakeholder identifizieren und strukturieren

Ein bewährtes Werkzeug ist das Stakeholder-Mapping. Dabei werden zwei Dimensionen betrachtet:

• Einfluss (Power): Welche Entscheidungs- oder Blockademacht besitzt der Stakeholder?
• Interesse (Interest): Wie stark ist die Betroffenheit durch die Softwareeinführung?

Auf Basis dieser Werte lassen sich Stakeholder in vier Gruppen einordnen:

1. Schlüsselakteure (High Influence / High Interest): z. B. Betriebsrat, IT-Security, Top-Management. → eng einbinden und aktiv beteiligen.

2. Latente Machtträger (High Influence / Low Interest): z. B. CFO, zentrale HR-Leitung. → faktenorientiert informieren, ohne zu überlasten.

3. Multiplikatoren (Low Influence / High Interest): z. B. Key-User im Fachbereich. → detailliert informieren und Feedback ernst nehmen.

4. Randakteure (Low Influence / Low Interest): z. B. Abteilungen mit wenig Schnittstellen. → minimal informieren, aber beobachten.

Praxis-Tipps:

• Nutzen Sie Visualisierungstools wie Miro, Lucidchart oder ein einfaches Excel-Sheet, um die Matrix darzustellen.
• Wiederholen Sie die Bewertung regelmäßig – Rollen und Interessen verschieben sich im Projektverlauf.
• Dokumentieren Sie kritische Annahmen: Warum wurde z. B. eine Gruppe nur als „Low Interest“ eingestuft?

Der Kommunikationsplan als Leitplanke

Ein strukturierter Kommunikationsplan beantwortet drei Fragen:

• Wer wird wann über was informiert?
  → Stakeholdergruppen differenzieren: Was interessiert das Management, was braucht die IT, was erwartet der Fachbereich?
• Über welchen Kanal (Meeting, Mail, Intranet, Ticket-System)?
  → Je nach Zielgruppe: Mail, Intranet, Meetings, Ticket-System, Videocall, Projektwiki. → Wichtig: Technische Zielgruppen erwarten andere Kanäle als Endanwender:innen.
• Mit welchem Ziel (Information, Feedback, Commitment)?
  → Information, Feedback einholen, Commitment erzeugen, Entscheidungen vorbereiten. → Jeder Kommunikationsschritt sollte ein klares Ziel verfolgen – und messbar sein.

Unser Tipp: Nutzen Sie die Unterstützung Ihres Softwareanbieters – oft gibt es fertige Kommunikationspakete. Ziehen Sie zusätzlich die Kommunikationsabteilung Ihres Unternehmens hinzu. Sie kennt die richtigen Kanäle und den passenden Stil für Ihre Mitarbeitenden.

Kommunikation in IT-Projekten – Allgemeine Dos and Don’ts

Erfolgreiche Kommunikation beginnt frühzeitig und berücksichtigt die spezifischen Bedürfnisse jeder Stakeholdergruppe.

Dos:

• Stakeholder rechtzeitig informieren
• Inhalte an Zielgruppen anpassen (Management = KPIs, IT = technische Details, Key-User = Anwendungstipps)
• Feedback aufnehmen und sichtbar berücksichtigen
• Pilotgruppen und Testumgebungen gezielt nutzen

Don’ts:

• Stakeholder nur „in CC setzen“
• Kritische Stimmen ignorieren
• Übermäßigen Fachjargon einsetzen

Umgang mit schwierigen Stakeholdern

Widerstand in IT-Projekten ist normal – ob offen oder verdeckt. Manche Stakeholder blockieren, verweigern Feedback oder erscheinen nicht zu Meetings Entscheidend ist: Früh erkennen, Ursachen verstehen, gezielt gegensteuern.

Typische Szenarien & Strategien:

• „Betrifft uns nicht“
  → Klare Aufklärung über indirekte Auswirkungen, z. B. auf Reporting oder Datenpflege.

• Change-Fatigue („bringt eh nichts“)
  → Früh kleine Erfolge sichtbar machen, Nutzen betonen, persönlichen Support bieten.

• Blockadeverhalten
  → 1:1-Gespräch suchen, Hintergründe klären, klare Verantwortungen schaffen.

Drei Hebel gegen Projektblockaden:

1. Transparenz schaffen:
→ Risiken und offene Punkte offen benennen (z. B. im Projektboard).

2. Verbindlichkeit sichern:
→ Zuständigkeiten klar definieren, z. B. mit RACI-Matrix.

3. Verbündete aktivieren:
→ Engagierte Key-User als Multiplikatoren einbinden.

Erfolgsmessung – wie Sie wirksame Kommunikation erkennen

Gutes Stakeholdermanagement zeigt sich in messbaren Indikatoren. Dazu zählen:

• Beteiligung & Engagement: Antwortquoten bei Umfragen, Nutzung von Projektnewslettern oder Intranet-Beiträgen

• Projektfortschritt: Anteil aktiver Teilnehmer:innen bei Tests, Schulungsquote und Lernerfolg

• Adoptionsrate: Nutzung der Software nach dem Go-live im definierten Zeitraum

Projektleitende sollten drei bis fünf zentrale KPIs auswählen, die für die Organisation aussagekräftig sind. Zu viele Kennzahlen verwässern den Überblick.