Verhaltensmuster im Projektmanagement Teil 1: Zielanpassungen

Ich habe oft das zu statische Vorgehen nach den alt bekannten Methoden, wie beispielsweise PMI oder Prince2, im Rahmen von Projektmangement kritisiert. Dabei werden nämlich Dynamiken nicht erkannt und dementsprechend nicht behandelt. Diese Kritik möchte ich zum Anlass nehmen, eine Post-Reihe zu starten, in welcher ich prominente Verhaltensmuster, die wahrscheinlich jeder, der schon einmal in Projekten tätig war, kennt, beleuchte. Dies werde ich stets nach dem gleichen Muster tun. Starten werde ich mit der Beschreibung der Verhaltensmuster. Danach werde ich das Verhaltensmuster in einem qualitativen Modell auf Basis der Systemarchetypen von Peter M. Senge reflektieren. Abschließend werde ich das qualitative Modell quantifizieren und auf Basis von Simulationen Implikationen der Verhaltensmuster validieren. Für die Quantifizierung der Modelle werde ich die System Dynamics Methode nutzen. Die qualitativen und quantitativen Modelle erstelle ich mit dem CONSIDEO MODELER. Mit dieser Post-Reihe komme ich auch dem Wunsch nach, der mich häufig ereilt hat, nämlich aufzuzeigen, wie man von qualitativen zu quantitativen Modellen kommt.

Also legen wir los.

Heute möchte ein oft von mir beobachtetes Szenario thematisieren. Man startet ein Projekt mit hochgesteckten Zielen. Alle Beteiligten sind motiviert. Nach und nach werden in Statusberichten eine Diskrepanz zwischen dem Status und den Zielen festgestellt. Es werden Maßnahmen definiert, diese Diskrepanz zu schließen. Nach einer gewissen Projektlaufzeit, die verbliebende Zeit zum Go Live wird immer kürzer und die Maßnahmen, die man definiert hat, um den Status zu verbessern, fruchten nicht richtig, werden Scopediskussionen entfacht. Man diskutiert, in welchen Bereichen der Scope des Projektes minimiert werden kann. Einhergehend setzt man das ursprünglich gesteckte Ziel des Projektes herunter. Das macht man in dem Glauben, dass dann auf jeden Fall die Diskrepanz zwischen Status und Ziel gestopft wird. Das Datum des Go Live ist heilig, da ein Verschub ja eine große Außenwirkung hat. Kleinere Scopeminimierungen dringen ja nicht so nach außen und falls ja kann man sie ja schön reden oder gar wegdiskutieren. Nur sehr häufig stellt man wiederum nach einer gewissen Zeit auch bei dem minimierten Scope eine Diskrepanz zwischen Ist und Soll fest. Eine Abwärtsspirale wurde entfacht. Warum ist das so? Qualitativ möchte ich dies am Systemarchetyp Erodierende Ziele erklären. Die folgende Abbildung zeigt das qualitative Modell dieses Archetyps, erstellt im CONSIDEO MODELER.

In dem obigen Modell erkennen Sie 2 ausgleichende oder balancierende Schleifen bezogen auf das Gap zwischen Projektstatus und Projektziel. Innerhalb der linken Schleife wird nach der Wahrnehmung des Gaps zwischen Status und Ziel die Anstrenung erhöht, den Status zu verbessern. Das kennzeichnet das “+” an den Pfeilen. Man verfolgt damit die Intension, dass, wenn der Status besser wird, das Gap zum Ziel geschlossen werden kann. Das stellt das “-” dar. Schauen wir uns die rechte Schleife an. Hier reflektieren wir den Fakt, dass ein Projekt nicht losgelöst durchgeführt wird, sondern innerhalb einer Umwelt, die gewisse Erwartungen in das Projekt setzt. Mit Erwartungen geht natürlich der Druck einher. Wenn also das Gap zwischen Status und Ziel groß ist, steigt der Druck dieses schließen zu müssen. Das kann wahrscheinlich Jeder, der in Projekten gearbeitet hat, bezeugen. Diese Beziehung ist mit dem “+” dargestellt. Steigt also der Druck, steigt damit der Zwang, den Scope des Projektes zu verringern, da man dadurch die Ziele heruntersetzt, was wiederum zu einer Verringerung des Gaps führt. Beide Schleifen schwingen sich balancierend auf ein Fließgleichgewicht des Gaps ein. Das bedeutet aber nicht notwendigerweise, dass das Gap geschlossen wird, was wünschenswert ist. Das Gap kann auch ein Fließgleichgewicht ungleich Null annehmen. Um zu untersuchen, wann je eine der Varianten eintritt und welche Implikationen diese haben, müssen weitergehende Untersuchungen angestellt werden, die man nur durch Quantifizierung des Modells erreicht.

