Stakeholder Biases: Warum Projektkontext so wichtig ist

Die meisten Projektmanager kennen die Definition von „Projektmanagement“ in- und auswendig. Allerdings wird immer wieder deutlich, dass sie häufig wenig bis nichts über die sogenannten Stakeholder Biases, also die Standpunkte der Auftraggeber gegenüber dem Projekt, wissen. Wenn es an diesem Wissen fehlt, wie wahrscheinlich ist es dann, dass die richtigen Kenntnisse, Werkzeuge und Methoden im Rahmen des Projekts angewendet werden? Wissen die Projektmanager tatsächlich, was der Zweck des Projektmanagements ist? Hinter dieser Frage steckt eine Herausforderung, aber auch eine Chance für geschäftsorientierte PMO-Leiter.

Der Zweck des Projektmanagements

Um sich dieser Thematik besser nähern zu können, muss man sich zunächst ganz grundlegende Fragen stellen.

Was ist ein Projekt? Ein Projekt ist ein zeitlich begrenztes Vorhaben, in dessen Rahmen etwa ein einzigartiges Produkt kreiert werden soll2.

Was ist Projektmanagement? Projektmanagement ist die Anwendung von Wissen, Fähigkeiten, Werkzeugen und Techniken auf Projektaktivitäten, um den Projektanforderungen gerecht zu werden2.

Was ist der Zweck des Projektmanagements? Der Zweck des Projektmanagements ist, so viele Risiken und Probleme wie möglich vorherzusagen und Aktivitäten so zu planen und zu steuern, dass das Projekt trotz aller Risiken so erfolgreich wie möglich fertiggestellt wird3.

Werfen Sie nun einen Blick auf die beiden Projekte in der Abbildung 1. Dabei handelt es sich um zwei identische Projekte mit dem gleichen Umfang und den gleichen Phasen. Zudem sind Status, Terminplanung und Kosten ersichtlich.
Welches Projekt wurde besser verwaltet?

Abbildung 1: Welches Projekt wurde besser verwaltet?

Diese Frage wurde in PMO-Workshops rund um den Globus gestellt. Die Antworten sind aufschlussreich und in jedem Fall lesenswert.

Die Workshops bestanden aus drei Gruppen: (1) Projektmanager, einschließlich PMO-Management und Mitarbeiter, (2) Mitarbeiter agiler Projekte und (3) Mitarbeiter in Führungspositionen.

Natürlich baten die Teilnehmer um weitere Informationen, allerdings durften sie für ihre Entscheidung nur die Daten aus der Abbildung heranziehen. Ihnen wurden drei Antwortmöglichkeiten vorgegeben: „Projekt #1 wurde besser verwaltet“, „Projekt #2 wurde besser verwaltet“ oder „Weitere Informationen benötigt“. Letztere durfte allerdings nur gegeben werden, wenn sie in ihrer eigenen PMO-Umgebung tatsächlich weitere Informationen gebraucht hätten und sich nicht bereits eine Meinung gebildet haben, welches der beiden Projekte besser verwaltet wurde.

Wie in Abbildung 2 deutlich wird, unterschieden sich die Ergebnisse der einzelnen Gruppen erheblich. Projektmanager votierten vornehmlich für Projekt #1. Unter den Mitarbeitern agiler Projekte wählte eine große Mehrheit Projekt #2. Bei den Mitarbeitern in Führungspositionen wurde für beide Projekte in gleichem Maße gestimmt.

Abbildung 2: Stimmenverteilung

Die Erklärungen zu ihren Angaben waren äußerst interessant und weltweit innerhalb der jeweiligen Gruppen deckungsgleich.

Projektmanager argumentierten damit, dass Projekt #1 besser verwaltet wurde, weil es zeitgerecht und innerhalb des Budgets beendet wurde. Mitarbeiter agiler Projekte begründeten ihre Antwort, dass Projekt #2 besser verwaltet wurde, damit, dass es trotz Verspätung und Budgetüberschreitung früher abgeschlossen wurde als Projekt #1 und somit die Markteinführung schneller erfolgen und entsprechend Gewinn gemacht werden konnte.

