Zurück zur Methodenübersicht

Stakeholder

Stakeholder: Basis

Einleitung Stakeholder

Zum Projekterfolg gehört auch die Zufriedenheit wichtiger Stakeholder dazu. Selbst, wenn alle Ziele des magischen Dreiecks (Leistungsziele, Kostenziele, Terminziele), sind unter Umständen wichtige Stakeholder unzufrieden. Weil sie nicht genügend oder nicht - aus ihrer Sicht angemessen - in das Projekt einbezogen wurden. Oder sie andere informelle Erwartungen hatten, die sich kaum oder gar nicht in den Projektergebnissen widerspiegeln. Es gibt auch Stakeholder, die - aus welchen Gründen auch immer - das Projekt bekämpfen. Umgekehrt können Promotoren das Projekt unterstützen, sofern man sie identifiziert und für das Projekt einbindet. Wer sich als Projektleiter diese unterschiedlichen Einstellungen und Erwartungen zum Projekt nicht angemessen auseinandersetzt, riskiert am Ende den Projekterfolg. Zum Themenspektrum gehört die Identifizierung und Analyse der Stakeholder sowie die Ableitung angemessener Strategien und Maßnahmen.

Schnittstellen zum Projektumfeld frühzeitig klären

Kein Projekt findet im luftleeren Raum statt. Es ist von der Unterstützung des Projektumfelds innerhalb und außerhalb der Organisation angewiesen. Siehe auch Umfeldanalyse. Die Projektleitung muss frühzeitig die Schnittstellen des Projekts zum Projektumfeld klären. Siehe auch Vertiefung

Klassische Strukturen des internen Projektumfelds beachten und Supportfunktionen zu nutzen

Welche Abteilungen oder Strukturen hier besonders wichtig für das Projekt sind, hängt von der Organisation und dem Projektinhalt ab.

  • Finanzbuchhaltung und Controlling: Controllingprozesse und Berichtsarten sind zwar oft für alle Projektleiter vorgegeben, erleichtern aber gleichzeitig auch die Arbeit, weil man sich nur um projektspezifische Ergänzungen kümmern muss. Berichtsarten:

    • Regelmäßige Berichte wie Projektstatusbericht und Statusberichte zu Arbeitspaketen
    • Ereignisorientierte Berichte wie Abschlussberichte oder Berichte auf Anfrage
    • Agile Berichte wie Burn-Down Chart , Burn-Up Chart, Sprintbericht, Releasebericht. Siehe auch Vertiefung

  • Typische Aufgaben eines Projektmanagementoffice sind organisationsabhängig zum Beispiel Prozess-Standardisierung und Bereitstellung eines Projektmanagementhandbuchs, Coaching der Projektleiter, manchmal auch die Leitung eines Projektleiterpools, zentrales Projektcontrolling. Im Gegensatz dazu unterstützt ein Projektoffice nur ein oder mehrere Projekte temporär mit Assistenz (z.B. Stundenzettel einsammeln) oder mit hochqualifizierte Beratung (z.B. Pflege vernetzter Balkenplan in einem PM-Tool und Benachrichtigung der Projektleitung drohenden Verzögerungen auf dem kritischen Pfad).

  • Multiprojektmanagement wird in einigen Literaturquellen recht pragmatisch als “Planung, Überwachung und Steuerung mehrerer Projekte und Programme” bezeichnet. Insofern sind nach dieser Definition “Programm- und Portfoliomanagement” zwei Ausprägungsformen von Multiprojektmanagement:

    • Programm-Management ist das Management eines Programms mit dem Ziel, zentrale strategische Änderungen durchzusetzen. Ein Programm besteht aus mehreren miteinander verbundenen Projekten mit derselben strategischen Zielsetzung und endet mit dem Programmende.
    • Portfolio-Management ist die dauerhafte Versorgung einer Organisation mit Projekten und Programmen, welche die Organisation bei ihren strategischen Zielen unterstützen. Ein Projektportfolio fasst – je nach Festlegung der Organisation – identifizierte, definierte, genehmigte, geplante und laufende Projekte und Programme zusammen. Typische Aufgaben:
      • Initiierung strategiekonformer Projekte
      • Abbruch oder Modifikation von Projekten, die nicht mehr strategiekonform sind
      • Übergeordnete Überwachung, Steuerung und Priorisierung
      • Mehr Koordination als Führung. Die Aufgaben des Porfoliomanagements werden von mehreren Rollen durchgeführt wie zum Beispiel:
      • Projektportfoliomanager: Diese Rolle wird meist dann zusätzlich zum Projektmanagementoffice definiert, wenn die Größe und Komplexität des Portfolios eine spezialisierte Betreuung erfordert.
      • Projektmanagementoffice: Je nach der Festlegung des Leitungsspektrums eines Projektmanagementoffice werden auch Aufgaben im Portfoliomanagement übernommen.
      • Projektportfolioboard: *Hier sitzen oft Top-Manager wie Geschäftsführer und Bereichsleiter, welche die Vorschläge der anderen zwei Rollen - zum Beispiel zur Projektpriorisierung - diskutieren und Entscheidungen treffen.

Human Resources unterstützt bei vielen Themen wie der Weiterbildung und Suche nach Projektmitarbeitern, PM-Zertifizierungen oder der Suche nach Mediatoren bei Konflikten.

Mit der Umfeldanalyse einen schnellen Überblick über äußere Einflussfaktoren auf das Projekt identifizieren

Eine Umfeldanalyse ist eine frühzeitige Betrachtung und Analyse der positiven und negativen Einflüsse des Projektumfelds auf das Projekt. Oft wird noch die Einleitung von Maßnahmen zum Oberbegriff der Analyse dazu gezählt.

Für eine schnelle Umfeldanalyse hat sich die oben gezeigte grafische Darstellung des Projektumfelds mit einer einfachen Kategorisierung in sachliche, soziale, interne und externe Projektumfeldfaktoren bewährt. Mit ihr sind zum Beispiel notwendige Sofortmaßnahmen ableitbar oder frühzeitige Grundsatzentscheidungen zum Weitermachen oder Stopp.

Soziale Faktoren entsprechend den Stakeholder des Projekts. Das sind Personen oder Personengruppen, die am Projekt beteiligt sind, vom Projekt betroffen sind oder in irgendeiner Form am Projekt interessiert sind.

Im besten Fall unterstützen sie das Projekt, im schlechtesten Fall bekämpfen sie das Projekt. In jedem Fall sollte sich die Projektleitung überlegen, ob schon zu diesem frühen Zeitpunkt die sozialen Faktoren mit Stakeholdermaßnahmen im Sinne des Projekts beeinflusst werden müssen. Unter Umständen sollte schon zu diesem frühen Zeitpunkt das Projekt abgebrochen werden, wenn zu große Widerstände zu erwarten sind. Sollte das Projekt in der Definitionsphase weiterverfolgt werden, werden alle sozialen Faktoren im Stakeholdermanagement einer näheren Analyse unterzogen.

Soziale Faktoren können meist im Projekt selbst aktiv gestaltet werden - oft ohne formale Instanzen, also oft direkt. Änderungen im Stakeholdermanagement wirken oft schnell und unmittelbar.

Soziale Faktoren sollten nur ausnahmsweise als Gruppen geführt werden. Eine Gruppe “Abteilungsleiter” ist sicher problematisch, weil jede Abteilungsleiterin und jeder Abteilungsleiter eigene Ziele verfolgt - oft aus einer Machtposition heraus. Diese Gruppe ist für ein effektives Stakeholdermanagement in den meisten Projekten zu inhomogen. Alle Abteilungsleiter im Stakeholdermanagement “über einen Kamm zu scheren” ist deshalb meist eine schlechte Idee. In der Umfeldanalyse ist die Bildung solcher grober Gruppen vielleicht noch akzeptabel. Spätestens in der späteren Stakeholderanalyse sollten sehr inhomogene Gruppen in handhabbarere Untergruppen oder sogar Einzelpersonen aufgeteilt werden. Je nach individueller Abwägung zwischen verfügbarer Kapazität und der erhofften Wirkung zielgruppenspezifischer Maßnahmen.

💡 Projektleitungen sollten Personen lieber schon in der Umfeldanalyse namentlich nennen. Das ist für eventuelle Sofortmaßnahmen hilfreich und für das Brainstorming mit Sparringspartner meist aussagekräftiger. Beispiel: Statt „Fachbereich Vertrieb“ besser „Frau Schmidt – Fachbereich Vertrieb – Product Owner“.

Sachliche Faktoren sind keine Personen oder Personengruppen. Es sind Rahmenbedingungen wie Gesetze oder technische Entwicklung. Oft werden sie zwar erst durch Personen geschaffen, aber stellen erstmal Fakten dar.

Die PESTEL-Analyse sorgt für Struktur. Sie ordnet sachliche Faktoren in politische, wirtschaftliche, soziale, technologische und rechtliche Bereiche. PESTEL legt eher den Schwerpunkt auf makro-ökonomische und gesellschaftliche.  Rahmenbedingungen mit einem mittel- und langfristigen Zeithorizont.

  • Political: Gesetzgebung, Handelshemnisse
  • Economic: Wirtschaftswachstum, Inflation, Konkurrenz, interpretierbare Verträge
  • Social: Demografie, Bildung, Lebensstil, Werte (Hiermit sind nicht die sozialen Faktoren der Umfeldanalyse gemeint)
  • Technological: Bei Entwicklung und Produktion, Neuartigkeit Produkt/Lösungsansätze
  • Enironmental: ökologisch/umweltbezogen: Wetter, Rohstoffverfügbarkeit
  • Legal: Wettbewerbsrecht, Umweltrecht, Rechtssystem

💡 Viele Organisationen ergänzen die PESTEL-Analyse mit eigenen Kategorien.

