Komplexität ist eine der grossen Herausforderungen unserer Zeit

Doch was ist Komplexität? Was auch immer Sie sich darunter vorstellen, es ist etwas, was wir in erster Linie als unangenehm wahrnehmen. Manchmal verspüren wir fast körperliche Pein, wenn uns Komplexität plagt. Daher versuchen wir zunächst reflexhaft, die Komplexität loszuwerden. Stephanie Borgert schreibt:

Jeder kennt sie, jeder erlebt sie, manche können sie ganz klar benennen, aber keiner will etwas damit zu tun haben

Sie kann Ihnen zwar die Komplexität auch nicht abnehmen, zeigt aber in ihrem neusten Buch Die Irrtümer der Komplexität, wie Sie sich mit ihr versöhnen können (1).

komplexitätKomplexität gab’s schon immer. Aber mit ihr ist es, wie mit der Weltbevölkerung: sie wächst exponentiell und hat in letzter Zeit eine rasante Steigung erreicht. Während wir im 19. und anfangs 20. Jahrhundert noch nicht wirklich darunter litten, macht uns die Komplexität unserer Welt, unserer Wirtschaft und Gesellschaft, in letzter Zeit immer mehr zu schaffen. Zu vieles ist miteinander vernetzt. Die Unterscheidung zwischen Ursachen und Wirkungen löst sich auf. Wenn wir an einer Ursache schrauben erweist sich die Wirkung verzögert als Ursache der Ursache. Unser Kausalitätsdenken gerät ins Schwanken. Zum Glück!

Stefanie Borgert schreibt weiter:

Als Führungskraft und Manager wir von Ihnen erwartet, dass Sie Ihre Zahlen, Perspektiven, Ziele, Risiken, Kennzahlen und Mitarbeiter jederzeit benennen, steuern, kontrollieren und erklären können. Das sollten Sie dann bitte in einfachen Kausalitätszusammenhängen tun

Aber „komplexe Aufgaben und Probleme lösen sich durch Vereinfachung nicht auf“. Lineare Kausalitätsketten (sog. „Laundry-List-Thinking“), Vereinfachungen, Best-Practice-Lösungen und Expertentum sind alles Versuche, Komplexität zu reduzieren. Doch Komplexität lässt sich nicht reduzieren. Komplexe Systeme brauchen komplexe Antworten!

Als Antwort auf die Frage, was angesichts erhöhter Komplexität getan werden kann, beschreibt Borgert internationale Initiativen (nicht „Projekte“!), um nach dem Erdbeben vom 12. Januar 2010 auf Haiti schnell Verschüttete und in Lebensgefahr geratene Menschen zu finden. Die Initiativen waren spontan initiiert, stark miteinander verbunden, obwohl es keine zentrale Steuerung oder Koordination gab, und die einzelnen Gruppen, die sich für diverse Aufgaben zusammenfanden, waren hochspezialisiert. Genauso arbeitet auch unser Gehirn. Das nennt sich Selbstorganisation, ein Phänomen, das Borgert in ihrem Buch immer wieder antrifft und bei Anwesenheit von Komplexität typisch ist.

Nicht Planung, Projektmacherei oder starke, heldenhafte Führung sind Rezepte gegen Komplexität, sondern Diversität, Perspektivenwechsel, Szenariendenken und Augenhöhe.

Stephanie Borgerts Buch ist wohl eines der besten, die es im Moment zum Thema „Komplexität“ gibt.

In diesem Sinne: Bleibe erfolgreich, Stephanie!

(1) Stephanie Borgert. Die Irrtümer der Komplexität – Warum wir ein neues Management brauchen. Gabal Verlag, Offenbach 2015. ISBN 978-3-86936-661-6.

Sollen Muster gebrochen werden?

Das Thema des Barcamps über Projektmanagement, das vom 19. bis am 21. November in Dornbirn stattfindet, lautet „Muster brechen“.

Ein Musterbeispiel

In komplexen Projekten gibt es in der Tat viele Muster. Davon lebt die Komplexität des Projekts. Einige Muster könnten das Projekt verzögern. Folgendes Beispiel soll das illustrieren:

Es wird immer deutlicher, dass die verbleibende Arbeit in der nur noch kurzen Zeit bis zum geplanten und versprochenen Fertigstellungstermin des Projekts nicht bewältigt werden kann. Es ist offensichtlich, dass das Projekt nicht rechtzeitig fertig wird. Was tun?

In Wann kippt ein Projekt und warum? habe ich dargelegt, dass sich für viele vermeintlich fertig gestellte Arbeiten nachträglich herausstellt, dass sie noch Mängel aufweisen und nachgebessert werden müssen. Das nennt sich „Rework Cycle“. Manchmal gibt es explizit eine Qualitätssicherung, die gute Arbeiten durchwinkt und mangelhafte identifiziert. In IT-Projekten übernehmen Tests diese Aufgabe.