In der dritten Gruppe, Mitarbeiter in Führungspositionen, hat sich die eine Hälfte dafür ausgesprochen, dass Projekt #1 besser verwaltet wurde. Diese Entscheidung haben sie, wie die Projektmanager, mit dem eingehaltenen Zeitplan und Budget begründet. Die andere Hälfte hat sich für Projekt #2 entschieden, allerdings nicht wegen der schnelleren Markteinführung, sondern weil sie glaubten, dass ein Projekt, bei dem alle Statusindikatoren grün sind, nicht stimmen könne. Sie hielten ein Projekt, bei dem die Indikatoren durchmischt (gut, Vorsichtig, Problem) sind, als vertrauenswürdig, transparenter und daher besser verwaltet.

Eine entscheidende Beobachtung war auch, dass nur wenige wirklich mehr Informationen benötigten, was bereits auf weitere interessante Erkenntnisse hindeutete.

Nach dieser Aufgabe bekamen die Workshop-Teilnehmer zwei Projektszenarien (Abbildung 3), welche die Details hinter den beiden oben abgebildeten Projekten darstellten. Trotz gleicher Kosten- und Zeitvorgaben hätten sie hinsichtlich Geschäftskontext und Stakeholder Biases nicht unterschiedlicher sein können.

Abbildung 3: Projektszenarien

In der Abbildung werden nicht nur Geschäftskontext und Stakeholder Biases (Standpunkte der Auftraggeber) deutlich, sondern auch das Verständnis darüber, welche Bedeutung diesen Haltungen zukommt, so dass diese bei der Verwendung der Projektmanagement-Methoden berücksichtigt werden können.

Bei Szenario A handelte es sich um ein Projekt, anhand dessen Bauvorbereitungen innerhalb einer bestimmten Zeit abgewickelt werden sollten, damit die nächste Phase beginnen konnte. Verzögerungen hätten zu hohen Geldbußen geführt (muss zeitgerecht beendet werden). Zeitmanagement war für die Stakeholder also der entscheidende Aspekt. Der Umfang spielte nach der Zeit eine zweitrangige Rolle. Um Kosten machten sie sich keine Gedanken. Den Projektmanagern wurde aufgetragen, das Projekt zeitkritisch zu planen und daher jede Phase mit Puffern zu versehen. Auch wenn die erste Phasenplanung nach oben korrigiert werden musste (von 20 auf 25 Tage), konnte das Projekt termingerecht beendet werden und so Geldbußen verhindert werden.

Bei Szenario B handelte es sich um ein Projekt, an dessen Ende ein völlig neues Online-Versandportal stehen sollte, von dem sich das Unternehmen 20.000 Dollar Mehreinnahmen pro Tag versprach. An jedem Tag, an dem das Portal noch nicht zur Verfügung stand, würde das Unternehmen folglich weniger Umsatz generieren. Die Zeit spielte auch hier die entscheidende Rolle (so schnell wie möglich). Der Umfang stand an zweiter Stelle und war dahingehend flexibel, dass Kernfunktionen früher als zusätzliche Funktionalitäten geliefert werden konnten. Die Kosten konnten im Hinblick auf die vielversprechenden Einnahmenprognosen vernachlässigt werden. Die Projektmanager sollten daher offensiv und mit negativen Puffern planen. Diese Methode wird häufig zur Verkürzung der Zeit bis zur Markteinführung eingesetzt. So konnte das Projekt, zwar später als die offensiv angelegte Zeitplanung, aber so früh wie möglich geliefert werden, was den Umsatz steigen ließ.

„Ein Projekt, das den Zeit- und Budgetrahmen einhält, wurde nicht zwingend besser verwaltet als ein Projekt, bei dem dies nicht der Fall war."