Hinweis zu “S” Insbesondere das S sollte nicht mit Personen oder Personengruppen verwechselt werden: S steht für kollektive Strömungen und nicht für individuelle Akteure (Beispiele: Alterung der Bevölkerung, Wertewandel hin zu Nachhaltigkeit, Trend zu Homeoffice, Urbanisierung, Einstellung zu Digitalisierung).

  • Diese Themen kann man nicht gezielt mit einer Maßnahme „überzeugen“ wie einen einzelnen Stakeholder. Sie sind eher Rahmenbedingungen, wirken langfristig, sind diffus und nur indirekt beeinflussbar.
  • Insofern sind die Maßnahmen sind eher auf kurzfristige Anpassung und weniger auf nachhaltige Beeinflussung gerichtet. Eine Beeinflussung der oben aufgeführten Themen ist nur langfristig und indirekt möglich.

💡 Im Gegensatz zum “S” bei PESTEL geht es bei den sozialen Faktoren (Stakeholdern) der Umfeldanalyse um klare Interessen und damit auch klaren Einflussmöglichkeiten durch direkt adressbarbare Kommunikations-, Beteiligungs- und Verhandlungsstrategien.

Diese sachlichen Faktoren sind in Bezug auf das Projekt neutral oder können sich positiv oder negativ auf das Projekt auswirken. Bei einer negativen Auswirkung sollten sie Gegenstand der Risikoanalyse werden. Unter Umständen lohnen sich Sofortmaßnahmen. Oder die Risiken werden - zusammen mit den sozialen Faktoren schon zu diesem frühen Projektstadium als zu groß angesehen und man bricht die Überlegung zu einem möglichen Projekt an dieser Stelle schon ab.

In jedem Fall sollte man zu jedem sachlichen Faktor entscheiden, ob und wie man ihn wann im Projekt berücksichtigt. Dies macht man zum Beispiel in einer Schnittstellenanalyse (siehe unten).

Sachliche Faktoren können oft nicht sofort und direkt beeinflusst werden, sondern oft nur indirekt. Um sie anzupassen, braucht es zum Beispiel oft Entscheidungen des Auftraggebers, Verhandlungen, Verträge, Genehmigungen oder organisatorische Anpassungen. Das Projektteam kann oft nur reagieren, optimieren oder kompensieren - aber oft nicht spontan umstellen.

Die Unterscheidung in sachliche und soziale Faktoren ist wichtig, weil oft eine unterschiedliche methodische Behandlung empfehlenswert ist. Sachliche Faktoren können in eine Vielzahl von Projektmanagementmethoden einfließen (Projektstrukturplan, Risikomanagement…). Soziale Faktoren fließen in Methoden des Stakeholdermanagements ein.

Die Unterscheidung zwischen internen (endogene) und externen (exogenen) Faktoren ist aus meiner Sicht nicht so wichtig wie die Unterscheidung zwischen sachlichen und sozialen Faktoren.

  • Nach einer sehr verbreiteten Definition bezeichnen interne Faktoren alle Faktoren, die innerhalb der Unternehmensgrenze erzeugt werden und auf das Projekt einwirken (Beispiele: Infrastruktur, andere Projekte). Sie können oft durch über interne Ansprechpartner gesteuert werden, also direkt.
  • Externe Faktoren sind dann zum Beispiel Gesetze, Verordnungen. Es sind Faktoren außerhalb des Unternehmens (Gesetze, Marktsituation, technologische Entwicklung, öffentliche Meinung). Sie können durch das Unternehmen schwerer über Ansprechpartner gesteuert werden können.
  • Interne bzw. endogene Faktoren sind in der Regel leichter zu beeinflussen, deshalb ist diese Differenzierung nicht nur eine akademische Übung.

💡 Für mich dient die Unterscheidung in interne und externe Faktoren in erster Linie einer Art Vollständigkeitscheck, um keinen wichtigen Faktor zu vergessen.

Schnittstellenanalyse für den Umgang insbesondere mit den sachlichen Faktoren nutzen

Oft stecken in sachlichen Faktoren Hinweise auf zuständige Stakeholder, die man bei der ersten Umfeldanalyse noch nicht auf dem Schirm hatte. Beispiel: Beim sachlichen Faktor “Datenschutz” ist es logisch, in seiner Organisation den Datenschutzbeauftragten als Stakeholder anzusehen, sofern das noch nicht passiert ist.

Letztlich sollte man zumindest versuchen, zu jedem sachlichen Faktor mindestens einen Ansprechpartner zu finden und die methodischen Konsequenzen im Projekt zu vereinbaren.

Es wird in vielen Projekten (Beispiel Gesetze) nicht immer gelingen, zu allen relevanten sachlichen Faktoren Ansprechpartner zu finden, auf die man einwirken kann.

💡 Es ist pragmatisch, sich bei der oben aufgeführten Schnittstellenanalyse auf die sachlichen Faktoren zu konzentrieren. Bei der Analyse der Schnittstellen vom Projektteam zu den sozialen Faktoren helfen zahlreiche Methoden des Stakeholdermanagements. Bei einer Berücksichtigung der Stakeholder sowohl in einer Schnittstellenanalyse als auch in den verschiedenen Stakeholdermethoden wäre aus meiner Sicht die Redundanz sehr groß.

Stakeholdererwartungen im Kontext formaler Projektziele managen

Viele Projektleiter sehen Stakeholdermanagement nur als notwendiges Übel an. Dabei hat professionelles, frühzeitiges und regelmäßiges Stakeholdermanagement viele Vorteile, dass sich in der Regel der Zeitaufwand lohnt:

  • Besseres Management der formalen Projektziele im Kontext oft abweichender informeller Erwartungen, Verbesserung der Projektunterstützung und Reduktion von Widerständen (vor allem bei partizipativer Strategie):
    • Nützliche Erfahrung und Wissen der Stakeholder wird bei (regelmäßiger partizipativer) Einbindung oft bereitwilliger zur Verfügung gestellt.
    • Stakeholder erfahren **durch Einbindung Selbstwirksamkeit. Ownership für das Projekt und eine positive Bewertung am Ende wird wahrscheinlicher.
    • Gleichzeitig wird die Entscheidungsfindung durch Vielfalt der Perspektiven (Schwarmintelligenz) verbessert.
    • Einige Projektziele entsprechen zu Beginn der Auftragsklärung bereits den Zielen der Stakeholder. Je mehr sinnvolle informelle Projektziele, die noch nicht Gegenstand des anfangs oft nur grob skizzierten Projektauftrags sind, in den Projektauftrag verhandelt werden, desto positiver wird die Bewertung des Projekts ausfallen.
    • Viele Stakeholder haben informelle Erwartungen, die aus verschiedenen Gründen nicht geäußert werden.
      • Wenn man mit einem Stakeholder spricht, geht es nicht darum, die „heimlichen“ Ziele direkt zu benennen: „Ich weiß, dass Sie eigentlich X wollen…“, sondern das Bedürfnis dahinter behutsam zu adressieren: „Ich merke, Ihnen ist wichtig, dass das Ergebnis auch intern gut kommunizierbar ist – wie können wir das unterstützen?“
      • Wenn die Bedürfnisse nicht bedient werden könnten, sollte man auf keinen Fall moralisch argumentieren, sondern sachlich: “Das Anliegen ist nachvollziehbar, fällt aber außerhalb des aktuellen Projektauftrags. Wir können es dokumentieren und ggf. als Ergänzung oder Empfehlung aufnehmen.“ Oder: “Ich sehe, dass Ihnen wichtig ist, dass das Thema X ausreichend berücksichtigt wird. Innerhalb des aktuellen Auftragsrahmens ist das nur begrenzt möglich, aber ich möchte sicherstellen, dass wir Ihre Perspektive an geeigneter Stelle sichtbar machen – z. B. in den Lessons Learned oder in einem Anschlussprojekt. Wäre das ein gangbarer Weg?“ Oder: “Wir müssen hier eine Balance halten zwischen X und Y – ich verstehe Ihren Punkt, möchte aber vermeiden, dass wir das Projektziel gefährden.“ So fühlt sich der Stakeholder gesehen, auch wenn sein Anliegen nicht erfüllt wird.
      • Oft kann man auf Basis der verfügbaren Informationen Bedürfnisse nicht direkt adressieren, auch nicht behutsam. Beispiel: “Ich weiß ja, dass sie sich das Projektscheitern wünschen, weil der Projektleiter von ihrem Intimfeind benannt wurde, mit dem sie um eine Top-Managementposition streiten.” In solchen Fällen sollte man aber dringend Annahmen treffen und diese auch gerne schriftlich zur Ableitung einer angemessenen Stakeholderstrategie notieren. Die Unterlagen des Stakeholdermanagements müssen genau aus diesem Grund vertraulich behandelt werden.
      • Je negativer die Einstellung zum Projekt und je größer das Konfliktpotenzial, desto wechselt die Einschätzung des Projektleiters von “vielleicht noch neutral in “Projektgegner”. Das lässt sich natürlich nicht wissenschaftlich exakt festlegen, sondern sind fließende Übergänge. Aber von dieser Einschätzung des Projektleiters ist natürlich auch abhängig, auf welchem Spektrum der Maßnahmen man sich bewegt. Obwohl das natürlich eine grobe Vereinfachung darstellt, dürfte man sich analog der Skala von neutral zu Projektgegner auf einer Maßnahmen-Skala von partizipativ zu diskursiv zu informativ, zu restriktiv und zu repressiv bewegen. Die noch neutral eingestellten Wackelkandidaten kann man ggf. noch für das Projekt gewinnen. Bei den Projektgegnern sollte man dieses Unterfangen eher aufgeben.
  • Verbessertes Konfliktmanagement und Vorteile im Beziehungsaufbau:
    • Konfliktprävention: Nach Studien entsteht die Hälfte aller Konflikte durch Missverständnisse aufgrund fehlender oder ungeschickter Kommunikation
    • Installation eines Frühwarnsystems für rechtzeitig Maßnahmen vor unnötiger Eskalation
    • Wirksamerer Umgang mit ausgebrochenen Konflikten: Regelmäßig gehörte Stakeholder fühlen sich wertgeschätzt und gehört, äußern deshalb ihre Bedenken offener und sind in Konflikten konstruktiver.
    • Verbesserung der oft über ein Projekt hinausgehenden langfristigen Beziehungen.

