C0110

Begriffe rund um Integration (1177)

Um was geht’s?

Nachfolgend eine Übersicht von gängigen Begriffen rund um das Tun, das Durchführen – die Integration. In Deutsch und in Englisch.

Reflektionsfragen
  • Können Sie jeden der unten stehenden Begriffe zuordnen?
  • Gibt es einen Begriff, den Sie noch nie gehört haben?
Develop Project CharterProjektauftrag entwickeln
Monitor and Control Project WorkProjektarbeit überwachen und steuern
Perform Integrated Change ControlIntegrierte Änderungssteuerung durchführen
Project Integration ManagementIntegrationsmanagement in Projekten
Project Management PlanProjektmanagementplan
Develop Project Management PlanProjektmanagementplan entwickeln
Direct and Manage Project WorkProjektdurchführung lenken und managen
Manage Project KnowledgeProjektwissen managen
Configuration Management SystemKonfigurationsmanagementsystem
Project Statement of WorkLeistungsbeschreibung des Projekts
Requested ChangeBeantragte Änderung
ForecastPrognose
Lessons LearnedGesammelte Erfahrungen
Lessons Learned Knowledge BaseWissensspeicher der gesammelten Erfahrungen
Work Performance ReportsArbeitsfortschrittsberichte

Copyright Gita GmbH. Alle Rechte vorbehalten.

Abschluss (1176)

Um was geht’s?

Um den Abschluss und die Abschlussarbeiten am Projektende oder auch am Phasenende – je nach Projektgröße.

Oder auch: Wenn ein Schiff in den Hafen einfährt, ist der Törn noch lange nicht vorbei. Das Ankerbier gibt es erst, nachdem der Kahn sauber am Kai liegt.



Kurze Erinnerungshilfe
  • Klärt, was alles am Ende eines Projekts (oder einer Phase) geschehen muss.
  • Produktübergänge in die Linie.
  • Teamrückführung, Entlassung in die Linie.
  • Administrativer Abschluss, z. B. Projektdoku ablegen und letzten Statusbericht abgeben.
  • Formale Entlastung des Teams und des Projektleiters.
  • Feiern – im Sinne des Teamzusammenhalts wichtig.
  • Lessons (which I have) Learned. Ist etwas anderes als der administrative Abschluss.
  • Die Abnahme liegt häufig vor dem Abschluss, da erst mit der Abnahme durch den Kunden das Projekt abgeschlossen werden kann.


Kurze Erinnerungshilfe
  • Wie bereiten wir das Projektende vor? Üblicherweise durch eine Abschlussphase.
  • Normalerweise sind wir vorher mit dem Produkt fertig, der Kunde hat es abgenommen.
  • Aber damit ist das Projekt nicht beendet, es ist noch einiges zu tun.
  • Wenn wir das nicht ordentlich machen, kann es teuer werden, da das Projekt nie zu Ende geführt mutiert und zum Zombieprojekt wird.


Kurze Erinnerungshilfe
  • Produkt abnehmen – der Anfang vom Ende.
  • Produkt übergeben, evtl. mit Dokumentation und Schulung.
  • Administrativ abschließen
  • Projektabschlussbericht erstellen – Soll-Ist-Vergleich zwischen Ziel und Ergebnis.
  • Team entlasten
  • Sun-Set-Meeting durchführen
  • Projektleiter entlasten
  • Team in die Linie zurückführen
  • Feedback aus/an Linie, Steuerungskreis, Kunde…
  • Lessons Learned durchführen.

DevOps im agilen Kontext

Der klassische Gedanke ist geprägt von der (Produkt-)Erstellung und (Linien-) Übergabe, wie hier beschrieben. Könnte prinzipiell auch für agile Projekte gelten, da die Erstellungsform zunächst keinen Einfluss auf das Produkt hat.

Aber: Am Ende eines Sprints findet sich idealerweise ein „potentially shippable product“. Wenn also tatsächlich nach jedem Sprint das im Echtbetrieb befindliche Produkt eine Aktualisierung erfährt, dann muss ein ganz anderes Augenmerk auf die Verzahnung und Integration von Entwicklung (Development) und Betrieb (Operations) gelegt werden. Das ist dem Schlagwort „DevOps“ gemeint.