Die Folge war, dass die Workshop-Teilnehmer ihre Antworten revidieren wollten. Die Projektmanager erkannten, dass ein Projekt, das den Zeit- und Budgetrahmen einhält, nicht zwingend besser verwaltet wurde als ein Projekt, bei dem dies nicht der Fall war. Die Mitarbeiter agiler Projekte sahen ein, dass ein früh beendetes Projekt nicht zwingend besser verwaltet ist als eines, das länger dauert. Die Mitarbeiter in Führungspositionen sahen die Punkte ebenfalls ein und, was noch wichtiger ist, verstanden, dass Projektstatusindikatoren nicht als Hinweis genommen werden sollten, ob ein Projektmanager das Projekt wahrheitsgetreu darstellt, sondern vielmehr, wie der Projektmanager Projektmanagementmethoden anwendet bzw. anwenden sollte, um das vom Auftraggeber gewünschte Ziel zu erreichen. Es herrschte Einigkeit darüber, dass das Arbeitsergebnis weit besser ausfällt, wenn der Standpunkt der Stakeholder klar ist.

Stakeholder Biases verbildlicht

Dass PMOs das Konzept von Stakeholder Biases bekannt ist, steht außer Frage. Doch dass die Standpunkte selbst bekannt sind und im Laufe des Projekts berücksichtigt werden, ist eine völlig andere Angelegenheit.

Abbildung 4: Stakeholder Biases „Magic“ Quarter

Der Stakeholder Biases „Magic“ Quarter ist ein Diagramm, in dem abgelesen werden kann, zu welchem Grad mit Stakeholder Biases gearbeitet wird. Der Bereich rechts oben ist sozusagen der magische Quadrant. PMOs in diesem Quadranten nutzen Projektmanagement-Ansätze, die den Geschäftskontext des Projekts sowie die Stakeholder Biases berücksichtigen. Das, was für den Stakeholder den Projekterfolg ausmacht, steht also dabei im Mittelpunkt. Die anderen Quadranten weisen auf ein noch ausbaufähiges Vorgehen hin. Daher sind hier Einbußen bis hin zum völligen Projektfehlschlag möglich.

Als Teil der von J. Ross Publishing herausgegebenen Buchreihe 1„Business Driven PMO“ wurde vom Autor anhand von Umfragen und Gesprächen die Arbeit von PMOs erforscht. So sollte herausgearbeitet werden, zu welchem Grad der Stakeholder Bias, also der Standpunkt der oder des Auftraggeber(s) berücksichtigt wurde. Die befragten PMOs bestanden aus vier Typen: IT-PMOs (30), Enterprise PMOs (30), Agile PMOs (30) und PMOs für Neuproduktentwicklungen (10). Jede dieser PMOs wurde um einen beliebigen Projektauftrag, Projektstatusbericht und Executive Dashboard Report gebeten. Die Dokumente wurden dann dahingehend geprüft, zu wie viel Prozent die PMOs den Stakeholder Bias zur Priorisierung von Umfang, Zeit und Kosten nicht berücksichtigt haben. Die Ergebnisse fielen wie folgt aus.

  • Projektaufträge: Bei 89 % wurde der Stakeholder Bias nicht berücksichtigt.
  • Projektstatusberichte: Bei 93 % wurde der Stakeholder Bias nicht berücksichtigt.
  • Executive Dashboard Reports: Bei 93 % wurde der Stakeholder Bias nicht berücksichtigt.

All diese Dokumente enthielten Projektindikatoren, doch nur wenige zogen entsprechende Maßnahmen nach sich, geschweige denn welche, bei denen der Stakeholder Bias berücksichtigt wurde. Beispielsweise enthielten sämtliche Projektaufträge Daten zu Umfang, Terminplanung und Budget, allerdings nur wenige Beweise dazu, dass Stakeholder Biases verstanden oder verwendet wurden:

  • Projektauftrag: Stakeholder Bias bzgl. Umfang
    • Bei 82 % wurden erforderliche Anforderungen identifiziert.
    • Bei 27 % wurden optionale (später lieferbare) Anforderungen identifiziert.
    • Bei 12 % wurden priorisierte Anforderungen identifiziert.
  • Projektauftrag: Stakeholder Bias bzgl. Zeit
    • Bei 4 % wurde der Wartewillen des Auftraggebers identifiziert.
    • Bei 4 % wurde der Zeitdruck des Auftraggebers identifiziert.
  • Projektauftrag: Stakeholder Bias bzgl. Kosten
    • Bei 7 % wurde der Zahlungswille des Auftraggebers identifiziert.
    • Bei 7 % wurde der Zahlungswiderwille des Auftraggebers identifiziert.
  • Projektauftrag: Priorisierung von Umfang, Zeit, Kosten
    • Bei 11 % wurden Umfang, Zeit und Kosten nach Bedeutung priorisiert bzw. geordnet.