⚠️ Natürlich kann man auf Stakeholdermanagement auch ganz verzichten, wie es viele machen. Motto: “Ich kenne doch meine Pappenheimer”. Oder man macht Stakeholdermanagement nicht strukturiert sondern aus dem Bauch heraus. Dann ist die Gefahr aber recht groß, in eine Sympathiefalle zu tappen und sich verhältnismäßig intensiv mit Stakeholdern auseinanderzusetzen, mit denen man gut klarkommt, wo die Wellenlänge stimmt. Und dass man die eher unsympathisch erscheinenden Stakeholder trotz ihrer Macht wenig oder gar nicht zur Kenntnis nimmt. Strukturiertes Stakeholdermanagement bewahrt den Projektleiter auch davor, in diese Falle zu tappen.

Mit verschiedenen Quellen relevante Stakeholder identifizieren

Orientierung an Stakeholderdefinition: Natürlich können Beteiligung, Betroffenheit und Interesse zusammenfallen. Der gezielte Fokus auf einzelne Definitionsmerkmale kann bei der Identifikation der Stakeholder eine große Hilfe sein:

  • Beteiligt ist man als Teil des Projektteams (Orientierung am Organigramm).
  • Betroffen sind z.B. Endanwender, welche das Projektergebnis nutzen oder Abteilungsleiter, die Ressourcen zur Verfügung stellen. Vor allem hier kann das Lasten- und Pflichtenheft eine gute Unterstützung darstellen)
  • Interessiert ist man als Stakeholder ggf. nur ganz grundsätzlich am Projekt interessiert, ohne beteiligt oder betroffen zu sein.

Umfeldanalyse:

  • Falls in einer Umfeldanalyse soziale Faktoren (Stakeholder) identifiziert wurden, werden diese mindestens in die Stakeholderanalyse übertragen. Weil es sich bei der Umfeldanalyse um schnelle und grobe Analyse gehandelt hat, ist zu überlegen, ob man - zum Beispiel bei der Einführung einer Software - eine größere Gruppe “Endwender” (Umfeldanalyse) in Untergruppen aufteilt (Endanwender Internet Sales, Endanwender ERP usw.). Bei dieser Aufteilung muss immer überlegt werden, ob die Vorteile einer zielgruppenspezifischeren Ansprache in einem ausgewogenen Verhältnis zum damit verbundenen Mehraufwand stehen.
  • Bei einer vorheriger Umfeldanalyse kann man zudem die sozialen Faktoren als Basis zur Ableitung relevanter Stakeholder nehmen. Beispielsweise könnte bei der DSGVO als sachlichem Faktor der Datenschutzbeauftragte ein relevanter Stakeholder sein.

Prozessdiagramm: Hier kann man sich die Frage stellen, welche Stakeholder entlang der Prozesskette betroffen sind. Dabei kann man sowohl betroffenen fachlichen Prozesse analysieren als auch die betroffenen Projektmanagementprozesse. In vielen Organisationen finden sich leicht zugängliche Prozessketten, die zum Beispiel klickbar im Intranet abgelegt sind.

Auftraggeber: In meinen Projekten habe ich sehr gerne meinen Projektauftraggeber gefragt. Dieser ist aufgrund seiner Linienfunktion meist stärker “politisch” unterwegs als die Projektleitung und kann in der Regel wertvolle Tipps zu Promotoren und möglichen Opponenten geben. Um von Auftraggebern oder anderen Sparringspartnern mögliche Opponenten genannt zu bekommen, bietet sich auch “Reverse Thinking” mit zum Beispiel der folgenden Frage an: “Wer müsste überzeugt werden, damit das Projekt scheitert?”

Sparringspartner: Gerade beim Thema Stakeholder muss man einer Person vertrauen können, wenn man sich mit ihr über interne Stakeholder des Projekts unterhält. Gegenseitiges Vertrauen ist von Faktoren wie Glaubwürdigkeit, Verlässlichkeit und Vertrautheit abhängig und einer Reduktion der eigenen Selbstorientierung.

Lessons Learned: Eine der wertvollsten Informationsquellen waren für mich immer ehemalige Projektleiter vergleichbarer Projekte. In dieselbe Kategorie fallen Lessons Learned Unterlagen der Projekte. Leider machen sich nach meiner Erfahrung viele Organisationen mit sehr restriktiven Berechtigungskonzepten das Leben selber schwer. Wenn es Wochen dauert, bis der Projektleiter Zugang zu einschlägigen Unterlagen vergleichbarer Projekte bekommt, gibt der meist unter großen Zeitdruck stehende Projektleiter oft auf. Abgesehen davon sind die Unterlagen oft nicht selbsterklärend abgelegt, so dass man sich in der Regel auf die mündlichen Aussagen des verantwortlichen Projektleiters verlassen muss.

Informelle Machtstrukturen: Nicht nur das offizielle Organigramm ist eine wertvolle Informationsquelle. Über Soziogramm kann man sich eine übersichtliche Struktur schaffen, in der man abbilden kann, wer wie zu wem steht und wen man ggf. noch als relevanten Stakeholder beachten müsste. Wenn man berücksichtigt, dass nicht nur formelle Machtquellen sondern auch informelle Machtquellen eine starke Projektwirksamkeit entfalten können, kommt man nach bei der Betrachtung informeller Machtquellen in aller Regel auf zusätzliche Stakeholder, auf die man sonst nicht gekommen wäre.

In einer Stakeholdertabelle die identifizierten Stakeholder analysieren, bewerten und - je nach Methode - mit Strategien und Maßnahmen versehen

Stakeholder (= soziale Faktoren) haben Einfluss auf die Kosten, den Zeitplan, den Projektinhalt, die Ressourcen, das Ergebnis oder den wahrgenommenen Erfolg eines Projekts. Es kommt also beim erfolgreichen Stakeholdermanagement nicht nur auf Erreichung der formellen Ziele an, sondern auch um die Erreichung einer passenden Wahrnehmung und Erreichung informeller Ziele wichtiger Stakeholder. Stakeholder bezahlen für das Projekt, kaufen die Ergebnisse und arbeiten mit ihnen, übernehmen Führungsrollen und helfen bei der Umsetzung. Je unterstützender, mächtiger, effektiver und zugänglicher sie sind, desto mehr Beachtung sollte man Ihnen als Projektleiter schenken.

Erwartungen und Befürchtungen. Im klassischen Stakeholdermanagement geht es bei diesen Spaltenüberschriften darum, sich in die Perspektive des Stakeholders hineinzuversetzen. Es geht als nicht darum, was man als Projektleitung selbst vom Stakeholder erwartet. Sondern man versucht, zu antizipieren, was der Stakeholder oder die Stakeholdergruppe vom Projekt erwarten könnte.

Die Bezeichnung “Erwartungen und Befürchtungen” ist in der Projektwelt weit verbreitet, aber meiner Meinung nach nicht redundanzfrei. Erwartungen sind aus meiner Sicht neutral und können positiv oder negativ sein. Befürchtungen sind nur negativ. Wer sich an dieser begrifflichen Unschärfe stört, kann alternativ die Spalte auch mit dem Begriff “Interessen” überschreiben.

💡 In die Emotion gehen: Es ist nicht optimal, profane Erwartungen wie (Projekterfolg) als Erwartung anzugeben. Interessanter ist, durch Befragung oder durch Hineinversetzen die Bedürfnisebene des Stakeholders zu antizipieren, z.B. Angst vor Transparenz, Angst vor Karriereknick, Angst vor Autonomieverlust.

Beispiel: Der Abteilungsleiter IT moniert bei der Vorstellung einer möglichen PM-Software die schlechte Usability für seine Projektleitungen. Wenn man dann als Maßnahme ableitet, eine Software mit einer besseren Usability zu suchen, geht diese Maßnahme unter Umständen ins Leere. Zum Beispiel könnte sich hinter der Ablehnung des Abteilungsleiters IT seine Befürchtung verbergen, dass die systemaffine Geschäftsführung plötzlich eine transparenten Darstellung seiner IT-Projekte durch eine Projektmanagementsoftware erhält. Mit der Furcht vor schlechter Usability hätte das aber nichts zu tun. Auch wenn es wie in diesem Beispiel unter Umständen keine gute Idee ist, den Abteilungsleiter direkt auf seine mögliche Befürchtung anzusprechen und damit seine verdeckten Motive an die Oberfläche zu zerren, könnte man proaktiv ein restriktives Berechtigungskonzept ins Spiel bringen, über das zudem noch der Betriebsrat ein wachsames Auge hätte. Das wäre in diesem Beispiel die angemessenere Maßnahme. Der Schlüssel zu der zielgenauen Maßnahme ist wie gesagt die tatsächliche Bedürfnisebene.

💡 Verdeckte Motive sind meist stark verhaltenssteuernd. Sie werden nicht umsonst oft mit allen Mitteln verdeckt gehalten. Zum Beispiel, weil sie gegen die formalen Ziele der eigenen Stelle oder sogar der Organisation gerichtet sind. Trotzdem oder gerade deshalb beeinflussen sie stark das Verhalten der Stakeholder und dürfen deshalb nicht vernachlässigt werden.