Die folgende Abbildung stellt das finale quantitative Modell dar. Durch einen Klick auf die Abbildung können Sie das Bild vergrößern. Die grün hinterlegten Faktoren sind die Faktoren, die Sie bereits aus dem qualitativen Modell kennen.

Keine Angst, falls Ihnen das Modell zu unübersichtlich erscheint. Ich werde jetzt Schritt für Schritt dieses finale quantitative Modell aus dem qualitativen Modell herleiten, um dann Simulationen zu starten, die Aufschluss geben, wann das Gap Null werden kann und wann nicht. Die Bilder zu den Modellen finden Sie in dieser Datei.

Die Bilder werde ich auf Grund der Übersichtlichkeit in diesem Post nicht direkt einfügen. Ich beziehe mich in meinen Erklärungen stets auf die Folienseite, so dass Sie die Erklärungen gut nachvollziehen können. Des Weiteren werde ich in jedem Schritt, die neu aufgenommenen Faktoren blau hinterlegen.

Schritt 1: Quantifizierung des Modells mit Festlegung der Bestandsfaktoren Projektstatus und Projektziel

Die Folie 3 der oben gelinkten Datei stellt dieses Modell dar. Um ein qualitatives Modell zu quantifizieren, muss man entscheiden, welche Faktoren Bestandsfaktoren sein sollen. Daraus abgeleitet, muss man dann in der Regel Faktoren zufügen, die als Flussfaktoren fungieren. Bestandsfaktoren können im Sinne von System Dynamics nur durch Flussfaktoren erhöht oder gesenkt werden. Manchmal lassen sich auch bereits bestehende Faktoren zu Flussfaktoren umwandeln, aber eher selten. In unserem Fall ist es auch nicht so. Warum habe ich mich nun für Projektstatus und Projektziel als Bestandsfaktoren entschieden? Diese beiden Faktoren sind unsere zentralen Faktoren, über die wir Auswertungen, vor allem über die Zeit hinweg, machen wollen. Beide Faktoren tragen ihre Historie über den gesamten Zeitraum mit, beispielsweise hat der Projektstatus von vor 3 Wochen einen Einfluss auf den Status von heute. Bei Nicht-Bestandsfaktoren, wie beispielsweise der Anstrengung, ist das nur implizit der Fall, über die Historie des Projektstatus. Des Weiteren muss noch erwähnt werden, dass wir “Woche” als Simulationsschrittweite für das quantitative Modell definieren. Die Faktoren werden also bei der Simulation Woche für Woche errechnet. Das macht auch Sinn, da man in der Regel wöchentliche Statusmeetings durchführt. In diesem Dokument werden im Kapitel 2 Bestands- und Flussfaktoren sehr lehrreich und anschaulich eingeführt.

Im Modell gibt es 3 zusätzliche Faktoren, die als Flussfaktoren fungieren. 2 von diesen kann man sich aus dem qualitativen Modell relativ einfach herleiten. Der Faktor “Verbesserung des Scopes” erhält eine direkte Wirkung aus dem Faktor “Anstrengung” und der Faktor “Anpassung des Scopes” aus dem Faktor “Zwang für Anpassung”. Der Flussfaktor “Verschlechtern des Status” ist aus dem qualitativen Modell nicht so klar herleitbar. Es ist aber einleuchtend, dass der Projektstatus sich bei keinerlei Anstrengung, sprich wenn die Arbeit niedergelegt wird, schleichend verschlechtert. Das drückt dieser Faktor aus.

Schritt 2: Integrieren von Wahrnehmungsverzögerungen

Die Folien 3 bis 5 stellen die entsprechenden Zwischenmodelle dar. An den 3 Zwischenmodellen erkennen Sie, dass ich 3 Wahrnehmungsverzögerungen einbauen werde, und zwar sind dies

• Wahrnehmungsverzögerung des Projektstatus (Folie 3)
• Wahrnehmungsverzögerung des Gaps zwischen Projektstatus und Projektziel (Folie 4)
• Wahrnehmungsverzögerung des Anpassungsdrucks des Projektziels (Folie 5)