Reflektionsfragen
  • Wie hängen Abnahme und Abschluss zusammen?
  • Wie wird idealerweise der Übergang der Verantwortlichkeiten geregelt?
  • Was genau führt zu Zombieprojekten?
  • Wie könnten Zombieprojekte beendet werden?

Zum Weiterlesen

PMBOK Guide, 6.Ausgabe, Prozess 4.6 – Projekt oder Phase abschließen


Copyright Gita GmbH. Alle Rechte vorbehalten.

Änderungsmanagement (1175)

Um was geht’s?

Kein Plan hat jemals den ersten Kontakt mit dem Feind überlebt – Originalzitat von Generalfeldmarschall von Moltke.

Es ist also nicht die Frage, ob es Änderungen gibt, sondern wie sie organisiert werden.



Kurze Erinnerungshilfe
  • Änderungen an Inhalt und Umfang, Kosten und Terminen.
  • Wichtig ist in diesem Zusammenhang das Konfigurationsmanagement. In der Praxis häufig bei komplexen technischen Produkten anzutreffen.
  • Konfigurationsmanagement beschreibt, welche Versionen der Einzelteile eine gültige Konfiguration ergeben.
  • Konfigurationsmanagement kann auch auf das Projektmanagement selbst angewendet werden.


Kurze Erinnerungshilfe
  • Wieder ein Planungsthema: Wie möchten wir in unserem Projekt Change Management durchführen?
  • Aspekte eines Change Management Plans könnten sein:
    • Wo können wir bei Änderungen was drehen? (Zielhierarchie, Abklärung des Dreizwangs)
    • Für welche Änderungen gilt der Change-Prozess?
    • Wie wahrscheinlich sind Änderungen und wie groß könnten sie sein?
    • Welchen Aufwand wird das Änderungsverfahren an sich benötigen?
    • Wer hat welche Rolle, welche Verantwortlichkeit, welche Befugnisse?
    • Wie zeichnen wir die Changes auf, wie überwachen und wie berichten wir sie?
    • Welche Arten bzw. Kategorien von Changes gibt es? Und wie gehen wir jeweils damit um?
    • Wie werden Änderungen evaluiert?
    • Wie und wann wird die Projektdokumentation aktualisiert?
    • Wie wird das Projektteam über Änderungen informiert?
  • Wichtig: Nicht alles muss für jedes Projekt zutreffen.


Kurze Erinnerungshilfe

Folgende Fragen sollten im Change Management Plan geklärt werden:

  • Wann ist ein Change ein Change?
    • Nur bei Veränderungen der Rahmenbedingungen?
    • Oder auch bei Abweichungen vom Plan?
  • Liegt ein Change vor, dann sollte man:
    • Change analysieren und bewerten.
    • Bewertung der Gesamtauswirkung zur Entscheidung dem Steuerkreis vorlegen.
    • Entscheiden lassen.
    • Entscheidung umsetzen.
    • Gesamtsystem konsistent halten.
  • Zur Konsistenz:
    • Alle Projektmanagementartefakte müssen zueinander passen.
    • Was muss bei einem Change alles geändert werden?
    • Das Konsistent-halten kann auch als Konfigurationsmanagement gesehen werden.
      • Konfigurationsmanagement: Welche Version von welchemTeil“ passt zu welcher Version eines anderen „Teils“ und bilden zusammen eine gültige Gesamtkonfiguration?

Change & Agile Projekte

Eine der wichtigsten Merkmale agiler Projekte sind die so genannten „Build-In Changes“. Durch die Repriorisierung des Backlogs nach jedem Review ist tatsächlich ein Change-Automatismus geschaffen, der seines Gleichen sucht.

Daher wäre es ein Verbrechen am agilen Ansatz, Backlogs einzufrieren oder nur durch Change Requests zu ändern. Dann ist fraglich, ob überhaupt noch Agilität stattfindet.

Allerdings lauert hier auch die Gefahr, dass sich die Entwicklung und die Backlogs voneinander loslösen. Es findet dann eine schleichende Erweiterung des Inhalts und Umfangs statt (Scope Creep), der dann auch zur teuren und Never-Ending-Story mutieren kann.