Die Projektstatusberichte und Executive Dashboard Reports waren, was den Bezug auf bzw. die Nutzung von Stakeholder Biases betrifft, identisch. Nur 7 % wiesen auf eine Priorisierung der Projektindikatoren hin. War das der Fall, erfolgte dies immer in Form einer roten Flagge oder eines Kommentars. Sie waren nie Teil des zentralen Formats der Projektstatusberichte bzw. der Executive Dashboard Reports noch dauerhaft vorhanden.

Die Umfrage führte unweigerlich zur Frage: „Wenn die Standpunkte der Auftraggeber nicht verstanden bzw. berücksichtigt wurden, wie wahrscheinlich ist es dann, dass den Wünschen der Auftraggeber im Lauf des Projekts entsprochen wird?“ Die Gespräche mit den PMO-Mitarbeitern sollten dann dazu dienen, diese Frage zu beantworten und zu prüfen, ob es vielleicht andere Hinweise darauf gibt, dass die Stakeholder Biases berücksichtigt wurden. Im Folgenden werden einige Aussagen dazu angeführt. Diese sind zwar aufschlussreich, doch dokumentierte Beweise für die Berücksichtigung der Standpunkte gibt es nicht:

  • „Wir halten Informationen von Auftraggeberseite hinsichtlich deren Rang, Einfluss und Erwartungen sowie die Kommunikationswege zwar fest, aber nein, wir fragen nicht nach ihren Standpunkten zu Projektindikatoren.“
  • „Wir dokumentieren Stakeholder Biases zwar nicht, wissen aber, welche sie sind.“
  • „Wir nehmen an, dass, wenn Umfang, Zeit und Kosten eingehalten werden, die Auftraggeber zufrieden sind.“
  • „Wir sprechen erst genauer über die KO-Kriterien Zeit oder Kosten, wenn das Projekt zu scheitern beginnt.“

Es lässt sich also im Allgemeinen feststellen, dass in den Projektaufträgen, den Projektstatusberichten und Executive Dashboard Reports der befragten PMOs nur wenige bis keine Nachweise für die Berücksichtigung von Stakeholder Biases zu finden waren. Zudem wurde erkannt, dass die meisten PMOs zwar zu einem gewissen Grad Stakeholder-Management betrieben, dieses jedoch nicht in ausreichenden Maße den Standpunkten der Auftraggeber Beachtung schenkten. Unter den PMO-Managern herrschte ebenfalls Einigkeit darüber, dass bei Projektbesprechungen, seien sie offiziell oder inoffiziell, zwar Interessen und zu einem gewissen Grad auch Standpunkte häufig verstanden und aufgenommen wurden, aber am Ende nur ein vernünftiges Projektergebnis stehen könnte, wenn die angewendeten Projektmanagement-Methoden voll und ganz auf den Stakeholder Biases basieren.

Obwohl die PMO-Umfrage hinsichtlich der Anzahl der Befragten und der unterschiedlichen Typen keine belastbaren quantitativen Daten dazu liefern kann, ob IT-PMOs, Enterprise PMOs, Agile PMOs und PMOs für Neuproduktentwicklungen Stakeholder Biases erfragen und entsprechend berücksichtigen, kann jedoch eine Schlussfolgerung daraus abgeleitet werden. Laut Autor ist die Schlussfolgerung in Abbildung 4 ersichtlich, da sich alle PMOs in diesem Diagramm positioniert haben.

Fazit