⚠️ Vertraulichkeit: Aus dieser Empfehlung folgt, dass man mit der schriftlichen Hinterlegung vor allem interner Stakeholder sehr sensibel umgehen muss. Am besten macht man das nur auf einem privaten oder verschlüsselten Laufwerk. Außerdem sollte man sich gut überlegen, ob man diese Überlegungen alleine anstellt oder als Gruppenarbeit. So wertvoll es auch ist, andere Sichtweisen auf einen Stakeholder zu bekommen und seine eigene Einstellung zu überdenken und seine Maßnahmen anzupassen, so groß ist auch die Gefahr, viel Porzellan zu zerschlagen und sich Stakeholder unnötig dauerhaft zum Feind zumachen, wenn ggf. negative Stakeholdereinschätzungen in offiziellen Projektdokumenten die Runde machen.

⚠️ Abgrenzung zur den formalen Zielen: Oft lässt sich eine gewisse Redundanz von Stakeholdererwartungen und den formalen Zielen nicht vermeiden. Trotzdem sollte man aus meiner Sicht eine klare methodische Trennung durchführen:

  • Die formalen Ziele werden mit den Methoden zur Auftragsklärung festgehalten. Wenn man möchte, kann man ja in einer sogenannten “Traceabiltiy-Matrix” festhalten, von wem die konkrete Anforderung in den Projektauftrag eingebracht wurde. So wäre z.B. die Erwartung eines “anwenderfreundlichen schlanken Projektmanagementbuches” sicher eher in der Zielmethode mit den formalen Projektzielen gut aufgehoben.
  • Die tatsächlichen Erwartungen (Steigerung der Quote erfolgreicher Projekte und Erhöhung der Karrierechancen) oder Befürchtungen (Erhöhung des Arbeitsaufwands durch Ausfüllen überflüssiger Formulare) liegen auf der informellen Ebene und gehören deshalb eher in die Stakeholdermethode.
  • Trotzdem sollte man natürlich als Projektleiter versuchen, so weit wie möglich auf die Erwartungen und Befürchtungen einzugehen und diese (noch) informellen Projektziele in formelle Projektziele umzuwandeln. Wie schon gesagt wird ein Projekt oft nur dann als erfolgreich eingestuft, wenn auch die informellen Ziele erreicht worden sind.
  • In der Praxis kann man es aber nicht allen Stakeholdern recht machen. In Projekten prallen verschiedene Interessen aufeinander. Je größer die Diskrepanz zu den verabredeten formalen Projektzielen wird, desto negativer könnte die Einstellung zum Projekt werden und umso höher könnte das sogenannte “Konfliktpotenzial” des betroffenen Stakeholders sein (siehe unten). Deshalb sollte man sich auch immer zuerst mit der Analyse der Interessen beschäftigen und dann erst mit der Zuweisung von Attributen wie “Konfliktpotenzial”.

Die Einstellung zu einem “Einstellungsobjekt” drückt sich dadurch aus, ob man auf das Einstellungsobjekt mit Zuneigung oder Ablehnung bewertet oder behandelt.

Obwohl “Einstellung” weniger komplex ist als das Attribut “Konfliktpotenzial” spricht einiges dafür, es zusätzlich zu analysieren und in der Tabelle aufzunehmen:

  • Bei der Identifikation nützlicher Machtpromotoren (siehe unten) ist ein schneller Check in der Tabelle möglich, ob der identifizierte mächtige Stakeholder überhaupt ein Promotor ist. Ohne eine positive Einstellung ist er das nämlich nicht.
  • In Projekten mit vielen Stakeholdern ist es oft effizient, mit der Methode “Stakeholderportfolio” das Stakeholdermanagement zu vereinfachen. Oft muss man sich entscheiden, ob man neben dem Attribut “Macht” das Attribut “Konfliktpotenzial” oder das Attribut “Einstellung” verwendet. In einigen Projekten hat das Attribut “Einstellung” durchaus seine Existenzberechtigung (siehe weiter unten)

Konfliktpotenzial wird als die Wahrscheinlichkeit bezeichnet, mit einem Stakeholder oder einer Stakeholdergruppe in Konflikt zu geraten. Das Konfliktpotenzial wird von mehreren Faktoren beeinflusst und ist deshalb als komplexer als das Attribut Einstellung:

  • Geraten die Interessen, die informellen Projektziele des Stakeholders mit den formellen Zielen des Projekts in Konflikt?
  • Wie ist die Einstellung zum Projekt? *Natürlich könnte man argumentieren, dass man diesen Aspekt schon mit den Stakeholderinteressen abgedeckt hat. Dann wäre dieses Attribut redundant. Trotzdem: Es ist gar nicht so selten, dass ein Stakeholder weder besondere Erwartungen noch Befürchtungen in Bezug auf ein Projekt hat. Und trotzdem hat er eine negative Einstellung zum Projekt entwickelt, warum auch immer. Dann sollte man das in seine Einschätzung einfließen lassen.
  • Ist der Stakeholder wegen seiner Persönlichkeit schnell bereit, Konflikte einzugehen? Ist er eher ausgleichend oder aufbrausend?
  • Erhöht seine Rolle (z.B. Auftraggeber, Controller) für Wahrscheinlichkeit von Konflikten? Aus der komplexen Kombination dieser Attribute leitet man als Projektleitung eine Gesamtbewertung ab.

💡 Sowohl für Einstellung als auch Konfliktpotenzial empfehle ich eine “digitale Bewertung”, also “positiv oder negativ” bei der Einstellung oder “hoch oder niedrig” beim Konfliktpotenzial. Oft wird argumentiert, dass das nur grob sei und man Abstufungen vornehmen müsse:

  • Ich halte dann immer mit dem Argument dagegen, dass man erst mal einfach anfangen sollte. Meist hat man ja noch nie schriftliches Stakeholdermanagement gemacht und man muss nicht gleich von 0 auf 100 gehen. Oft wird ja auf diese Methode mit dem Argument “nicht nötig” verzichtet, weil man ja angeblich “seine Pappenheimer” kenne.
  • Außerdem ist erfahrungsgemäß bei der Einschätzung psychologischer Aspekte wie Einstellung oder Konfliktpotenzial mit einer Abstufung von z.B. 1-5 eine Pseudpräzision erreicht und noch dazu ein unnötiger Aufwand erzeugt. Ich empfehle einen einfachen Start mit einer digitalen Bewertung. Dabei kann man ja in einem Worst Case Szenario erst mal vom schlimmsten Fall ausgehen und seine Strategie und Maßnahmen darauf einstellen. Wenn sich die erste Einschätzung später als falsch herausstellt, kann man seine Bewertung und Maßnahmen ja immer noch anpassen.

Macht nach dem Soziologen Max Weber die die Chance, innerhalb einer sozialen Beziehung den eigenen Willen auch gegen Widerstand anderer durchzusetzen.

Macht bzw. dem Ausüben von Macht wird oft eine negative Bedeutung zugeordnet. Dabei ist das Ausüben von Macht für Führungskräfte legitim bzw. Grundvoraussetzung für ihre Führungsrolle. Wenn die Macht “sozialisiert” ist, also zugunsten des eigenen Teams oder der Organisation eingesetzt wird, ist gegen die Machtausübung ohnehin auch ethisch-moralisch nichts einzuwenden. Projektleiter sind auch Führungskräfte. Insofern ist es völlig normal und in Ordnung für einen Projektleiter, verfügbare Machtquellen anzuzapfen.

Das aktive Ausüben von Macht wird beim Thema “Führung” behandelt. Hier nur der Hinweis, dass je nach Projektorganisation die Projektleitung eher auf informelle Machtquellen (Einfluss-Projektorganisation) oder auf formelle Machtquellen (Matrix-Projektorganisation, autonome Projektorganisation) zurückgreifen kann.

Bei der Stakeholderanalyse geht es nicht um das aktive Ausüben von Macht durch die Projektleitung. Sondern darum, zu analysieren, welche Machtquellen den Stakeholdern zur Verfügung stehen und wie viel Macht sie in Bezug auf das Projekt haben. Nach der Einschätzung der Machthöhe (hoch, niedrig) stellen sich für die als mächtig eingestuften Stakeholder die folgenden Fragen:

  • Wie kann der mächtige Stakeholder seine Machtquelle zugunsten (oder zu Ungunsten) des Projekts nutzen?
  • Wie kann ich als Projektleiter den mächtigen Stakeholder im Fall seiner positiven Einstellung (Machtpromotor) unterstützen oder im Falle einer negativen Einstellung (Opponent) die Machtquellen in ihrem Wirkungspotenzial reduzieren.

Nutzung der Kraftfeldanalyse zur Identifikation von Promotoren und Opponenten

Die Kraftfeldanalyse ist eine Methode zur Ermittlung von treibenden und rückhaltenden Kräften. Solche Kräfte können z.B. Stakeholder in Projekten sein. Schritte:

  • Sachverhalt definieren, z.B. Projekt
  • Kräfte identifizieren, z.B. Stakeholder
  • Kräfte bewerten, z.B. Promotoren mit viel Macht. Machtpromotoren haben eine positive Einstellung zum Projekt und viel strukturelle und/oder persönliche Macht. Sie können sich mit Fachpromotoren überschneiden, die ihre große Macht vor allem aus ihrer besonderen fachlichen Expertise zu ausgewählten Themen des Projekts beziehen.
  • Maßnahmen ableiten (z.B. Machtpromotoren für eigene Zwecke gewinnen)

Machtquellen formell Machtquellen informell Die Projektleitung sollte die mächtigen Projektopponenten kennen. Aber auch Machtpromotoren identifizieren können, weil sie sie im Projekt unterstützen können. Maßnahmen zur Veränderung der Macht (insbesondere zur Reduktion) wird oft aus ethisch-moralischen Gründen kritisch gesehen. Maßnahmen zur Veränderung bei Stakeholdern sollten deshalb eher z.B. auf der Einstellung basieren.