Insbesondere in hybriden Projekten müssen Ansätze gefunden werden, die trotz Agilität einen Change Prozess beinhalten. Ein durchgängiger Methodenansatz liegt hierfür aber derzeit nicht vor.


Reflektionsfragen
  • Wer entscheidet über Änderungen?
  • Wer bereitet Änderungen auf?
  • Welche Rolle haben die Projektverantwortlichen im Änderungsprozess
  • Wie ließe sich in einem agilen (Teil-)Projekt ein geschickter Änderungsprozess implementieren, ohne die Kreativität der Agilität zu gefährden?

Zum Weiterlesen
  • PMBOK Guide, Prozess 4.5 – Integrierte Änderungssteuerung durchführen
  • Practice Standard for Project Configuration Management 
  • Managing Change in Organizations: A Practice Guide

Copyright Gita GmbH. Alle Rechte vorbehalten.

Lessons Learned (1173)

Um was geht’s?

Der „Blick zurück“ ist mit das wichtigste Element im gesamten Projektmanagement-Zyklus. Nur leider wird dieser Blick viel zu selten gewagt…



Kurze Erinnerungshilfe
  • Lektionen, die gelernt wurden – und die hoffentlich einen Impuls für künftige Projekte geben.
  • Gerne als Workshop, auch als Event.
  • Es geht ums Lernen, nicht um Schuldzuweisung.
  • Welche Fragen können wir uns bei Lessons Learned stellen?
    • Was hat gut geklappt, was hat funktioniert?
    • Was kann künftig verbessert werden?
    • Welche Probleme hätten vermieden werden können? (Gibt Ideen fürs Risikomanagement?)
    • Welche Probleme haben wir vermieden? (Auch: wo war Risikomanagement erfolgreich?)

Reflektionsfragen
  • Wie halten Sie es mit dem „Blick zurück“
  • Wann sollte denn am Besten von diesen Erkenntnissen wieder Gebrauch gemacht werden?
  • Tun Sie das?
  • Ist Ihr Lessons-Learned frei von Schuldzuweisungen?
  • Ein echter Verbesserungsturbo?

Zum Weiterlesen

PMBOK Guide, 6.Ausgabe, Prozess 4.4 – Projektwissen managen und 4.7.


Copyright Gita GmbH. Alle Rechte vorbehalten.

Projekt lenken, managen und steuern (1174)

Um was geht’s?

Es geht darum, die Arbeit, wie sie im Projektmanagementplan oder auch anderen Planungsschritten festgelegt wurde, anzuleiten und auszuführen. Das Projektschiff wird nun durch die raue See der Projektrealität gesteuert.



Die eigentliche Projektarbeit

Mit Hilfe der bereits besprochenen Instrumente und Werkzeuge wird nun die Projektarbeit auf Basis der Planungen gemanagt und gesteuert, unabhängig vom Projekttyp und der Strategie. Es gilt der klassische PDCA-Deming Cycle, der ausgehend von einer Planung (Plan) die Durchführung veranlasst (Do) und die Ergebnisse überwacht (Check), um ggfs. korrigierend einzugreifen und zu handeln (Act).



Nachfolgend noch eine kurze Diskussion bzw. Illustration zum Thema Abweichung – am Beispiel des Kurses eines Segelboots.


Kurze Erinnerungshilfe
  • Was bedeutet denn Abweichung vom Plan eigentlich?
  • Wenn wir nicht genau im Plan sind, muss das keine Abweichung vom Plan bedeuten:
    • Wir sind immer noch in den vereinbarten Varianzen, in den akzeptierten Schwankungsbreiten.
    • Oder: Wir haben eine echte Abweichung und führen eine Korrektur durch, um zurück zum Plan zu kommen.
    • Oder: Wir habe eine echte Abweichung – und planen ab jetzt neu für den Rest.

Reflektionsfragen
  • Was ist ein Work Authorization System und was ein Project Management Information System?
  • Wie unterscheiden sich Steuerungsaufgaben im agilen System und im klassischen Projekt?

Zum Weiterlesen

PMBOK Guide, 6.Ausgabe, Prozess 4.3 – Projektdurchführung lenken und managen sowie Prozess 4.4 – Projektarbeit überwachen und steuern