Symptomatische versus fundamentale Lösung

Wenn man sieht, dass der gesamte Arbeitsbacklog in der verbleibenden Zeit nicht mehr zu erledigen ist, wäre die symptomatische Lösung, zum Schluss auf die Qualitätssicherung zu verzichten und alle Arbeiten als „definitiv erledigt“ zu deklarieren. Damit könnte das Projekt in der Zeit abgeliefert werden. Allerdings besteht die Gefahr, dass der Kunde beträchtliche Mängel reklamiert, deren nachträgliche Bearbeitung teuer zu stehen käme, ganz zu schweigen von dem Imageverlust.

Demgegenüber steht die fundamentale Lösung, die Qualitätssicherung bis zum Schluss durchzuziehen und das Projekt zu spät abzuliefern, auf die Gefahr hin, Konventionalstrafe bezahlen zu müssen. Diese ist aber berechenbar.

Wir können die Situation so darstellen:

Shifting_the_Burden_Projekt

 

Die blauen Pfeile stellen einen verstärkenden Einfluss dar, die roten einen abschwächenden (1). Das liest sich also so: Je grösser das Problem, dass sich das Projekt verzögert, desto grösser meine Lösungsanstrengung, die QA zu umgehen. Je mehr ich die QA umgehe, desto kleiner wird das Problem, dass sich das Projekt verzögert.

Die symptomatische Lösung entpuppt sich als Sucht

Sollte ich während der symptomatischen Lösung plötzlich „kalte Füsse“ bekommen und mich doch noch für die fundamentale Lösung entscheiden, käme ich in erhebliche Argumentations-schwierigkeiten. Denn erklären Sie einmal dem Kunden kurz vor Projektabschluss, warum vieles von dem, was Sie am Schluss gemacht haben, mangelhaft ist und das Projekt jetzt doch nicht, wie erwartet, fertig wird.

Je mehr ich also von der symptomatischen Lösung Gebrauch mache, desto unglaubwürdiger würden meine Erklärungen, wenn ich mich plötzlich doch für die fundamentale Lösung entscheiden möchte. Das bedeutet, dass die fundamentale Lösung immer mehr abrückt, je mehr und je länger ich den Weg der symptomatischen Lösung begehe. Die symptomatische Lösung wird dadurch zu einer Art „Sucht“, von der man nicht mehr abrücken kann oder wenn, dann nur mit externer Hilfe.

Shifting_the_Burden_Projekt_ganz

 

Brechen des Musters

Dieses Muster wird „Problemverschiebung“ genannt und ist eines von zehn berühmten Mustern, die nach Peter Senge „Systemarchetypen“ genannt werden (2). Zu jedem dieser Muster gibt es eine Durchbrechungsstrategie (3).

Die symptomatische Lösung ist immer der schnelle und bequeme Weg. Im Geschäftsleben wird diese Lösung bevorzugt, weil es meist schnell gehen muss und keine Zeit für fundamentale Lösungen zur Verfügung stehen. Die unsolide Basis der symptomatischen Lösungen holen einem aber meist auf schmerzliche Art ein. Daher sollte sie unbedingt vermieden werden.

Ich bin mir jedoch nicht sicher, ob es in jedem Fall richtig ist, diese Muster zu brechen, in der Meinung, dadurch das Projekt zu beschleunigen. Es könnte auch sein, dass durch das Brechen von irgendwelchen Mustern die Projektkomplexität leidet, was dazu führen würde, dass das Projektziel nicht erreicht wird.

Anmerkungen

(1) Genau genommen sollten wir sagen: die blauen Pfeile sind gleichgerichtet in dem Sinne, dass wenn die Ursache zunimmt, dann auch die Wirkung zunimmt, und wenn die Ursache abnimmt, dann die Wirkung ebenfalls abnimmt. Die roten Pfeile sind gegen-gerichtet in dem Sinne, dass wenn die Ursache zunimmt, dann nimmt die Wirkung ab, und wenn die Ursache abnimmt, dann nimmt die Wirkung zu.
Mit „Ursache“ bezeichne ich hier bloss die Grösse, bei der der Pfeil startet und mit „Wirkung“ bezeichne ich die Grösse, bei der der Pfeil endet. In einem solchen zyklischen Diagramm gibt es aber keine ultimativen Ursachen und Wirkungen.

(2) Die fünfte Disziplin: Kunst und Praxis der lernenden Organisation. Schäffer-Poeschel; 11. Auflage,völlig überarbeitete und aktualisierte Auflage (11. März 2011). ISBN 978-3791029962

(3) http://www.anchor.ch/wissen/Archetypendiagramme.html