Unterschiedliche Definitionen in der Praxis Machtpromotoren werden oft definiert als Personen, die aufgrund ihrer hierarchischen Position Widerstände überwinden können. Obwohl nach dem hier dargestellten Modell der Machtquellen ein Promotor nicht unbedingt strukturelle Macht haben muss, sondern ggf. „nur“ persönliche Macht.

Fachpromotoren sind ein etwas engerer Begriff. Sie basieren in der erster Linie auf dem Experten-Know-how. Wenn der Fachpromotor gleichzeitig noch viele strukturelle Machtquellen anzapfen kann, ist er gleichzeitig auch Machtpromotor.  

Tipps zur Auswahl und Gewinnung von Promotoren siehe Vertiefung

Networking und Allianzen: Netzwerke und Allianzen (Bündnisse) dienen in Projekten primär dazu, Ressourcen zu bündeln und Risiken zu minimieren, die ein einzelner Akteur allein nicht bewältigen könnte. Beispiele:

  • Ressourcen- und Wissensaustausch: Sie erhalten Zugriff auf spezialisiertes Fachwissen, Technologien oder Arbeitskräfte, die intern nicht verfügbar sind.
  • Risikoteilung: In komplexen Projekten werden finanzielle Lasten und das Scheiternsrisiko auf mehrere Schultern verteilt.
  • Erhöhte Innovationskraft: Durch die Vielfalt unterschiedlicher Perspektiven und Ideen entstehen oft kreativere Lösungen als in isolierten Teams.
  • Beschleunigung & Marktzugang: Strategische Allianzen ermöglichen es, neue Märkte schneller zu erschließen oder Projektphasen durch Arbeitsteilung zu verkürzen.
  • Legitimität und Einfluss: Ein starkes Netzwerk (z. B. eine strategische Allianz) stärkt die Verhandlungsposition gegenüber Stakeholdern und verbessert das Ansehen des Projekts.

Networking: Beim Networking geht es um den Aufbau und die Pflege von langfristigen Kontakten, die auf gegenseitigem Vertrauen und Unterstützung basieren. Im Kern ist es der gezielte Austausch von Informationen, Wissen und Ressourcen, um berufliche oder private Ziele leichter zu erreichen (Beispiel: Netzwerktreffen von Projektleitern in Fachgruppen der Gesellschaft für Projektmanagement). Es ist kein einmaliges „Sammeln von Visitenkarten“, sondern ein fortlaufender Prozess des Beziehungsmanagements.

Allianzen oder Bündnis: Im Gegensatz zum Networking ist eine Allianz bzw. Bündnis formeller und eine oft vertraglich geregelte Verbindung, um ein gemeinsames Ziel zu erreichen (Beispiel Arbeitsgemeinschaft). Sie enden in der Regel nach Zielerreichung, während ein Netzwerk eher auf Dauer ausgerichtet ist.

Erläuterung der Machtquellen im Detail siehe Vertiefung

Stakeholderstrategien

Partizipative Strategie

  • Kernidee: Stakeholder als Mitgestalter / Partner, Einbeziehung in Entscheidungsfindung
  • Kommunikationsform: bilateral, kollaborativ
  • Ziel: Interessen aktiv integrieren, Commitment erzeugen, Widerstände reduzieren
  • Aufwand: hoch (Zeit, Moderation, Entscheidungsprozesse)
  • Typische Anwendung:
    • hohe Macht + hohes Konfliktpotenzial
    • komplexe Change-Projekte
    • wenn Akzeptanz erfolgskritisch ist
  • Nutzen/Chancen:
    • erzeugt Ownership und Verantwortungsgefühl beim Stakeholder
    • macht versteckte Ziele früh sichtbar
  • Risiken/Nachteile:
    • Entscheidungsprozesse können langsamer werden
    • Gefahr von Erwartungsüberhöhung

Beispiele partizipative Einzelmaßnahmen

  • Mitgestalten lassen
    • Stakeholder werden bereits in der Planungsphase eingeladen, Projektziele mitzuformulieren
    • Workshops zur gemeinsamen Anforderungserhebung (World Café, Design Thinking, Projekt Canvas)
    • Prototypen oder Zwischenergebnisse werden frühzeitig zur gemeinsamen Überarbeitung vorgelegt
    • Rohfassungen von Konzepten, Plänen oder Materialien werden gezielt zur Kommentierung freigegeben – bevor sie finalisiert werden.
    • Ein Ideenboard oder digitales Kollaborationstool (z. B. Miro) steht allen offen
    • Board mit Spalten „Ideen”, „In Prüfung”, „Beschlossen” – Stakeholder können jederzeit, auch asynchron, Ideen und Kommentare einbringen.
  • Gemeinsam entscheiden
    • Entscheidungsrelevante Stakeholder sind in Steuerungskreisen oder Lenkungsausschüssen vertreten
    • Regelmäßige Steuerrunden mit fester Agenda und klar ausgewiesenen Entscheidungspunkten – keine reinen Informationsrunden.
    • Es gibt klar definierte Mitentscheidungsrechte (Konsent- oder Konsensprinzip)
    • Entscheidungsprotokolle werden transparent dokumentiert und geteilt
  • Commitment erzeugen
    • Stakeholder unterzeichnen eine gemeinsam erarbeitete Projekt- oder Zielvereinbarung
    • Ein kurzes Dokument mit Projektzielen, Budget, Rollen und gegenseitigen Erwartungen – von allen relevanten Parteien unterzeichnet. Schafft Verbindlichkeit auf Augenhöhe.
    • Beiträge von Stakeholdern werden sichtbar gemacht und anerkannt
    • Stakeholder werden zu Meilensteinfeiern eingeladen und aktiv eingebunden, z.B. Halbzeit-Runde nach Abschluss der Planungsphase: Stakeholder präsentieren selbst Teilergebnisse – stärkt Identifikation und Eigenverantwortung.
    • Ein gemeinsames Projektbild (Vision, Ziele) wird erarbeitet und sichtbar kommuniziert
    • Einen gemeinsam formulierten Leitsatz oder eine Projektmission entwickeln und auf allen internen Dokumenten und in Meetings sichtbar halten.

💡 Grundsätzlicher Hinweis: Die Beispiele für die Einzelmaßnahmen für die partizipative Strategie und die noch folgenden Strategien sollten nicht als Checkliste verwendet werden, sondern sind nur dazu gedacht, sich die Inhalte der jeweiligen Strategie besser vorstellen zu können. In den meisten Projekten ist es wichtig, sich sehr spezifische zum Projekt passende Maßnahmen zu überlegen.

Diskursive Strategie

  • Kernidee: Dialog, aber ohne Mitwirkung oder Mitentscheidung
  • Kommunikationsform: bilateral, feedbackorientiert
  • Ziel: Verbesserung der Informationslage + selektive Berücksichtigung der Wünsche, sofern kein großer Aufwand
  • Aufwand: mittel
  • Typische Anwendung:
    • Wenig Macht + hohes Konfliktpotenzial
    • Stakeholder ernst nehmen, aber ohne formale Beteiligung
  • Nutzen/Chancen:
    • ermöglicht Korrekturen ohne großen Aufwand
    • reduziert Missverständnisse und Eskalationen
    • integriert „Low Hanging Fruits“ von Stakeholdern
  • Risiken/Nachteile:
    • Stakeholder fühlen sich ggf. nicht ernst genommen („Man hört uns, aber entscheidet allein“)
    • eignet sich schlecht bei starker persönlicher Betroffenheit

Beispiele Einzelmaßnahmen

  • Dialog ohne formale Mitentscheidung
    • Regelmäßige Dialogformate werden etabliert, z. B. bilaterale Gespräche, Stakeholder-Interviews oder moderierte Diskussionsrunden – mit dem Ziel, Perspektiven zu verstehen, nicht zwingend Beschlüsse zu fassen.
    • Der Rahmen des Dialogs wird vorab klar kommuniziert. Stakeholder wissen: Ihre Meinung wird gehört und ernsthaft geprüft – aber die finale Entscheidung liegt bei der Projektleitung. Keine falschen Erwartungen wecken.
    • Informelle Gesprächsformate ergänzen die formalen Kanäle, z. B. kurze Einzelgespräche vor oder nach Meetings, um Bedenken abzuholen, die im Plenum nicht geäußert werden.
  • Selektive Berücksichtigung der Wünsche: Eingegangene Rückmeldungen werden systematisch bewertet. Jeder Stakeholder-Input wird anhand von Kriterien geprüft: Passt es zu den Projektzielen? Ist es umsetzbar? Welche Auswirkungen hätte es? – keine willkürliche Auswahl.
  • Priorisierung erfolgt transparent und nachvollziehbar: Es wird kommuniziert, welche Wünsche warum einfließen und welche nicht.

Informativ

  • Kernidee: Stakeholder erhalten Informationen, leisten aber keinen Input
  • Kommunikationsform: unilateral
  • Ziel: Transparenz, Erwartungsmanagement, Vermeidung von Gerüchten
  • Aufwand: gering
  • Typische Anwendung:
    • geringe Macht + geringes Konfliktpotenzial
    • breite Stakeholdergruppen (Newsletter, Boards)
  • Nutzen/Chancen:
    • hält alle „abgeholt“ ohne Energieverlust
    • verhindert Informationsvakuum und Spekulation
    • unterstützt Legitimität des Projekts
  • Risiken/Nachteile:
    • wenig Einfluss auf Einstellungen
    • keine Möglichkeit, Konflikte früh zu erkennen
    • kann bei Betroffenen als „Alibi-Transparenz“ wirken