Da PMO-Leiter immer nach neuen Möglichkeiten suchen, Strategien voranzutreiben, geschäftliche Agilität zu fördern, Change-Management nachhaltig zu gestalten, Werte zu vermitteln und kontinuierlich die PMO-Praktiken zu verbessern, kann es äußerst nützlich sein, von Zeit zu Zeit Grundlegendes neu zu überdenken und sich folgende Fragen zu stellen: Wissen alle Beteiligten, was ein Projekt ist? Wissen alle Beteiligten was Projektmanagement ist? Wissen alle Beteiligten, was der Zweck von Projektmanagement ist?

Für viele hat die praktische Anwendung des Projektmanagements weniger damit zu tun, was gelernt werden muss, als mit dem, was von dem Gelernten wieder vergessen werden muss. Die Vorstellung, dass der Zweck des Projektmanagements ist, ein Projekt rechtzeitig und im Rahmen des Budgets abzuliefern, ist ein gutes Beispiel dafür, was man vergessen oder zumindest vernachlässigen sollte.

Hinsichtlich des Stakeholder Biases „Magic“ Quarter lässt sich sagen, dass es ein Tool ist, anhand dessen grafisch dargestellt werden kann, zu welchem Grad die Standpunkte der Auftraggeber berücksichtigt werden. Die Position der PMOs im Diagramm richtet sich nach dokumentierten Belegen und Bewertungen der relevanten Personen. So können neue Methoden und Techniken erkannt werden, um das Projektmanagement sowie das Projektergebnis zu verbessern.

Nach der in diesem Artikel erläuterten PMO-Studie haben bereits mehrere der befragten PMO-Leiter ihre Erfahrungen bzgl. der Berücksichtigung von Stakeholder Biases weitergegeben. Sämtliche Berichte waren durchweg positiv, wie es sich in den folgenden Kommentaren einiger PMO-Leiter widerspiegelt:

  • „Die Berücksichtigung des Stakeholder Bias hat unsere Arbeit mit den Auftraggebern sowie die aktive Teilnahme in Projektstatus-Meetings signifikant gesteigert.“
  • „Durch die Aufnahme der Stakeholder Biases hat sich die Art und Weise geändert, wie unsere Projektmanager mit den Auftraggebern reden – es ist alles viel geschäftsspezifischer.“
  • „Warte- und Zahlungswillen zu berücksichtigen, hat sich auf die Art und Weise ausgewirkt, wie wir Projekte auswählen, Terminplanungen durchführen und Probleme in Projekten handhaben.“
  • „Den Stakeholder Bias in unser Dashboard aufzunehmen und bei Portfoliomeetings zu besprechen, hat unseren fachlichen Austausch verbessert.“
  • „Dank des Stakeholder Bias wird unser PMO jetzt nicht mehr als Überwachungsinstrument, sondern als aktiver Teil des Projekts wahrgenommen.“
  • Egal um was für einen Typ von PMO es sich handelt, das Ziel eines jeden PMO ist der Einsatz der bestmöglichen Projektmanagement-Methoden. Daher empfiehlt es sich, dass PMO-Manager die Standpunkte der Auftraggeber bei ihren PMO-Praktiken berücksichtigen. Wie andere bereits zuvor, werden auch sie ein sehr zufriedenstellendes Ergebnis bekommen.

 

Referenzen

1 Dieses Whitepaper basiert auf Büchern und Artikeln des Autors. Siehe:

  1. Mark P. Perry, Business Driven PMO Setup – Practical Insights, Techniques and Case Examples for Ensuring Success (Plantation, Florida: J. Ross Publishing, 2009)
  2. Mark P. Perry, Business Driven Project Portfolio Management – Conquering the Top 10 Risks that Threaten Success (Plantation, Florida: J. Ross Publishing, 2011)
  3. Mark P. Perry, Business Driven PMO Success Stories – Across Industries and Around the World (Plantation, Florida: J. Ross Publishing, 2013)
  4. Mark P. Perry, The Purpose of Project Management, (10. August 2017)
  5. Mark P. Perry, The Project Management Triangle, (5. September 2017)
  6. Mark P. Perry, Stakeholder Bias, (6. September 2017)

2 What is Project Management? The Project Management Institute 2019

3 Brian Miller, The Purpose of Project Management and Setting Objectives, Project Smart 2019