(4) Die Figuren wurden mit kumu.io gemacht: https://kumu.io/peteraddor/shifting-burden-project#shifting-burden-project

Eine kleine Zwischenbemerkung über das Unterdrücken unangenehmer Tatsachen

Im Zusammenhang mit einer längeren Rechnung fragte ich kürzlich einen meiner Studenten, was die Wurzel aus 2(b+c)^2 sei. Er antwortete „b+c “. Als ich fragte, wo die 2 geblieben sei, hat er lange versucht, mich mit ausweichenden Antworten zufrieden zu stellen. Er übersah partout die Wurzel aus 2. Nach einigem Ringen hatte er es verstanden und ging in sich, um herauszufinden, warum er es nicht gleich richtig gemacht hat. Er kam dann mit der Erklärung, dass er sich gegen die Wurzel gewehrt hatte, weil er sie nicht in seiner Rechnung haben wollte.

Am besten, man übersieht unangenehme Kleinigkeiten generös

Das scheint mir ein verbreitetes Verhalten zu sein. In der Mathematik (oder Programmierung) lassen sich solche unangenehmen Kleinigkeiten nicht einfach unter den Teppich kehren. Das fällt auf, die Rechnung stimmt nicht oder das Programm läuft nicht.

In Politik und Wirtschaft hingegen sind die Sachlagen noch komplizierter als mathematische Aufgaben und vor allem diffuser. Unangenehme Kleinigkeiten lassen sich unter diesen Voraussetzung vorzüglich ausblenden und verleugnen, was aber fatale (Langzeit-) Folgen haben kann. Dabei ist es den Entscheidern oft nicht einmal bewusst, dass sie wichtige Tatsachen ausblenden. Warum erwarten wir, dass vor allem in Krisenzeiten die Regierung sofort präsent ist, eine starke Hand zeigt und dezidierte Lösungen anbietet? Besser wäre vielleicht, wenn die Entscheider sich zunächst zurück ziehen und fragen, was eigentlich los ist, um auszuschliessen, dass keine Tatsachen verdrängt werden, die für die Entscheidungen massgebend sein können.

Ein gutes Weltbild ist etwas praktisches

Karlheinz, zieh den Vorhang ein wenig! Es blendet.
Karlheinz, zieh den Vorhang ein wenig! Es blendet.

Die Heuristik des Verleugnens unangenehmer Tatsachen lässt sich auch ganz gut für jede Art von Polemik missbrauchen. In diffusen und komplizierten Situationen können Details, die aber nichtsdestotrotz wichtige Konsequenzen zur Folge haben, unbemerkt weggelassen werden. Das fällt weder den Entscheidern, noch den Betroffenen auf. Beispielsweise können radikale Bewegungen und Organisationen unter dem Vorwand, sich um das Gesamtwohl zu kümmern, Argumente anführen, die auf den ersten Blick stechen, aber eben Details verleugnen, die das fundamentalistische Weltbild möglicherweise einstürzen lassen würden.

Dietrich Dörner nannte dies reduktive Hypothesenbildung (1). Er schreibt:

Die Tatsache, dass solche reduktiven Hypothesen Welterklärungen aus einem Guss bieten, erklärt vielleicht nicht nur ihre Beliebtheit, sondern auch ihre Stabilität. Wenn man einmal weiss, was die Welt im Innersten zusammenhält, so gibt man ein solches Wissen ungern auf …. Mittel, um einmal aufgestellte Hypothesen gegen Falsifikationen zu verteidigen und gegen jede Erfahrung aufrechtzuerhalten, gibt es viele.

Ich hüten mich vor allzu glatten Argumenten und Weltanschauungen. Mir sind Suchende lieber, als solche, die die Weisheit mit Löffeln gefressen haben wollen.

(1) Dietrich Dörner. Die Logik des Misslingens. Strategisches Denken in komplexen Situationen. Rowohlt Taschebuch, Reinbek b. Hamburg 1992

 

Wann kippt ein Projekt und warum?

Der „Rework Cycle“ ist eines der am besten untersuchten Phänomene des Projektmanagements. Ich habe schon mehrmals über den Rework Cycle geschrieben, z.B. hier

Die effektivste Massnahme, um Projektverzögerungen zu minimieren 

und hier

Projekten in den Rachen geschaut .

Beim Rework Cycle handelt es sich um die Tatsache, dass erledigte Arbeit nicht immer endgültig ist. Es kann sich nachträglich herausstellen, dass sie Fehler enthält, und dass sie deshalb nachgearbeitet werden muss. Zusätzlich können die Rahmenbedingungen des Projekts ändern, so dass gewisse Resultate überarbeitet werden müssen.

Das führt in jedem Fall zu ungeplanten zusätzlichen Aufwänden.

Das Grundmodell

