Archiv der Kategorie: System Dynamics

Im Himmel ist alles viel einfacher

Kürzlich nahm ich an einer Strategiediskussion einer Gruppe von Mitgliedern einer humanitären Organisation teil. Es ging dabei um die Frage, welche humanitären Aktionen man als nächstes in Angriff nehmen wolle. Nachdem sich unterschwellig ein paar Konflikte abzeichneten, lief die Diskussion darauf hinaus, dass man nur noch Ideen sammelte, wem man Geld spenden will. Anstatt zu überlegen, was man mit den eigenen Kräften tun könnte, begann man aufzuzählen, welche notleidenden Zielgruppen es gibt, die die Hilfe nötig haben. Eine solche Aufzählung ist leider sehr einfach, denn die Not in der Welt ist bekanntlich gross. Am Schluss überlegte sich die Gruppe, wem sie grosszügigerweise Geld zukommen lassen will, ob der Schule in einer ärmlichen Region Osteuropas oder Brandopfern in einer hiesigen Universitätsklinik. Es ist natürlich bedeutend angenehmer, in Gedanken Geld zu verteilen, als zu überlegen, was man arbeiten sollte. Schliesslich bestimmte die Gruppe ein Mitglied, das sich bis zum nächsten Treffen Gedanken machen soll, mit welcher konkreten Aktion man das Geld verdienen könnte, das man dann der Zielgruppe zukommen lassen will.

Solche Diskussionen erlebe ich in Projekten und im Management fast täglich. Wenn einer darauf hinweist, dass man thematisch abgleite, wird ihm unwirsch erklärt, dass die Diskussion von Grundfragen der wirklich wichtige Schritt sei. Psychologen nennen diesen Verhalten vertikale Flucht. Stefan Strohschneider schreibt darüber, dass man sich von der Ebene profanen Handelns löst und sich in Gedanken damit beschäftigt, wie es wäre, wenn die Probleme schon gelöst seien. Dazu gehört auch die ständige Entwicklung neuer Zielvorstellungen, gekoppelt mit dem Verschleppen von Terminen, bei denen man sich konkret mit dem in Frage stehenden Problemen auseinander setzen müsste. In einer angenehmen Gruppenatmosphäre wird besonders die Vermeidung von Konflikten wichtig1. Die Gruppe verlegt sich auf die angenehme oder beherrschbare Ebene (hinauf, deshalb vertikale Flucht genannt) und erklärt, dort die eigentlichen Grundfragen des Projekts zu behandeln. Vor allem, wenn die Vergangenheit von Misserfolgen geprägt war, kapselt man sich gerne gegenüber unangenehmen oder schwierigen Fragen ab. Harald Schaub erklärt das Phänomen der Einkapselung so: Handeln in komplexen Realitäten ist für viele Entscheider gekennzeichnet durch ständig neue Probleme und Schwierigkeiten, durch Misserfolge, Pannen und Enttäuschungen. Es ist kaum verwunderlich, wenn in solchen Konstellationen die Tendenz zur Einkapselung in gut beherrschte Realitätsausschnitte zu beobachten ist. Der frustrierte [Projektmanager] sucht seine Aufgaben nicht mehr nach deren Wichtigkeit und Dringlichkeit aus, sondern nach der individuellen Bewältigbarkeit, also nach der Erfolgswahrscheinlichkeit. Er macht das, was er kann und vergisst, was er machen sollte2. Beide Fehler – vertikale Flucht als auch Einkapselung – können als Verschiebung des Problems betrachtet werden. Peter Senge hat 1990 zehn Handlungsarchetypen beschrieben3. Eine davon nannte er Shifting the Burden. Das eingangs erwähnte Problem der humanitären Organisation liesse sich mit dem Shifting-the-Burden-Archetypus wie folgt darstellen:

Ursprünglich wurde eine Aktionsidee gesucht, also eine Grobbeschreibung der Aktion, mit der man notleidenden Menschen helfen will. Die grundsätzliche Lösung wäre also, den Prozess zu planen, mit dem man helfen will. Stattdessen beschreibt man lieber, wem man helfen will. Das ist eine symptomatische Lösung. Die Vorstellung, man hätte das Geld, das man spenden will, bereits verdient und könnte es nun dem Nutzniesser übergeben, ist sehr angenehm. Immerhin weiss man nun, wem man helfen will und braucht nur noch die Kleinigkeit einer Aktionsbeschreibung. Diese delegiert man und schiebt damit die Entscheidung über den eigenen Arbeitseinsatz hinaus. Je mehr man den Endzustand beschreibt, desto glücklicher werden die Diskussionsteilnehmer und umso weniger sehen sie die Notwendigkeit, einen Arbeitsprozess beschreiben zu müssen. Zwar hat man am Schluss des Tages das Gefühl, etwas erreicht zu haben. Die ursprünglich gestellte Aufgabe ist anscheindend gelöst. Spätestens aber, wenn der Delegierte seine Vorschläge vorstellt, beginnt die Diskussion auf’s Neue, diesmal aber viel heftiger.

1Stefan Strohschneider. Kompetenzdynamik und Kompetenzregulation beim Planen. In S. Strohschneider/R. van der Weth (Hrsg). Ja mach nur einen Plan – Pannen und Fehlschläge – Ursachen, Beispiele, Lösungen. S. 35-51. Verlag Hans Huber. Bern 2002

2Harald Schaub. Exception Error“: Über Fehler und deren Ursachen beim Handeln in Unbestimmtheit und Komplexität. In: gdi impuls 4. Gottlieb Duttweiler Institut, Rüschlikon 1996.

3Peter M. Senge. Die Fünfte Disziplin – Kunst und Praxis der lernenden Organisation. Klett-Cotta. Stuttgart 1996.

Projekten in den Rachen geschaut

Eines der ersten Projektmodelle veröffentlichte Ed Roberts 19641. In den frühen achtziger Jahren ebnete das Modell von Pugh-Roberts2 den Weg zum berühmten Modell mit dem sogenannten Rework Cycle. Ausgehend von einem Bestand an unerledigter Arbeit, der entsprechend der vorhandenen Produktivität abgearbeitet wird, fliesst ein Teil der erreichten Resultate in einen Bestand an erledigter und abgeschlossener Tasks, während ein anderer Teil Fehler enthält und in einen Bestand undiscovered Rework fliesst. Das sind also solche Tasks, die unbrauchbar sind und später nachgearbeitet werden müssen. „Später“ ist dann, wenn das Projektteam die Fehler wahrgenommen hat. Dann existiert ein Bestand an unerledigter Rework, der neben der geplanten Arbeit zusätzlich gemacht werden muss. Das führt zu einer Verzögerung in der Projektabwicklung. Folgende moderne Darstellung des sogenannten Rework Cycle lieferte Cooper 19933:

Zum Vergrösseren klicken Sie auf die Figur, die aus dem Überblicksartikel von Lyneis und Ford stammt4. Nach diesem Modell flacht der Fortschritt während der Laufzeit des Projekts vorübergehend ab, bevor er wieder anwächst. Das führt zum bekannten 90 % Syndrom. Nähere Einzelheiten hat James Lyneis in einer aufschlussreichen Powerpointpräsentation festgehalten5. Der Rework Cycle ist eines der best untersuchten Phänomenen im Projektmanagement. Unglücklicherweise betreffen alle diese Untersuchungen vor allem Entwicklungsprojekte und nicht so sehr Migrations- und Integrationsprojekte. Für diese steht ein valides Modell noch aus. In Migrations- und Integrationsprojekte kommt neben dem Rework Cycle vor allem ein „New work Cycle“ in’s Spiel, der viel gravierender ist.

Quellen:

1Ed B. Roberts. The Dynamics of Research and Development. Harper and Row. New York 1964

2Richardson, George P. and Pugh III, Alexander L. Introduction to System Dynamics Modeling with Dynamo. MIT Press. Cambridge, MA 1981

3Kenneth G. Cooper (1993). The Iteration Cycle: Benchmarks for Project Managers. Project Management Journal. Vol. 24, No. 1 and
Kenneth G. Cooper (1993). The Iteration Cycle: How Projects are Missmanaged. Project Management Journal. Vol. 24, No. 1

4James M. Lyneis and David N. Ford. System dynamics applied to project management: a survey, assessment, and direction for future research. In System Dynamics Review, 23/2007, No. 2-3. S. 157-189.

5James M. Lyneis. Dynamics of Project Performance (2003). Powerpoint Presentation. Massachusetts Institute of Technology MIT