Copyright Gita GmbH. Alle Rechte vorbehalten.

Projektmanagementplan (1172)

Um was geht’s?

Der Projektmanagementplan (öfters auch mit PMP(!) abgekürzt) beinhaltet alle relevanten Informationen zur Ausführung des Projekts. Dort würde unter anderem auch festgehalten werden, mit welchem Verfahrensansatz das Projekt durchgeführt wird.



Kurze Erinnerungshilfe
  • Beinhaltet:
    • die relevanten Basispläne
    • alle Managementpläne
    • gewählter Projektansatz (agil, hybrid, klassisch)
    • gewählter Lebenszyklus
    • verwendete Prozesse
  • Drei (klassische) Basispläne:
    • Termin
    • Budget
    • Inhalt und Umfang (Scope Statement, WBS, WBS Dictionary)

Achtung! Es wird eine Unterscheidung getroffen zwischen dem Projektmanagementplan und weiteren Projektdokumenten, die nicht zum Umfang des Projektmanagementplans gehören.


Reflektionsfragen
  • Welche Ziele und welchen Zweck hat der Projektmanagementplan?
  • Hat ein agiles Projekt auch einen Projektmanagementplan?
  • Aus wie vielen Artefakten besteht der Projektmanagementplan? Was sollte mindestens drin sein und was kann alles drin sein?
  • Wovon hängt es ab, wie umfangreich der Projektmanagementplan ausfällt?
  • Wer ist für den Projektmanagementplan verantwortlich?

Zum Weiterlesen

PMBOK Guide, 6.Ausgabe, Prozess 4.2 – Projektmanagementplan entwickeln


Copyright Gita GmbH. Alle Rechte vorbehalten.

Die Projektcharter (1171)

Um was geht’s?

Der Projektauftrag (oder auch mit dem englischen Begriff die Charter) ist die formelle Freigabe der Trägerorganisation, Mittel und Ressourcen für die Durchführung des Projekts einzusetzen. Von einer für diese Aufgabe benannten Person – dem Projektverantwortlichen.



Immer interne Freigabe

Das Prinzip der internen (!) Projektfreigabe ist simpel – und genau darin liegt seine Schwierigkeit.

Die deutsche Übersetzung Projektauftrag des englischen Begriffs Charter ist schon missverständlich, da ein Projektauftrag immer irgendwie nach „Vertrag“ klingt. Die Charter hat seine Analogie aber im Wort Charta – und das ist so eine Art Grundlage.

Für die Freigabe des Projektes wäre eine schriftliche Dokumentation natürlich ideal. Wir behalten aber im Hinterkopf, dass wenn der Chef eine Mitarbeiterin in der Kaffeeküche anspricht und sie bittet, das Projekt, das gerade eben ins Haus geflattert ist, zu übernehmen, dann ist das auch eine Charter.

Die Charter wird immer von einem Sponsor herausgegeben. Je nach Trägerorganisation verbirgt sich dahinter ein riesiger formaler Prozess oder eben auch nur die Kaffeeküche.

Fakt ist, dass mit der Charter das Projekt startet. Jetzt gibt es das Projekt, jetzt wurde aus der Kollegin in der Kaffeeküche die Projektleiterin dieses Vorhabens. Jetzt geht die Verantwortung für die Durchführung über und jetzt kommen all die Instrumente, Methoden, Techniken und Werkzeuge des Projektmanagements zum Einsatz.

Wie lauten die Minimalanforderungen an eine Charter? Nun, wie in der Küche auch: Was soll gekocht werden und wer ist der Koch? Also:

  • Projektziel
  • Projektverantwortliche(r)

Wenn bereits weitere Informationen vorliegen (Rahmenbedingungen, gesetzliche Vorgaben, Zeiteinschränkungen, Risiken, Anforderungen usw.) gehören die natürlich auch dazu.


Reflektionsfragen
  • Wer erstellt die Charter eigentlich?
  • Wie unterscheiden sich Business Case und Vertrag mit einem externen Kunden von einer Charter?
  • Werden agile Projekte auch gechartert?
  • In Scrum gibt es den Begriff Charter nicht. Wie lösen Sie dieses Dilemma?

Zum Weiterlesen