Warum macht es überhaupt Sinn Wahrnehmungsverzögerungen zu modellieren? Ganz einfach, weil diese in der Realität vorhanden sind. Wir Menschen können nur verzögert Dinge unserer Umwelt wahrnehmen und verarbeiten. Also warum diese dann nicht modellieren? Grundsätzliche Informationen zu Wahrnehmungsverzögerungen und wie diese in System Dynamics modelliert werden, können Sie in meinem Post Mit System Dynamics Dynamiken und Verzögerungen von Handlungen verstehen nachlesen. Im Abschnitt “Verzögerungen nach Typ” finden Sie Wissenswertes zu Wahrnehmungsverzögerungen, in dem Post als Verzögerung in Informationsströmen deklariert. Ich möchte nur für die erste Wahrnehmungsverzögerung, die des Projektstatus, die quantitative Modellierung erklären. Die anderen beiden Verzögerungen lassen sich entsprechend herleiten.

Nehmen Sie sich also bitte die Folie 3 zur Hand. Sie erkennen 4 zusätzliche Faktoren (blau hinterlegt). Einer dieser 4, nämlich “Sickerzeit”, hat nichts mit der Wahrnehmungsverzögerung zu tun. Dieser Faktor gibt an, nach wieviel Wochen sich der Status verschlechtert, wenn nichts getan wird. Konzentrieren wir uns auf die 3 Faktoren mit denen wir die Wahrnehmungsverzögerung modellieren. Erst einmal ist ersichtlich, dass ein Projektstatus immer nur verzögert wahrgenommen werden kann. Es laufen beispielsweise Diskussionen und Ergebnisse dieser müssen in Dokumenten zusammengefasst und präsentiert werden. Um den Projektstatus überhaupt zu erkennen, müssen Aktivitäten durchgeführt werden, wofür man Zeit benötigt. Nicht nur das. Dieser Status muss dann auch noch verinnerlicht werden. Auch dieser Fakt sollte nicht unterschätzt werden. Oft ist es so, dass sich Projektbeteiligte eine Scheinwelt aufbauen, die nur mit Mühe und Aufwand umgestoßen werden kann. Der Projektstatus ist quasi in der “realen Welt” vorhanden. Die Projektbeteiligten, in diesem Falle Beobachter, müssen zu diesem vordringen. Dazu benötigen sie Zeit. Dieses Vordringen wird mit dem Faktor “Wahrnehmung des Projektstatus” dargestellt. Der Kenntnisstand über den Projektstatus ist im Modell ein Bestand, weil sich dieser über einen Zeitraum aufbauen muss. Das ist der Faktor “Wahrgenommener Projektstatus”. Der Faktor “Wahrnehmungszeit Projektstatus” gibt die Zeit an, die die Projektbeteiligten benötigen, um den Kenntnisstand aufzubauen. Damit ergibt sich also für den Faktor “Wahrnehmung des Projektstatus” die folgende Formel:

([Projektstatus]-[Wahrgenommener Projektstatus]) / [Wahrnehmungszeit Projektstatus]

An der Formel kann man erkennen, dass der wahrgenommene Projektstatus niemals größer sein kann als der Projektstatus. Dieser nähert sich Schritt für Schritt dem Projektstatus an. Wir haben es hier also erkenntnistheoretisch mit einem “idealen Beobachter” zu tun. Denn ein Beobachter wird niemals den “realen Projektstatus” wahrnehmen können, weil er stets seine Subjektivität in die Wahrnehmung mit einbringt. Aber das möchte ich hier nur anmerken und nicht weiter ausführen (Details zur Erkenntnistheorie finden Sie ebenfalls in meinem Logbuch). Wir sind trotz dieser Einschränkung schon weiter als im herkömmlichen Projektmanagement, weil wir überhaupt modellieren und dann auch noch die Wahrnehmungsverzögerungen integrieren.

Basis für weitere Überlegungen ist dann stets der wahrgenommene Projektstatus, nicht der “reale”, kann ja auch nicht, denn nur von dem wahrgenommenen Status kann der Beobachter wissen. Das erkennen Sie daran, dass von dem Faktor “Wahrgenommener Projektstatus” der Wirkungspfeil in den Faktor “Gap” läuft. Wenn Sie ähnliche Überlegungen zu den beiden anderen Wahrnehmungsverzögerungen vollführen, erhalten Sie das Zwischenmodell auf Seite 6, welches wir nun weiter detaillieren.

Schritt 3: Integrieren von Wirkungsverzögerungen