Diesmal will ich auf eine Konsequenz des Rework Cycle eingehen, die im Englischen „Tipping Point“ genannt wird, auf Deutsch vielleicht mit „Kipppunkt“ übersetzt. Es gibt Projekte, die nie fertig werden, während andere zwar einmal abgeschlossen werden können, aber nur mit grosser Verzögerung. Das kann daher kommen, dass das Projekt mehrmals seinen Kipppunkt überschreitet.

Die herkömmliche Rework-Cycle-Struktur eines Projekts sieht so aus.

ReworkCycle_Basis

Erledigte Arbeiten können sich als fehlerhaft oder überholt herausstellen, was zur Folge hat, dass sie korrigiert oder nachgebessert werden müssen. Manchmal wird das zufällig entdeckt, manchmal gibt es tatsächlich Quality Assurements. Vor allem in IT Migrations- und Integrationsprojekten, die hauptsächlich aus Tests bestehen, zeigt ein nicht bestandener Test fehlerhafte Arbeiten an. Die Software muss nachgebessert und der Test wiederholt werden.

Zusätzlich generierte Arbeiten

Bestandene Tests weisen darauf hin, dass die Arbeiten endgültig erledigt sind. Sie fliessen dann quasi in den Bestand der „released work“. Es ist also der Qualitätssicherungsprozess, der die erledigten Arbeiten freigibt und somit das Projekt vorantreibt.

Auf der anderen Seite verzögert jede Nachbesserung das Projekt. Dazu kommt, dass jedes Mal, wenn eine fehlerhafte Arbeit entdeckt wird, neue zusätzliche Arbeit generiert wird. Im Fall der IT Migrations- und Integrationsprojekte nennen sich die zusätzlichen Arbeiten Regressionstests. Ist einmal ein Softwarefehler erkannt, so muss er nachgebessert werden. Danach genügt es nicht, denselben Test noch einmal zu fahren, denn durch die Nachbesserung wurden ja vielleicht in ganz anderen Modulen neue Fehler eingebaut. Daher müssen weitergehende Tests entwickelt und durchgeführt werden. Das sind grundsätzliche neue, ungeplante Arbeiten. Im der Abbildung heisst die Ursache solcher neuen Arbeiten „Ripple Effect“.

ReworkCycle_Ripple

Während also der Loop B1 das Projekt vorantreibt, bremst der Loop R1 das Projekt aus. Je nachdem, welcher der beiden Loops überwiegt, ist das Projekt unterhalb der Kipppunktlinie oder oberhalb. Unterhalb bedeutet, dass es dem Ende zustrebt. Oberhalb entweicht es in den Zustand des nie Fertigwerdens.

Die Kipplinie

Die Linie ist in einem Koordinatensystem, welches auf der waagrechten Achse den Fertigstellungsgrad zur Zeit t-1 abträgt und auf der senkrechten Achse den Fertigstellungsgrad zur Zeit t, also zum jetzigen Zeitpunkt. Der Fertigstellungsgrad berechnet sich aus dem Quotient der noch zu erledigenden Arbeitet und der zu Beginn vorgesehenen Arbeiten. Zu Beginn, wenn noch nichts abgearbeitet ist, beträgt also der Fertigstellungsgrad 1.

Die Zeit könnte z.B. in Tagen gemessen sein, so dass also t-1 gestern war und t heute. Ist der Fertigstellungsgrad heute etwas kleiner als gestern, befindet sich das Projekt unterhalb der Kipppunktlinie, die hier als Diagonale eingezeichnet ist und das Projekt ist auf gutem Weg. Umgekehrt droht das Projekt aus dem Ruder zu laufen, wenn der Fertigstellungsgrad heute grösser ist als gestern.

ReworkCycle_Kipp

Häufig kommt es vor, dass das Projekt die Kipppunktlinie mehrmals kreuzt, um dann schliesslich oberhalb der Linie zu bleiben. Zunächst kommt es zu Oszillationen, indem mehrere unvorhergesehene Ereignisse das Projekt immer wieder zurück werfen, die Rückstände aber jedes Mal aufgeholt werden können. Schliesslich wird aber doch immer mehr Arbeit generiert, als abgearbeitet werden kann und das Projekt muss abgebrochen werden.

ReworkCycle_Oszil

Dass das tatsächlich beobachtet werden kann, zeigt das Beispiel der US-Kraftwerke „Watts Bar“. Das Projekt hat die 80%-Linie knapp überschritten. Danach fiel es wieder zurück und musste nach ca. 8 Jahren abgebrochen werden. Vermutlich sähe das entsprechende Diagramm des Berliner Flughafens ganz ähnlich aus.

ReworkCacle_WattsBar

(Alle Illustrationen stammen aus der Präsentation von David N. Ford. Tipping Point Dynamics in Large Development Projects )