PMBOK Guide, 6.Ausgabe, Kapitel 4, die Einleitung und cProzess 4.1 – Projektauftrag entwickeln


Copyright Gita GmbH. Alle Rechte vorbehalten.

Begriffe rund um Kommunikation (1183)

Um was geht’s?

Nachfolgend eine Übersicht von gängigen Begriffen rund um Risikomanagement. In Deutsch und in Englisch.

Reflektionsfragen
  • Können Sie jeden der unten stehenden Begriffe zuordnen?
  • Gibt es einen Begriff, den Sie noch nie gehört haben?
Manage CommunicationsKommunikation managen
Plan Communications ManagementKommunikationsmanagement planen
Project Communications ManagementKommunikationsmanagement in Projekten
Communication Management PlanKommunikationsmanagementplan
Communication MethodsKommunikationsmethoden
Communication ModelsKommunikationsmodelle
Communication Requirements AnalysisAnalyse der Kommunikationsanforderungen
Communication TechnologyKommunikationstechnologie
Monitor CommunicationsKommunikation überwachen
Communication ConstraintsKommunikationsbeschränkungen
Information Management SystemsInformationsmanagementsysteme

Copyright Gita GmbH. Alle Rechte vorbehalten.

Stakeholder identifizieren (1170)

Um was geht’s?

Wir gehen nochmals auf den Begriff Stakeholder ein und führen unsere ersten Prozessschritte durch: Die Stakeholder-Identifikation und -Analyse.



Kurze Erinnerungshilfe
  • Welche Erwartungen haben die Stakeholder an mich? (Nicht ich an die Stakeholder.)
    • Empathischer Perspektivenwechsel: Wenn ich einer meiner Stakeholder wäre, was würde ich dann erwarten?
  • Wie kann ich das Engagement der Stakeholder beeinflussen?
    • Wo hätte ich den Stakeholder gerne? Wie kann ich meine Stakeholder dazu bringen, mich zu unterstützen?
    • Welche Stakeholder könnten Einfluss auf mein Projekt nehmen?
  • Wie kann ich den Stakeholder verorten? Z.B. Macht/Einfluss-Diagramm als „Landkarte“.

Kommen wir jetzt zur ersten Aufgabe dieses Prozesses:


Kurze Erinnerungshilfe
  • Ähnlich aufgebaut wie das Risikoregister.
  • Übliche Punkte im Register sind:
    • Stakeholder
    • die Stakeholderwartungen
    • Power/Interest der Stakeholder und
    • ihre aktuelle Haltung
  • Power/Interest wird qualifiziert.
  • Wie mit der Haltung verfahren wird, ist eine Fallentscheidung.
  • Stakeholder werden häufig in Gruppen zusammengefasst (Alle Nachbarn, die Mitarbeiter, die für die Verschmelzung sind, …)
  • Erwartungsgruppierungen zu bilden ist die hohe Kunst der Stakeholderanalyse.

Sind alle Stakeholder bekannt, müssen sie auch noch klassifiziert werden. Darum geht es jetzt um die


Kurze Erinnerungshilfe
  • Erstellen einer Stakeholderlandkarte.
  • Eingangsvoraussetzung: Übersicht der Stakeholder; die Interessenslage der jeweiligen Stakeholder ist bekannt.
  • Auswahl geeigneter Dimensionen, z.B. Macht und Interesse.
  • Achtung! Dimensionen immer in Bezug auf das Projekt sehen!
  • Quadranten des Diagramms geben den ersten Hinweis auf die Strategie zum Umgang mit den dort definierten Stakeholdern.
  • Achtung! Analyse nicht mit Aktion verwechseln!

Reflektionsfragen
  • Wer kann alles Stakeholder sein?
  • Mit welchen Methoden kann ich Stakeholder identifizieren und klassifizieren?
  • In welchem Kontext werden die Stakeholder betrachtet?
  • Bin ich selbst im Projekt mein eigener Stakeholder?

Zum Weiterlesen

PMBOK Guide, 6.Ausgabe, Prozess 13.1 – Stakeholder identifizieren


Copyright Gita GmbH. Alle Rechte vorbehalten.

Stakeholder-Taxonomie (1169)

Um was geht’s?