Die Folien 6 und 7 enthalten die Modelle, in denen die beiden Wirkungsverzögerungen

• Wirkungsverzögerung der Änderung des Projektscopes (Folie 6)
• Wirkungsverzögerung der Erhöhung der Anstrengung (Folie 7)

integriert sind. Ähnlich wie bei den Wahrnehmungsverzögerungen verhält es sich mit den Wirkungsverzögerungen. Es macht Sinn diese zu modellieren, weil sie schlichtweg vorkommen. Bei den Wahrnehmungsverzögerungen kam der Input noch aus der Umwelt der Projektbeteiligten, den diese verarbeiten mussten und dafür Zeit benötigten. Die Projektbeteiligten sind Beobachter. Die Wirkungsverzögerungen sind das Komplement zu den Wahrnehmungsverzögerungen. Die Projektbeteiligten werden zu Handelnden und agieren basierend auf ihren Wahrnehmungen. Die Wirkungen auf die Umwelt geschehen auch wieder mit Verzögerungen, den Wirkungsverzögerungen. In dem unter Schritt 1 bereits aufgeführten Post Mit System Dynamics Dynamiken und Verzögerungen von Handlungen verstehen können Sie Details zu den Wirkungsverzögerungen studieren. Dort sind sie unter Verzögerung in Materialströmen geführt. Auch hier möchte ich nur die erste Wirkungsverzögerung, bzgl. der Änderung des Scopes, ausführlich erklären.

Nehmen Sie also bitte die Folie 6 zur Hand. Sie erkennen hier 6 neue Faktoren, die für die Modellierung der Wirkungsverzögerung verwendet werden. Dabei sind 3 davon ausschließliche Zeitparameter, die man auch weglassen könnte. Sie dienen nur der Parametrisierung der Zeitkonstanten. Das sind die Faktoren “Anpassungszeit des Ziels”, “Operationalisierungszeit der Entscheidung” und “Entscheidungszeit”. Mittels der anderen 3 Faktoren “Entscheiden über Anpassung des Scopes”, “Gefällte Entscheidung über Anpassung des Scopes” und “Wirksamkeit der Anpassung des Scopes” möchte ich die Modellierung der Wirkungsverzögerung erklären. Die Projektbeteiligten werden wie bereits erwähnt zu Handelnden. Sie verändern, in diesem Fall verringern sie den Scope. Diese Änderung manifestiert sich aber nicht sofort in der Umwelt, quasi von jetzt auf gleich. Das tut es genauso wenig, wie eine Badewanne nicht sofort von einer Sekunde auf die nächste mit Wasser gefüllt ist. Das schrittweise Manifestieren der Verringerung des Scopes wird durch den Bestandsfaktor “Wirksamkeit der Änderung des Scopes” modelliert. Nur was bereits wirksam geworden ist kann für weitere Aktivitäten überhaupt relevant sein. Diese wirksamen Teile stehen dann über den Flussfaktor “Gefällte Entscheidung über Anpassung des Scopes” für weitere Wahrnehmungen und Handlungen zur Verfügung. Das erkennt man in dem Modell daran, dass dieser Faktor Inputgeber für den Faktor “Anpassung des Scopes” ist. Diese Beziehung wird über die Formel

[Wirksamkeit der Anpassung des Scopes]/[Operationalisierungszeit der Entscheidung]

modelliert. Dabei gibt der Faktor “Operationalisierungszeit” die Dauer an, die für das Herstellen der Wirksamkeit benötigt wird. Wenn Sie ähnliche Überlegungen zu der zweiten Wirkungsverzögerung durchführen, erhalten Sie das finale Modell, welches auf Folie 7 oder oben in der zweiten Abbildung dargestellt ist. Dieses Modell ist nun Basis für die Simulation und Erkenntnisgewinnung.

Schritt 4: Simulation und Erkenntnisgewinnung

Die folgende Abbildung stellt das Simulationscockpit dar.

Auf der linken Seite sehen Sie die einstellbaren Parameter, die zur Erstellung von Szenarien zu nutzen sind. Auf der rechten Seite erkennen Sie das Diagramm, in welchem die Abhängigkeit von Projektstatus und Projektziel dargestellt ist. Ich möchte Ihnen 2 Szenarien vorstellen, die der Beantwortung der Frage dienen, unter welchen Umständen, das Gap zwischen Projektziel und Projektstatus Null wird, sprich wann das Ziel erreicht wird und wann nicht. Wir modellieren über 4 Jahre mit einer wöchentlichen Schrittweite, stets zum wöchentlichen Projektstatusmeeting.