Beispiele Einzelmaßnahmen

  • Unilateral informieren

    • Regelmäßige Projekt-Updates werden strukturiert und terminiert versandt, z.B. monatlicher Newsletter oder Status-Mail mit festen Rubriken: Fortschritt, nächste Schritte, offene Punkte – kein Fließtext, sondern schnell erfassbar.
    • Ein zentrales Informationsmedium wird als „Single Source of Truth” etabliert, z. B. eine Projektseite im Intranet, ein geteiltes Dokument oder ein schwarzes Brett – alle Stakeholder wissen, wo sie den aktuellen Stand finden.
    • Informationen werden zielgruppengerecht aufbereitet. Nicht alle erhalten dieselbe Detailtiefe: Führungsebene bekommt eine Kurzübersicht, operative Beteiligte erhalten relevante Detailinformationen – gleiche Kernbotschaft, unterschiedliche Aufbereitung.

  • Transparenz & Erwartungsmanagement

    • Meilensteine und Entscheidungen werden proaktiv kommuniziert – nicht nur auf Nachfrage. Stakeholder erfahren Projektergebnisse nicht zufällig oder durch Dritte, sondern gezielt und rechtzeitig durch die Projektleitung.
    • Auch Verzögerungen, Änderungen und Rückschläge werden offen kommuniziert. Ehrliche Kommunikation verhindert Vertrauensverlust – kurze Erklärung was sich geändert hat, warum, und was als nächstes passiert.
    • Der Kommunikationsplan legt fest: Wer erhält was, wann und in welchem Format? Eine einfache Matrix schafft Klarheit und verhindert Lücken oder Doppelkommunikation.

  • Informationsvakuum vermeiden

    • Bei projektrelevanten Ereignissen wird unmittelbar informiert. Auch eine kurze Zwischenmeldung („Wir sind noch in Klärung, mehr folgt bis…”) ist besser als Schweigen – verhindert Gerüchte und Spekulation.
    • FAQ-Dokument wird laufend gepflegt und geteilt. Häufig gestellte Fragen werden gesammelt und regelmäßig aktualisiert – reduziert Rückfragen und gibt Stakeholdern Orientierung.
    • Kommunikation erfolgt auch bei „nichts Neuem”. Ein kurzes „Alles läuft planmäßig” ist eine aktive Botschaft – Stille wird von Stakeholdern oft als Problem interpretiert.

  • Risiko „Alibi-Transparenz” vermeiden

    • Informationen sind inhaltlich substanziell – nicht nur formell. Nicht nur Termine und Logos kommunizieren, sondern echten Projektstand, Herausforderungen und Begründungen für Entscheidungen teilen.
    • Tonalität ist sachlich und respektvoll – kein „Verlautbarungsstil”. Informationen werden so formuliert, dass Stakeholder sich ernst genommen fühlen – nicht wie Empfänger einer Pressemitteilung.
    • Rückkanal wird optional angeboten – auch wenn er nicht systematisch ausgewertet wird, z.B. Kontaktadresse oder Ansprechperson nennen: „Bei Fragen wenden Sie sich an…Das signalisiert Offenheit, ohne Beteiligungsprozesse auszulösen.

Repressiv, restriktiv

  • Kernidee: aktive Einschränkung störender Stakeholder
  • Kommunikationsform: wenig transparent / taktisch
  • Ziel: Konflikte eindämmen, Blockaden beseitigen, Machtdynamiken nutzen
  • Aufwand: variabel, meist hoch beim Konfliktmanagement
  • Typische Anwendung:
    • Abwendung eines hohen Schadens fürs Projekt
    • Ausnahmefälle, nicht als Standardstrategie
  • Formen:
    • Fakten schaffen (Timing, Ressourcen, Deadlines)
    • Gegenpromotoren einsetzen
    • Eskalation an Gremien / Sponsoren
    • restriktive Informationspolitik
  • Risiken/Nachteile:
    • eskalationsanfällig
    • kann langfristig Vertrauen zerstören
    • ethisch und strategisch heikel
    • häufig Nebenwirkungen auf Kultur und Stakeholdernetzwerk

Beispiele Einzelmaßnahmen Hinweis vorab: Die repressive Strategie ist ausdrücklich eine Ausnahmestrategie – einzusetzen, wenn andere Strategien versagt haben oder ein erheblicher Projektschaden droht. Jede Maßnahme sollte vorher kritisch auf ethische Vertretbarkeit geprüft werden.

  • Ausnahmecharakter sicherstellen

    • Der Einsatz wird bewusst entschieden – nicht aus Ungeduld oder Bequemlichkeit. Vor jeder repressiven Maßnahme wird geprüft: Wurden partizipative oder diskursive Ansätze ernsthaft versucht? Ist der drohende Schaden tatsächlich erheblich?
    • Der Einsatz wird intern dokumentiert und begründet. Warum wurde diese Maßnahme gewählt? Welche Alternativen wurden verworfen? Eine kurze Aktennotiz schützt die Projektleitung und schafft Nachvollziehbarkeit. Bitte diese Informationen nicht ins Projektlaufwerk stellen sondern als persönliche Aktennotiz für den Fall einer Rückfrage vom Auftraggeber aufheben.
    • Die Maßnahme ist zeitlich begrenzt und auf den Einzelfall bezogen. Repressive Mittel werden nicht zur Gewohnheit – sie haben ein klares Ziel, einen definierten Zeitraum und ein Ende.

  • Fakten schaffen

    • Entscheidungen werden zu einem Zeitpunkt getroffen, an dem störende Stakeholder nicht eingreifen können. Z. B. Beschlüsse in Gremien herbeiführen, bevor ein Widerstand sich organisiert – bewusster Einsatz von Timing als taktisches Mittel.
    • Ressourcen oder Budgets werden frühzeitig gebunden. Verträge, Beauftragungen oder Reservierungen werden so früh abgeschlossen, dass eine spätere Einflussnahme faktisch keinen Effekt mehr hat.

  • Deadlines werden als strukturelles Argument genutzt. Externe Fristen (rechtlich, vertraglich, saisonal) werden sichtbar gemacht, um Verzögerungen durch Widerstand faktisch zu entkräften.

  • Gegenpromotoren einsetzen

    • Einflussreiche Fürsprecher werden gezielt aktiviert. Stakeholder mit hoher Akzeptanz und Glaubwürdigkeit werden gebeten, das Projekt aktiv zu vertreten – besonders gegenüber kritischen Gruppen. Fürsprecher sollten authentisch und nicht als verlängerter Arm der Projektleitung agieren.

  • Restriktive Informationspolitik

    • Informationen werden gezielt dosiert – nicht willkürlich zurückgehalten. Bestimmte Details werden erst dann kommuniziert, wenn der richtige Zeitpunkt oder Entscheidungsstand erreicht ist – mit nachvollziehbarer Begründung.
    • „Need to know” wird als Prinzip transparent gemacht: Stakeholder wissen, dass nicht alle Informationen für alle zugänglich sind – und warum. Heimlichkeit ohne Erklärung erzeugt mehr Misstrauen als dosierte Offenheit.
    • Die Grenze zur Täuschung wird nie überschritten: Informationen zurückhalten ist taktisch vertretbar – aktiv falsche Informationen streuen ist es nicht. Diese Grenze ist nicht verhandelbar.

  • Abgleich mit ethisch-moralischem Kompass. Vor jeder Maßnahme prüfen: Würde ich das öffentlich vertreten können? Der „Zeitungstest”: Wäre diese Maßnahme, wenn sie morgen in der Zeitung stünde, vertretbar und erklärbar?

  • Langfristige Beziehungsschäden werden in die Entscheidung einbezogen. Kurzfristiger Projekterfolg durch repressive Mittel kann langfristige Zusammenarbeit, Reputation und Teamkultur beschädigen – diese Kosten werden explizit abgewogen.

Eine Reflexionsrunde nach dem Einsatz sollte Standard sein. Was hat die Maßnahme ausgelöst? Welche Nebenwirkungen sind entstanden? Was würde man beim nächsten Mal anders machen?

💡 Bei einer überschaubaren Zahl an Stakeholdern (oft in kleineren Projekten) ist es oft völlig ausreichend, flexibel die Strategien und darauf basierenden Maßnahmen jedem einzelnen Stakeholder zuzuordnen, wenn das im einzelnen Projekt sinnvoll erscheint. Die Arbeit mit der Stakeholdertabelle ist dann völlig ausreichend.

💡 Die operativen Einzelmaßnahmen passend zur gewählten Strategie, passend zum Stakeholder und individuell passend zum Projekt beschreiben.

Abgrenzung “informativ” und “restriktiv”: “Restriktiv” kann auch als Untergruppe der repressiven Strategie bezeichnet werden. Wie kann aber die restriktive Strategie von der informativen Strategie abgegrenzt werden? Das Kernproblem ist, dass beide Strategien mit Informationssteuerung arbeiten – die eine durch Weitergabe, die andere durch Zurückhaltung. Der Unterschied liegt im Warum und Gegenüber wem. Praxistaugliche Leitfrage für die Projektleitung: „Würde ich diese Entscheidung (was ich kommuniziere / nicht kommuniziere) offen im Lenkungsausschuss begründen können?”:

  • Ja: Informative Logik (Transparenz schaffen, neutral / wohlwollend, Empfänger, die abgeholt werden sollen, Auswahl Info je nach Relevanz für Stakeholder, regelmäßig und proaktiv, symmetrisch: alle vergleichbaren Gruppen erhalten Gleiches).
  • Nein: Restriktive Logik (Einfluss einschränken, taktisch und Selbstschutz, Opponenten, die gebremst werden sollen, Auswahl Info nach taktischen Kalkül gegen den Stakeholder, situativ und reaktiv, keine Symmetrie sondern gezielt selektiv gegenüber Einzelnen oder Gruppen)

💡 Bei einer großen Zahl von Stakeholdern (oft in größeren Projekten) kann ein Stakeholderportfolio hilfreich sein:

Mit einem Stakeholderportfolio für Übersicht und Effizienz im Stakeholdermanagement sorgen

Zunächst werden die Stakeholder entsprechend ihrer Attribute (z.B. Konfliktpotenzial und Macht) aus der Tabelle in das Portfolio übernommen. Alternativ könnte man auch z.B. “Einstellung” und “Macht” nehmen. Einstellung schwankt oft stärker und in bestimmten Projekten (z.B. Changeprojekten) mag eine zeitnahe Anpassung dieses Attributs sinnvoll sein. Konfliktpotenzial ist auf der anderen Seite ein komplexeres und gleichzeitig oft auch stabileres Attribut, welches von vielen Faktoren abhängig ist. Eine veränderte Einstellung wirkt sich z.B. nicht automatisch auf ein verändertes Konfliktpotenzial aus, weil es noch von anderen Faktoren abhängig ist. Vielleicht ist einem eine gewisse Stabilität wichtig, weil man nicht ständig seine Stakeholderstrategie anpassen muss.

Anschließend wird jedem Portfoliobereich ganz grundsätzlich passend erscheinende Stakeholderstrategie zugeordnet. Weil sich in der Praxis die Arbeit mit 4 Portfoliobereichen bewährt hat, spricht man dann auch gerne von “Quadrantenstrategien”. Die Zuordnung einer Strategie zu einem Quadranten bedeutet, dass alle Stakeholder, die sich in diesem Quadranten aufgrund ihrer Attributskombination befinden, mit derselben Strategie bearbeitet werden.

Im folgenden werden mehrere Varianten in der Praxis unterschieden, anbei nur ein paar Beispiele:

  • Jede Strategie wird in einer Tabelle genau mit den konkreten Maßnahmen beschrieben. Alle Stakeholder erhalten dann mehr oder weniger diese eine - genau spezifizierte - Strategie. In die Stakeholdertabelle wird nur noch die zugeordnete Strategie eingetragen. Auf eine weitere differenzierte Darstellung einzelner Stakeholdermaßnahmen wird verzichtet, selbst wenn das zu zu größeren Streuverlusten führt. Nach meiner Erfahrung in Großprojekten ist das aber bei einer großen Zahl von Stakeholdern pro Quadrant ein pragmatischer Ansatz.
  • Die aufwändigste Methode ist, in der Tabelle nochmal für jeden einzelnen Stakeholder auf Basis der Grundstrategie individuell Einzelmaßnahmen zuzuordnen. Das mag inhaltlich oft gerechtfertigt sein: Für einen Stakeholder bedeutet “partizipativ” natürlich etwas anderes als für einen anderen Stakeholder. Aber diese Variante ist natürlich sehr zeitintensiv und aus meiner Sicht ab einer gewissen Stakeholderzahl kaum zu bewältigen. Nichts desto trotz ist diese Variante in der ein oder anderen Zertifizierungsvariante gerne gesehen. Aus meiner Sicht weniger deshalb, weil es sich in der Praxis wirklich bewährt, sondern eher deshalb, um die ganze methodische Palette prüfen zu können.

💡 Unabhängig von diesen Varianten sollte es immer möglich sein, bei einzelnen Stakeholdern Ausnahmen von der zugeordneten Grundstrategie zu machen, um flexibler zu bleiben. Je mehr Ausnahmen man aber formuliert, desto mehr sollte man sich überlegen, ob man die Portfoliotechnik überhaupt benötigt oder nicht doch besser mit einer flexiblen Tabelle arbeitet.

💡 Letztlich ist es für die Praxis egal: Jeder Projektleiter muss eine für ihn stimmige Variante verwenden, die immer einen Kompromiss aus Zielgenauigkeit von Strategie und Maßnahmen und methodischen Aufwand darstellt.

Stakeholder: Vertiefung

Schnittstellenmanagement

Das „Projektsystem“ und das „Umfeldsystem“ prallen mit eigenen Interessen an den Schnittstellen aufeinander. Beide Systeme versuchen, sich zu optimieren bzw. ihre Interessen durchzusetzen. Daraus können sich Spannungen ergeben.

💡 Deshalb ist es meistens eine gute Idee, mit den relevanten Stellen des Umfeldsystems “Schnittstellenvereinbarungen” zu treffen, um das Projektumfeld sinnvoll in das Projekt zu integrieren. Beispiel: Wenn z.B. klar verabredet wird, wann ein Mitarbeiter des Controllings hinzugezogen wird und welche Tätigkeiten von ihm und welche durch die Projektleitung durchgeführt werden, kommen Spannungen mit dem Projektumfeld oft erst gar nicht auf. Die Aufmerksamkeit wird weg gelenkt von der Durchsetzung der eigenen Interessen und hin zu der Beachtung der vereinbarten Spielregeln.

Die Schnittstellenvereinbarung kann durch methodisch durch verschiedene Instrumente unterstützt werden. Für die sachlichen Faktoren z.B. durch eine Schnittstellenanalyse, für die sozialen Faktoren durch verschiedene Methoden des Stakeholdermanagements.

Abgrenzung direkte und indirekte Beeinflussung in der Umfeldanalyse

Abgrenzung von indirekter und direkter Beeinflussung siehe

  • Direkt beeinflussbar = Ich kann durch gezielte Maßnahmen die Haltung oder das Verhalten des (sozialen) Faktors kurz- bis mittelfristig ändern. Beispiel: Anwohner beschweren sich über Baulärm. Maßnahme: Baustellenzeiten anpassen, Lärmschutzwände. Die Einstellungsänderung erfolgt meist schnell und kann leichter gemessen werden.
  • Mittelding: Es gibt natürlich auch sachliche Faktoren, die teilweise direkt beeinflussbar sind wie z.B. lange Lieferzeiten Hardware durch frühe Bestellung, Express-Logistik. Wie ein Segel im Wind: Ich kann die Segelstellung ändern, aber nicht den Wind stoppen.
  • Nicht direkt beeinflussbar = Der Faktor ist Rahmenbedingung. Ich kann mich daran anpassen oder ihn allenfalls langfristig indirekt beeinflussen, aber nicht kurzfristig steuern.
    • Beispiel: CO2-Gesetze treten in Kraft / Trend zu mehr Klimaschutz. Projektbudget und Design (mehr Radwege) kann angepasst werden, aber der Gesetzgebungsprozess kann nicht kurzfristig verändert werden. Langfristige Maßnahmen könnten z.B. sein: Marketing- und Lobbyarbeit mit Branchenverbänden, Teilnahme an Studien und politischen Initiativen. Wie Klimawandel: Ich kann mich anpassen und über viele Jahre Einfluss nehmen, aber nicht sofort den Trend umkehren.
    • Beispiele: Ein existierendes Prozesshandbuch definiert Abläufe. Das Handbuch wirkt auf das Projekt. Niemand aus dem Projektteam kann das kurzfristig ändern.

⚠️ Ganz sauber ist die Trennung zwischen indirekter und direkter Beeinflussung nicht:

  • Sachliche Faktoren können teilweise sehr wohl beeinflusst werden (z. B. Scope bei Scrum)
  • Soziale Faktoren sind nicht immer sofort steuerbar (Beispiel mächtige Top-Manager) Die Begriffe sind eher didaktische Vereinfachungen, um zu verdeutlichen:
  • Sachliches = systemische Rahmenbedingungen
  • Soziales = menschliche Interaktion

Ich würde bei der Analyse des Projektumfelds im Rahmen der Umfeldanalyse den Schwerpunkt auf die äußeren Faktoren legen, die Einfluss auf das Projekt haben. Bei den sachlichen Faktoren ist das oft kontextabhängig. Ein top-down vorgegebenes Budget ist sicher ein äußerer sachlicher Faktor, den man als Projektteam erst mal als Faktum hinzunehmen hat. Wenn sich das Budget aber bottom-up aus der Projektplanung heraus ergeben soll, ist das Budget sicher kein sinnvoller sachlicher Faktor.

Bei den sozialen Faktoren muss man wegen der Gleichsetzung als Stakeholder aus meiner Sicht eine gewisse Unschärfe in Kauf nehmen. So gehören z.B. Auftraggeber, Projektleitung und Projektteam zum Projekt. Sie werden aber dennoch als soziale Faktoren aufgeführt, obwohl sie streng genommen nicht zu “äußeren Einflussfaktoren” gezählt werden können, die das Projekt beeinflussen. Sie repräsentieren ja bereits das Projekt.

Agile Berichte

Ein klassisches „Berichtswesen“ findet sich im agilen Projektmanagement nicht. Sowohl das Vorgehen, also auch die Tools unterscheiden sich vom klassischen Projektmanagement. So gibt es z.B. im Framework Scrum verschiedene Meetings, wie das Daily Scrum, in dem sich das Entwicklungsteam vor allem synchronisiert und den Leistungsfortschritt prüft (z. B. mit einem Burn-down Chart, das oft der Scrum Master aktualisiert). Auch wenn in diesem Meeting der Product Owner oder auch Stakeholder dabei sein können, sind diese als Gäste und stille Zuhörer dabei, nicht als Berichtsempfänger. Ähnlich ist es im Meeting „Review“, in dem der Fokus gemäß den agilen Werten und Prinzipien auf dem Dialog und Feedback liegt, weniger auf einem „Bericht“, wo man steht und schon gar nicht, was man als Nächstes plant. Zusammenfassend wird in agilen Arbeitsweisen Transparenz und Offenheit in verschiedenen Formaten gefördert, um über wertschätzendes Feedback und persönliche Kommunikation Erkenntnisse für die weiteren Entwicklungsschritte zu erhalten.

Wahl und Gewinnung von Promotoren

Es ist wenig sinnvoll, nur den Auftraggeber als Machtpromotor zu benennen. Die Idee dieses Konzepts ist ja, bei ggf. entscheidungsschwachen Auftraggebern einen Verbündeten zu finden.