Der Begriff „Stakeholderklingt im ersten Moment sehr präzise. Ist er aber nicht. Da ja irgendwie jeder und alle Stakeholder in unterschiedlichen Situationen sein können, kann mit dem Begriff Stakeholder auch immer eine sehr spezielle und eingegrenzte Personengruppe gemeint sein. Je nach Kontext sind unterschiedliche Aspekte, Gruppen und „Arten“ zu betrachten.

Die Unterscheidung auf dieser Seite dient dem besseren Verständnis, warum im Projektgeschäft ständig und dauernd von Stakeholdern die Rede ist, obwohl diese in unterschiedlichen Rollen und Funktionen vorkommen.

Es gibt grundsätzlich beliebig viele und noch andere Unterscheidungen und Klassifizierungen, die je nach Projektumfeld ebenfalls ihre Berechtigung haben:

  • Passive und aktive Stakeholder
  • Interne und Externe Stakeholder
  • usw.

Und wie immer ist die Realität unschärfer und es kann natürlich auch ein Stakeholder in zwei Gruppen gleichzeitig auftauchen.

Betrachten wir nun die unterschiedlichen Stakeholdergruppierungen:


Die Business-Treiber-Stakeholder

Typisierung: Das sind alle, die das Projekt wollen, es unterstützen, Anforderungen haben und sich etwas von dem Projekt versprechen. Aber auch ihre Interessen platzieren möchten, politischen Einfluss nehmen oder Lobbyarbeit betreiben.

Einfluss aufs Projekt: Groß, da sie die Grundlage für die Exisitenzberechtigung des Projekts bilden.

Vorkommnis: Start des Projekts, Vorprojektphase, typische Sparringspartner der Business Analysten. In der Business Analyse gibt es eine eigene Domaine, die sich nur dem Thema widmet, wie man diesen Stakeholdern ihre Anforderungen herauskitzelt (das heißt tatsächlich so!)

Aus Sicht der Projektleitung: Das Verständnis der Projektmotivation ist immer sehr hilfreich, allerdings ist der Grad der Einflussnahme vom Projekt zu diesen Stakeholdern eher gering. Meist ist das Thema ja auch schon platziert, wenn eine Projektmensch die Bühne betritt.


Die Endbenutzer bzw. Kunden

Typisierung: Das sind alle diejenigen, die ganz am Ende mit dem Projektprodukt zu tun haben werden. Die es also nutzen und für ihre Zwecke einsetzen werden. Diese Stakeholder treten in einem klassischen Projekt eher gar nicht oder nur indirekt auf, in einem agilen Projekt wird versucht, frühzeitig mit dieser Gruppe ins Gespräch zu kommen, um die Entwicklung zu beeinflussen. Typisch ist die Teilnahme der Kunden an agilen review-Meetings.

Einfluss aufs Projekt: Im klassischen Projekt meist (leider) nicht so stark wie im agilen Projekt. Wenn das Projektprodukt aber nicht für einen breiten Markt gemacht wird, sondern z.B. eine Spezialanfertigung für eine Fachabteilung ist, dann kann auch im klassischen Umfeld eine starke Interaktion stattfinden.

Vorkommnis: Idealerweise während des gesamten Projektes. Im klassischen Umfeld meist erst ganz am Ende, dann, wenn alles fertig ist. Daher wird versucht, während der Projektlaufzeit die Aspekte dieser Stakeholdergruppe im Qualitätsmanagement aufzufangen („Voice of the Customer“, „Qualität ist, wenn der Kunde zurückkommt und nicht das Produkt“, …)

Aus Sicht der Projektleitung: Eine Berücksichtigung dieser Stakeholdergruppe fällt vielen im Projektgeschäft schwer. Hängt aber stark vom Projekttyp ab und auch von der Methodik.


Die Aufsichtsgremien und Strukturen

Typisierung: Das sind alle diejenigen Stakeholder, die die Projektausführung überwachen und steuern, als Eskalationsinstanz dienen und dem Projekt den Durchführungsrahmen geben. Typischerweise der Lenkungskreis oder Steuerkreis. Diese Stakeholder können ganz eigene Interessenslagen haben und nicht den Produkterfolg an erster Stelle sehen, sondern eher die geräuschlose Projektabwicklung.

