Teil 03: Stakeholder-Analyse durchführen
- Michaela Kühn
- vor 1 Tag
- 7 Min. Lesezeit
Anforderungsmanagement in der IT - Modul 1: Grundlagen
In den ersten beiden Artikeln hast du gelernt, was Anforderungsmanagement ist und welche Rolle der Requirements Engineer spielt. Aber von wem kommen eigentlich die Anforderungen? Wer sind all die Menschen, deren Bedürfnisse du verstehen musst?
Die Marmorkuchen-Hochzeit-Metapher: Stell dir vor, du sollst einen Marmorkuchen für eine Hochzeit backen. Wer hat alles ein Wort mitzureden?
Das Brautpaar (will etwas Besonderes, hat das Budget)
Die Eltern (bezahlen vielleicht, haben Traditionen im Kopf)
Der Hochzeitsplaner (muss alles koordinieren)
Die Gäste (müssen ihn essen und mögen)
Der Location-Manager (muss wissen: Wie groß? Kühlschrank vorhanden?)
Der Fotograf (will, dass der Kuchen fotogen ist)
Jeder hat andere Wünsche, andere Prioritäten – und deine Aufgabe als Konditormeister ist es, all diese Menschen und ihre Bedürfnisse zu managen. Genau das ist Stakeholder-Management. Was ist ein Stakeholder?
Stakeholder: Eine Person, Gruppe oder Organisation, die ein Interesse am Projekt hat, vom Projekt betroffen ist oder das Projekt beeinflussen kann.
Das Wort kommt aus dem Englischen: "Stake" = Anteil/Einsatz, "Holder" = Halter. Also jemand, der einen "Anteil" im Projekt hat.
Stakeholder in IT-Projekten
Im Gegensatz zum Marmorkuchen-Beispiel ist die Stakeholder-Landschaft in IT-Projekten oft noch komplexer, den wir unterscheiden direkte und indirekte Stakeholder.
Direkte Stakeholder:
Auftraggeber (bezahlt das Projekt)
Endnutzer (arbeiten später mit dem System)
Product Owner / Fachbereich (verantwortlich für das Produkt)
Entwicklungsteam (setzt um)
Tester (prüfen Qualität)
Indirekte Stakeholder:
Management (strategische Entscheidungen)
Marketing & Vertrieb (verkaufen das Produkt)
Support-Team (betreut Nutzer nach Go-Live)
IT-Betrieb (wartet das System)
Compliance / Legal (regulatorische Anforderungen)
Externe Partner (Lieferanten, Dienstleister)
MarmorkuchenApp-Beispiel – Stakeholder identifizieren:
Stakeholder | Rolle | Interesse |
CEO von SmartBake | Auftraggeber | ROI, Marktführerschaft |
Privatkunden | Endnutzer | Einfache Bestellung |
Bäckerei-Ketten | B2B-Kunden | Großbestellungen, Rabatte |
Entwicklungsteam | Umsetzung | Klare Requirements, moderne Tech |
Marketing-Team | Vermarktung | Viral-Features, Social Media |
Support-Team | Kundenbetreuung | Einfache Bedienung, wenig Support-Aufwand |
IoT-Hardware-Hersteller | Partner | Kompatibilität mit Backmaschine |
Datenschutzbeauftragter | Compliance | DSGVO-Konformität |
Wie du siehst: Viele Köche mit verschiedenen Rezepten im Kopf!
Warum ist Stakeholder-Analyse wichtig?
Die Gefahren ohne Stakeholder-Analyse
Szenario 1: Der vergessene Stakeholder
Du entwickelst die MarmorkuchenApp nach den Wünschen des CEO
Kurz vor Launch: Der Datenschutzbeauftragte sagt "Stop! Das ist nicht DSGVO-konform!"
Ergebnis: Komplette Überarbeitung, Launch verschoben, Budget überschritten
Marmorkuchen-Analogie: Du backst den Kuchen nach Wunsch des Brautpaars. Am Hochzeitstag: Der Location-Manager sagt "Der Kuchen passt nicht durch die Tür!"
Szenario 2: Der falsche Stakeholder
Du fragst den Marketing-Chef nach Anforderungen
Er will: KI, Blockchain, VR-Integration
Die echten Nutzer wollen: Einfach Kuchen bestellen
Ergebnis: Überladene App, die niemand nutzt
Marmorkuchen-Analogie: Du fragst den Instagram-Fotografen, wie der Kuchen aussehen soll. Er will einen 2 Meter hohen, goldenen Kuchen. Das Brautpaar wollte eigentlich was Kleines und Schlichtes.
Szenario 3: Der ignorierte Stakeholder
Du weißt, dass es das Support-Team gibt, holst aber kein Feedback ein
Nach Launch: Support wird überflutet mit Anfragen, weil die App unklar ist
Das Support-Team ist frustriert: "Warum hat uns niemand gefragt?"
Die Vorteile guter Stakeholder-Analyse
✅ Vollständige Anforderungen: Du vergisst keine wichtigen Aspekte
✅ Frühe Konflikterkennung: Widersprüche werden vor der Entwicklung klar
✅ Bessere Akzeptanz: Stakeholder fühlen sich gehört und eingebunden
✅ Realistische Erwartungen: Alle wissen, was möglich ist und was nicht
✅ Effiziente Kommunikation: Du weißt, wen du wann wie informieren musst
Schritt 1: Stakeholder identifizieren
Methoden zur Identifikation
Brainstorming: Sammle mit dem Projektteam: "Wer könnte alles vom Projekt betroffen sein oder es beeinflussen?"
Stakeholder-Kategorien durchgehen
Wer bezahlt?
Wer nutzt es?
Wer entwickelt es?
Wer muss es warten?
Wer muss es genehmigen?
Wer profitiert davon?
Wer könnte dagegen sein?
Organisationsstruktur analysieren: Organigramm durchgehen: Welche Abteilungen sind betroffen?
"Schneeball-Methode": Frage bekannte Stakeholder: "Wen sollte ich noch einbeziehen?"
Lessons Learned aus ähnlichen Projekten: "Wen haben wir beim letzten Mal vergessen?"
Jetzt hast du eine lange Liste. Aber nicht alle Stakeholder sind gleich wichtig. Du musst sie priorisieren und kategorisieren.
Schritt 2: Stakeholder analysieren
Das meistgenutzte Tool zur Stakeholder-Analyse. Zwei Dimensionen:
Power (Macht/Einfluss): Wie viel Einfluss hat der Stakeholder auf das Projekt? Interest (Interesse): Wie stark ist der Stakeholder vom Projekt betroffen?
C: Keep Satisfied (Hoch Power, Niedrig Interest)
| D: Manage Closely (Hoch Power, Hoch Interest)
|
A: Monitor (Niedrig Power, Niedrig Interest)
| B: Keep Informed (Niedrig Power, Hoch Interest)
|
MarmorkuchenApp Power-Interest-Matrix
C: (Keep Satisfied) – Hohe Power, Niedriges Interest:
| D: (Manage Closely) – Hohe Power, Hohes Interest:
|
A: (Monitor) – Niedrige Power, Niedriges Interest:
| B: (Keep Informed) – Niedrige Power, Hohes Interest:
|
Weitere Analysedimensionen
Neben Power/Interest kannst du auch analysieren:
Haltung zum Projekt:
😊 Supporter: Aktiv für das Projekt
😐 Neutral: Weder dafür noch dagegen
😠 Opponent: Skeptisch oder dagegen
Beispiel MarmorkuchenApp:
Supporter: Marketing (sieht Potenzial), Endnutzer (wollen die Lösung)
Neutral: IT-Betrieb (noch ein System mehr zu warten)
Opponent: Etablierte Bäckerei-Ketten (fürchten Konkurrenz)
Kommunikationspräferenz:
📧 E-Mail (Details, asynchron)
📞 Telefon/Video-Call (schnelle Klärung)
👥 Workshop (gemeinsame Erarbeitung)
📊 Präsentation (Management, große Gruppe)
Verfügbarkeit:
Hoch: Täglich erreichbar (internes Team)
Mittel: 1-2x pro Woche (externe Partner)
Niedrig: Nur bei Bedarf (Management)
Schritt 3: Stakeholder-Typen und Umgang
Verschiedene Stakeholder erfordern verschiedene Ansätze. Hier sind typische "Charaktere":
Typ 1: Der Visionär
Will das Produkt revolutionieren
Große Ideen, manchmal unrealistisch
"Wir brauchen KI, Blockchain und Hologramme!"
Marmorkuchen-Analogie: "Der Kuchen muss 5 Meter hoch sein, essbare Blattgold-Überzüge haben und eine integrierte Lichtshow!"
Wie damit umgehen:
✅ Vision wertschätzen: "Tolle Idee!"
✅ Auf Machbarkeit prüfen: "Lass uns schauen, was realistisch ist"
✅ In Phasen denken: "Version 1: Basis, Version 2: KI-Features"
✅ Business Case zeigen: "Das würde 12 Monate und 500.000€ kosten"
MarmorkuchenApp-Beispiel: CEO will: "Eine App, die automatisch Kuchenfotos auf Instagram postet, KI-generierte Rezepte erstellt und mit Smart-Home-Systemen vernetzt ist!" → Runterbrechen auf MVP: "Version 1: Bestellen + Tracken. Weitere Features später."
Typ 2: Der Detailverliebte
Will alles bis ins kleinste Detail spezifiziert haben
Stellt viele Fragen
"Aber was passiert, wenn...?"
Marmorkuchen-Analogie: "Exakt 247,3 Gramm Mehl! Auf 0,1 Grad genaue Backtemperatur! Und die Marmorierung muss im 37-Grad-Winkel sein!"
Wie damit umgehen:
✅ Geduld haben
✅ Strukturiert Antworten: Detaillierte Dokumentation
✅ Grenzen setzen: "An diesem Punkt reicht die Genauigkeit"
✅ Visualisieren: Mockups, Diagramme helfen
MarmorkuchenApp-Beispiel: Datenschutzbeauftragter will genau wissen: Wie werden Daten verschlüsselt? Wo gespeichert? Wie lange? Löschkonzept? → Detaillierte Datenschutz-Dokumentation erstellen
Typ 3: Der Pragmatiker
Will funktionierende Lösungen
"Hauptsache es läuft!"
Weniger interessiert an Details
Marmorkuchen-Analogie: "Hauptsache der Kuchen schmeckt gut und reicht für alle. Mir egal wie er aussieht."
Wie damit umgehen:
✅ Fokus auf Ergebnisse
✅ Kurze, prägnante Updates
✅ Zeigen statt Erklären: Demos, Prototypen
✅ ROI kommunizieren
MarmorkuchenApp-Beispiel: CFO fragt: "Was kostet es? Was bringt es? Wann ist Break-Even?" → Business Case mit klaren Zahlen präsentieren
Typ 4: Der Skeptiker
Sieht Probleme und Risiken
"Das wird nie funktionieren!"
Oft sehr kritisch
Marmorkuchen-Analogie: "Marmorkuchen? Das wird zu trocken! Die Leute mögen keine Kuchen mehr! Und außerdem ist das zu teuer!"
Wie damit umgehen:
✅ Ernst nehmen: Risiken sind wertvoll!
✅ Bedenken dokumentieren
✅ Lösungen aufzeigen: "Wie können wir das Risiko minimieren?"
✅ Quick Wins liefern: Frühe Erfolge zeigen
MarmorkuchenApp-Beispiel: IT-Betrieb: "Noch eine App, die wir warten müssen? Das wird ein Support-Alptraum!" → Frühzeitig einbinden, zeigen dass Support-Freundlichkeit mitgedacht wird
Typ 5: Der Abwesende
Schwer zu erreichen
Antwortet selten/spät
"Bin gerade beschäftigt"
Marmorkuchen-Analogie: Das Brautpaar ist auf Weltreise und antwortet nur alle 2 Wochen auf E-Mails. Hochzeit ist in 6 Wochen!
Wie damit umgehen:
✅ Frühzeitig einplanen: Lange Vorlaufzeiten
✅ Strukturierte Anfragen: Konkrete Fragen, Multiple Choice wenn möglich
✅ Deadlines setzen: "Ich brauche Input bis..."
✅ Eskalieren wenn nötig: An Vorgesetzten wenden
MarmorkuchenApp-Beispiel: Externes IoT-Hardware-Team antwortet nur sporadisch. → Feste Jour-Fixe vereinbaren, Protokolle mit Action Items
Schritt 4: Kommunikationsplan erstellen
Jetzt weißt du, wer deine Stakeholder sind. Nun brauchst du einen Plan, wie und wann du sie informierst.
Stakeholder | Was | Wie oft? | Medium? | Wer verantwortlich? |
CEO | Projekt-Status, Risiken, Meilensteine | Monatlich | Präsentation | Product Owner |
Product Owner | User Stories, Prioritäten, Feedback | Täglich | Daily Stand-up, Slack | RE / Scrum Master |
Entwicklungsteam | Requirements Details, Änderungen | Täglich | Sprint Meetings, JIRA | RE |
Endnutzer (Beta) | Neue Features, Feedback-Anfragen | Bei Releases | E-Mail, In-App | RE / Marketing |
Support-Team | Neue Features, bekannte Bugs | Vor jedem Release | Schulung, Doku | RE |
Marketing | Roadmap, Launch-Plan | 2-wöchentlich | Workshop | Product Owner |
Datenschutz | Privacy-Features, Datenflüsse | Bei Bedarf | Dokumentation + Review | RE / Tech Lead |
Management | Budget, Timeline, Erfolge | Quartalsweise | Reporting | Product Owner |
Kommunikationsprinzipien
Stakeholder-gerecht kommunizieren
Mit CEO: Hochlevel, Business Impact
Mit Entwicklern: Technische Details
Mit Nutzern: Einfache Sprache, Mehrwert
Regelmäßigkeit schafft Vertrauen
Feste Termine
Auch kommunizieren, wenn es "nichts Neues" gibt
Proaktiv statt reaktiv
Probleme frühzeitig ansprechen
Nicht warten, bis gefragt wird
Feedback-Kanäle öffnen
Wie können Stakeholder dich erreichen?
Sind die Kanäle klar kommuniziert?
Dokumentieren
Meeting-Protokolle
Entscheidungen festhalten
Wer hat was wann gesagt?
Häufige Fehler und wie du sie vermeidest
Fehler 1: "Ich habe die wichtigsten gefragt" | ❌ Problem: Du fragst nur die offensichtlichen Stakeholder (z.B. Product Owner) ✅ Lösung: Systematisch alle identifizieren, auch "versteckte" Stakeholder MarmorkuchenApp-Beispiel: Du fragst nur Product Owner und CEO, vergisst aber:
|
Fehler 2: "Allen das Gleiche erzählen" | ❌ Problem: Gleiche Kommunikation für alle Stakeholder ✅ Lösung: Maßgeschneiderte Kommunikation je nach Stakeholder-Typ Beispiel: CEO interessiert sich nicht für technische Details wie "Welche API-Endpoints nutzen wir?" Entwickler interessieren sich nicht für "Was ist unsere Social-Media-Strategie?" → Jeder bekommt die Info, die für ihn relevant ist |
Fehler 3: "Das ist doch offensichtlich!" | ❌ Problem: Annahmen treffen statt zu fragen ✅ Lösung: Explizit nachfragen und dokumentieren MarmorkuchenApp-Beispiel: Annahme: "Natürlich funktioniert die App auf iOS und Android!" Realität: Budget reicht nur für eine Plattform → Late discovery, Nutzer-Erwartungen enttäuscht |
Fehler 4: "Stakeholder-Analyse mache ich am Anfang" | ❌ Problem: Einmalige Analyse zu Projektbeginn ✅ Lösung: Kontinuierliche Überprüfung Während des Projekts können:
→ Quartalsweise oder bei wichtigen Meilensteinen überprüfen! |
Zusammenfassung
Stakeholder sind alle Personen/Gruppen, die vom Projekt betroffen sind oder es beeinflussen können
Stakeholder-Analyse ist entscheidend, um Anforderungen vollständig zu erfassen und Konflikte frühzeitig zu erkennen
Identifikation: Systematisch alle Stakeholder finden (intern, extern, direkt, indirekt)
Analyse: Power-Interest-Matrix nutzen um zu priorisieren
Stakeholder-Typen: Visionär, Detailverliebter, Pragmatiker, Skeptiker, Abwesender – jeder braucht unterschiedlichen Umgang
Kommunikationsplan: Wer bekommt was, wann, wie?
Kontinuierlich: Stakeholder-Analyse ist kein einmaliger Akt, sondern ein fortlaufender Prozess
Übersicht zur Reihe
Über die Autorin: Michaela Kühn, Sparringspartnerin zum Thema Requirements Engineeting und Business Analyse in Projekten
Hast Du Fragen oder eigene Erfahrungen mit Requirements Engineering? Teilen Sie sie in den Kommentaren oder diskutieren Sie mit mir auf LinkedIn.
Quellen:
PMBOK Guide, 7 & 8th Edition, PMI, Themenfeld: Projektmanagement
Governance of Portfolios, Programs, and Projects: A Practice Guide, PMI, Governance
Business Analysis for Practitioners: A Practice Guide, 2nd Edition, PMI , Business Analysis
Requirements Management: A Practice Guide, PMI / Agile Aliance, Agile & Lean
Band 1: Organisation und Business Analysis – Methoden und Techniken, IBO, Business Analysis Methoden
Use Case 3.0, Ivar Jacobson et al., Use Cases & Requirements
Leading AI Transformation: Organizational Strategies for Project Professionals, PMI (2025), KI-Transformation
Guide to Leading and Managing AI Projects, PMI (2025) , KI-Projektmanagement
(C) Michaela Kühn - www.michaela-kuehn.com - Sparringspartnerin für Anfoderungsmanagement ( Requirements Engineering) und Agile Business Analyse und Projektmanagement
Kommentare