⚠️ Es kursieren in der PM-Literatur sogar Beispielsteckbriefe, in der zwei verschiedene Felder für den Auftraggeber und vorgesehen sind. Obwohl die im vorangehenden Absatz formulierte Idee scheinbar bestätigt wird, halte ich wenig davon, ein offizielles Feld im Steckbrief vorzusehen. Viele Machtpromotoren müssen aus politischen Gründen im Verborgenen wirken. Wenn man ihren Support nicht verlieren möchte, sollte man also auf solche Felder im Steckbrief verzichten.

💡 Gegen die Nutzung von Machtpromotoren im Sinne des Projekts ist nichts zu einzuwenden. Bei Machtpromotoren kommen und eine positive Einstellung zum Projekt zusammen. Bei einer negativen Einstellung spricht man von „Opponent“.

Machtpromotoren können i.d.R. nur helfen, wenn man bereits im Vorfeld des Projekts Networking betrieben und dabei sogenannte Networking-„Spielregeln“ beachtet hat:

  • Reziprozität kommt aus dem Lateinischen (Reziprocus - auf demselben Weg zurückkehren) und beschreibt einen tief verwurzelten psychologischen Mechanismus, dass Menschen sich verpflichtet fühlen, eine erhaltene Gefälligkeit zu erwidern.
  • Ein Beziehungsaufbau, der auf sofortige Verwertbarkeit der Beziehung aus ist, wirkt abschreckend. Oft wird in der Literatur deshalb empfohlen, seinen Networkingpartner (erst mal) ohne sofortige Gegenleistung zu unterstützen und eine Art psychologische Verpflichtung, eine Art “moralische Schuld” zu erzeugen. Dieses Verhalten soll die Bereitschaft erzeugen, im Projekt-Bedarfsfall Unterstützung zu bekommen.
  • Die aus der Gefälligkeit erzeugte Reziprozität kann aus meiner Sicht je nach Ausrichtung des ethisch-moralischen Kompasses als manipulativ empfunden werden. Es sollte natürlich nicht verboten sein, jemand einen Gefallen zu tun. Dabei sollte meines Erachtens aber nicht ein späterer Ausgleich Hauptmotivation für den Gefallen sein und der betroffene Stakeholder überwiegend unter Verwertungsaspekten betrachtet werden.
  • Eine aus Trainersicht sympathischere „Manipulationsvariante“ ist Projektmarketing, also das Überzeugen des potenziellen Machtpromotors, warum das Projekt für ihn und seinen Bereich auch von Vorteil ist.

Erläuterung der verschiedenen Machtquellen

Formelle Machtquellen

  • Hierarchische Position. Macht, die sich aus der offiziellen Stellung einer Person in der Organisationshierarchie ergibt und mit Weisungsbefugnis gegenüber nachgelagerten Einheiten verbunden ist. Projektbeispiel: Der CIO eines Konzerns steht an der Spitze der IT-Organisation und kann allen Abteilungsleitern direkt Anweisungen erteilen. In einem unternehmensweiten ERP-Einführungsprojekt kann er dem Projektleiter Vorrang vor laufenden Linienaufgaben einräumen.*
  • Entscheidungsbefugnisse: Formal zugewiesene Rechte, verbindliche Entscheidungen zu treffen – insbesondere über Budgets, Eskalationen und strategische Richtungsänderungen. Projektbeispiel: In einem Bauprojekt tritt während der Ausführungsphase ein unerwarteter Bodenbefund auf, der eine technische Zusatzmaßnahme erfordert. Diese verursacht Mehrkosten von 80.000 € und würde den Meilenstein um drei Wochen verschieben. Der Projektleiter hat laut Kompetenzregelung nur bis 20.000 € Entscheidungsbefugnis. Er muss die Entscheidung eskalieren – und solange der Auftraggeber nicht formal zugestimmt hat, darf die Maßnahme nicht beauftragt werden, obwohl jede Woche Verzögerung weitere Folgekosten erzeugt.*
  • Gesetzlich geregelte Mitspracherechte. Institutionell verankerte Beteiligungsrechte bestimmter Organe (z. B. Betriebsrat, Personalrat), die bei organisatorischen Veränderungen zwingend einzubeziehen sind. Projektbeispiel: Ein Automobilhersteller führt ein neues Schichtmodell in der Produktion ein. Ohne frühzeitige Einbindung des Betriebsrats kann die Umsetzung rechtlich blockiert werden; mit aktiver Unterstützung der Personalleitung gelingt eine konstruktive Einigung.
  • Moving Targets durch Auftraggeber: Die Möglichkeit des Auftraggebers, Projektziele, Anforderungen oder Prioritäten im Projektverlauf einseitig zu verändern – oft durch externe oder politische Einflüsse bedingt. Projektbeispiel: Ein Ministerium beauftragt die Entwicklung einer Bürger-App. Durch einen Regierungswechsel werden Funktionsumfang und Zielgruppe kurzfristig angepasst, was das Projektteam zur Neuplanung zwingt.
  • Fest vorgegebenes Budget: Ein politisch oder vertraglich fixierter Finanzrahmen, der nicht ohne weiteres angepasst werden kann und als harte Nebenbedingung das Projekthandeln begrenzt. Projektbeispiel: Ein gemeinnütziger Verein realisiert ein Bildungsprojekt mit EU-Fördermitteln. Das bewilligte Budget ist nicht verhandelbar; das Projektteam muss Leistungsumfang und Ressourceneinsatz konsequent priorisieren.*
  • Festgelegte Timeline & Meilensteine. Vertraglich, politisch oder strategisch fixierte Termine, deren Nichteinhaltung erhebliche Konsequenzen – rechtlich, finanziell oder reputationsbezogen – nach sich zieht. Projektbeispiel: Ein Pharmaunternehmen entwickelt ein Medikament mit regulatorisch festgelegtem Zulassungsdatum. Der externe Abgabetermin erzeugt klare Fokussierung und verhindert unnötige Scope-Erweiterungen.
  • Zusammensetzung & Entscheidungsschnelligkeit Steering Committee: Die strukturelle Ausgestaltung des Lenkungsausschusses – Größe, Hierarchieebene der Mitglieder und Entscheidungsmandat – beeinflusst maßgeblich, wie schnell und verbindlich Richtungsentscheidungen getroffen werden. *Projektbeispiel: In einem Transformationsprojekt eines Versicherungskonzerns besteht das kleine und schlagkräftige Steering Committee aus drei Vorstandsmitgliedern mit vollem Entscheidungsmandat. Eskalationen können so innerhalb von 48 Stunden verbindlich geklärt werden.

Informelle Machtquellen

  • Ausstrahlung / Charisma. Die persönliche Fähigkeit, durch Auftreten, Überzeugungskraft und emotionale Wirkung andere Menschen zu begeistern, zu motivieren und hinter einer Vision zu versammeln – unabhängig von formeller Autorität. *Projektbeispiel: Eine Führungskraft gewinnt durch überzeugende Präsentationen und authentisches Auftreten das Vertrauen eines skeptischen Fachbereichs und sichert so dessen aktive Mitarbeit.
  • Autoritäres Gehabe. Ein dominantes, wenig kompromissbereites Auftreten, das durch Entschlossenheit und Durchsetzungswillen kurzfristig Handlungsfähigkeit erzeugt, jedoch längerfristig Widerstände begünstigen kann. *Projektbeispiel: Bei einer drohenden Terminverfehlung in einem Bauprojekt setzt der Auftraggeber klar und unnachgiebig Prioritäten durch, löst bestehende Abstimmungsschleifen auf und bringt das Projekt wieder in den Takt.
  • Experten-Know-how: Macht durch überlegenes Fachwissen, das anderen fehlt und das die betreffende Person zur unverzichtbaren Ratgeberin in kritischen Fragen macht. *Projektbeispiel: Eine erfahrene Datenschutzexpertin wird frühzeitig in ein Digitalisierungsprojekt eingebunden. Ihr spezifisches Wissen verhindert kostspielige Nacharbeiten und verschafft ihr erheblichen informellen Einfluss auf Designentscheidungen.
  • Sozialintelligenz & Vernetzung: Die Fähigkeit, Beziehungen gezielt aufzubauen und zu pflegen sowie durch ein breites Netzwerk Informationen, Unterstützung und Kooperationsbereitschaft zu mobilisieren. *Projektbeispiel: Eine Mitarbeiterin der internen Beratung kennt persönlich die Entscheidungsträger mehrerer Fachbereiche. In einem Projekt kann sie informelle Widerstände abbauen und Zusagen beschleunigen, die auf formalem Weg Monate dauern würden.
  • Sprache & Rhetorik: Die Fähigkeit, komplexe Sachverhalte klar, adressatengerecht und überzeugend zu kommunizieren – schriftlich wie mündlich – und dadurch Verständnis, Zustimmung und Handlungsbereitschaft zu erzeugen. *Projektbeispiel: Der zuständige Arbeitspaketverantwortliche präsentiert im Lenkungsausschuss drei komplexe technische Alternativen und empfiehlt eine davon. Durch seine Fähigkeit zur strukturierten, nicht-technischen Darstellung mit klaren Nutzenargumenten erhält das Projekt unmittelbar die Freigabe für die vorgeschlagene Wunschalternative des Projekts.
  • Moralischer Druck. Einfluss durch den Appell an gemeinsame Werte, ethische Verantwortung oder übergeordnete Ziele, der intrinsische Motivation und ein erhöhtes Verantwortungsgefühl erzeugt. *Projektbeispiel: Der Sponsor eines Hilfsprojekts für Erdbebenopfer appelliert im Kick-off an die persönliche Verantwortung jedes Teammitglieds. Die Folge ist eine merklich höhere Einsatzbereitschaft und geringere Fluktuation im Projektteam.