Einfluss aufs Projekt: Groß, da ja die Steuerungsebene

Vorkommnis: Während der gesamten Projektlaufzeit. Wird im Projektkontext über das Thema Governance, Struktur, Linie/Projekt, Projektorganisation, PMO usw. abgehandelt.

Aus Sicht der Projektleitung: Da die Steuergremien dem Projekt allgegenwärtig sind, ist die Gefahr, diesen Stakeholder zu vergessen, kaum vorhanden.


Das direkte Arbeitsumfeld

Typisierung: Das sind alle Personen bzw. Personengruppen, die direkt mit dem Projekt zu tun haben, also das Projektteam und der engere Dunstkreis drumrum.

Einfluss aufs Projekt: Groß, da dort die Projektarbeit erfolgt.

Vorkommnis: Während der gesamten Projektlaufzeit. Die Themen dieser Stakeholdergruppe sind Teambuilding, Motivation, Kommunikation, Delegation, Führung, Konflikt, Gruppendynamik, usw.

Aus Sicht der Projektleitung: Extrem wichtig. Vor allem durch den Anspruch an die Projektleitung, eine laterale Führungskraft zu sein. Im agilen Umfeld auch gerne Servant Leadership genannt. Die eigentliche Herausforderung im Projektgeschäft.


Das indirekte Arbeitsumfeld

Typisierung: Das sind alle diejenigen, die sich im weiteren Dunstkreis des Projekts bewegen, aber nichts direkt mit dem Projekt zu tun haben. Die Arbeitskollegen, andere Abteilungen, Stabsstellen, andere Niederlassungen, aber auch z.B. Lieferanten.

Einfluss aufs Projekt: Natürlich viel geringer, werden dadurch aber leicht vergessen und können sich schnell zu einer sehr einflussreichen Stakeholdergruppe entwickeln, die dem Projekt nicht unbedingt wohlgesonnen sein muss.

Vorkommnis: Während des gesamten Projekts, zu Beginn noch in geringerem Ausmaß. Typischer Gegenstand einer neutralen und allgemeinen Stakeholderbetrachtung.

Aus Sicht der Projektleitung: Wird leicht übersehen und ist meist Gegenstand von Kommunikationsüberlegungen, also z.B. im Intranet oder Mitarbeiterzeitschriften.


Projektgegner

Typisierung: Das sind all diejenigen Stakeholder, die qua Amt gegen das Projekt sind, meist auch öffentlichkeitswirksam und laut. Hierunter zählen Bürgerbewegungen, Umweltinitiativen oder andere NGOs. Aber wenn das Projekt zum Gegenstand hat, einen Standort zu schließen und die Abwicklung zu organisieren, dann gehören in diese Kategorie auch jede Menge interne Stakeholdergruppierungen wie Betriebsrat oder Mitarbeiterbewegungen.

Einfluss aufs Projekt: Groß. In Infrastrukturprojekten neigt man dazu, den Stakeholderbegriff nur auf diese Gruppe zu reduzieren, was bedauerlich ist.

Vorkommnis: Formen sich meist im ersten Drittel der Projektlaufzeit.

Aus Sicht der Projektleitung: Diese Stakeholder können ganz eigene Liefergegenstände im Projekt bewirken. Denken wir zum Beispiel an einen Informationspavillion wegen einer Baumaßnahme.


Outer Space

Typisierung: Das sind alle Stakeholder, die scheinbar nichts mit dem Projekt zu tun haben, oder deren Einfluss und Macht auf das Projekt nicht ernstgenommen wird.

Einfluss aufs Projekt: Gering bis gar nicht – wenn dem nicht eine Fehleinschätzung zu Grunde liegt.

Vorkommnis: Wird in der Regel vom Projekt nicht beachtet, maximal in der allgemeinen Kommunikation.

Aus Sicht der Projektleitung: Wahrscheinlich den Aufwand nicht wert, hier Zeit zu investieren. Die Gefahr liegt höchstens in einer Fehleinschätzung. Eine schwedische Schülerin wurde am Anfang auch belächelt…


Copyright Gita GmbH. Alle Rechte vorbehalten.

Scroll to Top