Im ersten Szenario möchte ich nur den Parameter “Effizienz” variieren. Alle anderen Parameter bleiben konstant. In der folgenden Abbildung steht der linke Graph für eine Effizienz von 0.1 und der rechte für eine Effizienz von 0.4.

Was erkennen wir? Wenn die Effizienz der Arbeit eines Projektteams kleiner ist, nähern sich Status und Ziel auf einem geringeren Level an, als wenn diese höher ist. Das ist intuitiv. Es bedeutet aber auch, es macht schon definitiv Sinn, das Ziel zu korrigieren, wenn es nicht im Bereich des Machbaren liegt. Das habe ich in meinem Post Sind Ziele sinnlos auch ausgeführt. Wenn durch bestimmte Rahmenbedingungen im Projekt die Schaffenskraft des Teams “künstlich” verringert wird, erzeugt man natürlich auch eine Umgebung der verpassten Möglichkeiten. Das tatsächlich Erreichte und das Gewünschte werden sich auf einem niedrigen Niveau einpendeln. Es wird sich an dem Ziel ausgerichtet und nicht mehr als notwendig getan. Ein gutes Pferd springt nur so hoch wie es muss. Rahmenbedingungen, die künstlich von den Teams geschaffen werden, sind beispielsweise zu viele kleine Teams, die viele Schnittstellen bedingen, die zu einer hohen extrinsisch bedingten Integrationsnotwendigkeit führen. Hier kann man auch fehlende oder nicht klar formulierte Verantwortlichkeiten nennen, die von einem Arbeiten an der Sache ablenken.

Im zweiten Szenario möchte ich nur den Parameter “Entscheidungszeit” variieren und wiederum alle anderen Parameter konstant lassen. Damit variiere ich die Druckresistenz der Projektverantwortlichen, sprich, wie schnell sie das Ziel nach unten korrigieren. In der unteren Abbildung steht der linke Graph für eine Entscheidungszeit von 1 Woche und der rechte für eine von 15 Wochen.

In der obigen Abbildung erkennen Sie das sich wie erwartet ein Fließgleichgewicht zwischen Status und Ziel einstellt, das Ziel aber in der rechten Variante verfehlt wird. Wir erkennen, wenn die Entscheidungszeit für das Ändern des Scopes hoch ist, das Ziel zwar verfehlt wird, der erreichte Status aber trotzdem höher ist als im anderen Fall. Das hat etwas von selbsterfüllende Prophezeiung. In diesem Szenario ist die Schaffenskraft des Teams konstant. Das niedrige Ziel, welches man in der linken Graphik schneller auslobt, ist unter den Möglichkeiten des Teams. Die Auslobung des niedrigen Ziels führt dazu, dass das Team die Möglichkeiten nicht ausschöpft. Erfolg ist in gewisser Weise definierbar. Werden die Ziele kurzfristig korrigiert, wird das Erreichbare mit nach unten gezogen. Am Ende des Projektes wurde das Ziel erreicht. In der rechten Graphik erkennt man, dass das Ziel nicht erreicht wurde, das Projekt aber trotzdem mehr Nutzen generiert hat. Das Nichterreichen des Ziels hat für die Verantwortlichen eine schlechte Außenwirkung zur Folge, obwohl sie mehr Nutzen generiert haben. Das ständige Hochhalten der Ziele, die nicht erreichbar sind, kann Projektteams demotivieren, weil sie eben nicht nur eine schlechte Außenwirkung haben, sondern auch mit dem ständigen Gefühl umgehen müssen, ihre Ziele verfehlt zu haben. Das ist also ein zweischneidiges Schwert. Die Verantwortlichen des Projektes müssen also ganz genau wissen, was dem Team zugemutet werden kann und was nicht. Weder zu hohe noch zu niedrige Ziele sind gut.

Des Weiteren erkennen sie in diesem wie auch im ersten Szenario die für Verzögerungen typischen Oszillationen. Dieses Phänomen habe ich im Post Mit System Dynamics Dynamiken und Verzögerungen von Handlungen verstehen beschrieben. Speichern sie sich das Modell gerne ab und kreieren ihre eigenen Szenarien. Vielleicht gewinnen Sie so noch weitere Erkenntnisse. Viel Spaß dabei.

(Keine Bewertungen bislang. Geben Sie doch die erste ab.)

Loading...