Schlagwort-Archive: Systemarchetypen

Systemisches Denken mit Wirkungsnetzwerken

In einem meiner letzen Blogartikel forderte ich dazu auf, ein System Thinker zu werden. Ich denke, dass Sie mittlerweile genug Zeit hatten, sich mit System Thinking zu beschäftigen, so dass Sie folgendes Stück „System Thinking“ nachvollziehen können oder es dazu nutzen, um Ihre System Thinking Skills zu verbessern.

System Thinking kommt wohl ohne Causal Loop Diagrams (CLD) kaum aus. Ich möchte mich heute der Frage widmen, inwiefern ein Causal Loop Diagram als systemisches Darstellungsmittel genügt. Inspiriert dazu hat mich der Artikel The Ambiguity of Causal Loop Diagrams and Archetypes von Kim Warren.

Wer und was

Ich mag Kim Warren sehr. Er war 2013 Präsident der System Dynamics Society und ich habe ihn ein paar Mal auf einer SD Conference getroffen. Zudem nahm ich vor ein paar Jahren an einer seiner hochspannenden SD-Trainings teil.

Über Causal Loop Diagrams (CLD) – auf Deutsch vielleicht mit Wirkungsnetzwerk übersetzt – und Systemarchetypen habe ich hier schon oft geschrieben, z.B. in Kein einzelner Teil… und in Archetypendiagramme

Zwei Archetypen

Der Archetypus „Eroding Goal“ besagt, dass wir zu Beginn unsere Ziele zu hoch setzen, und wenn wir sie nicht erreichen können, schnell bereit sind, sie auf niedrigerem Niveau neu zu formulieren. Umgekehrt strengen wir uns immer mehr an, das Ziel zu erreichen. Ich habe diese Situation in Fallen gelassene Vorsätze von Dozenten, Studenten und Projektleitern beschrieben

Der Archetypus „Eroding Goal“ als CLD. Blaue Pfeile haben positive, rote negative Polarität.

Der Archetypus „Escalation“ skizziert die gegenseitige Konkurrenz zweier Parteien in ein und derselben Sache. Z.B. streben zwei Personen in einer Disziplin die Weltmeisterschaft an. Immer, wenn die eine einen Erfolg verbucht, fühlt sich die andere bedroht und gibt noch mehr, um das nächste mal die andere zu überbieten.

Der Archetypus „Escalation“ als CLD.

Die Diagramme sind mit insightmaker gezeichnet worden, ein freies Entwicklungstool, das Sie online und kollaborativ einsetzen können.

Gleiche Strukturen

Im erwähnten Artikel stellt Warren fest, dass beide Archetypen – „Eroding Goals“ und „Escalation“ – aus zwei zielsuchenden Loops bestehen und sieht sich deshalb ausserstande, den Unterschied der beiden Situationen mit einem CLD beschreiben zu können. Er folgert daraus, dass CLD uneindeutig und in gewissem Grad für eine präzise Beschreibung spezifischer (Unternehmens-)Situationen ungeeignet seien. Er räumt allerdings ein, dass der Einsatz von CLD dem „Laundry List“-Vorgehen von Nicht-System-Thinkers immer noch überlegen sei.

Warrens Definition, wonach ein Archetypus ein generisches CLD, zusammen mit einer speziellen Verhaltensstory sei, finde ich bestechend handlich. Gerade an ihrer Verhaltensstory können die beiden Archetypen – „Eroding Goal“ und „Escalation“ – sehr eindeutig voneinander unterschieden werden. Das fängt schon nur bei der Tatsache an, dass in „Eroding Goal“ bloss eine Partei in gewissem Sinne gegen sich selbst handelt, während es in „Eskalation“ zwei Parteien gibt, deren Handlungen sich an denjenigen des Gegners orientieren.

Dynamische Struktur

Warren plädiert dafür, nicht beim CLD stehen zu bleiben, sondern gleich den Schritt zum System Dynamics Modell zu machen, das erst die nötige Klarheit geben könne. Ich kann ihm in dieser Hinsicht nicht folgen. Ich glaube, seine Befürchtungen, dass ein CLD die nötige Eindeutigkeit fehle, sind zumindest dann übertrieben, wenn das CLD nach allen Regeln der Kunst erstellt wurde. Meine Kritik richtet sich vielmehr gegen die vielen Berater, die CLD ohne irgendwelche Grundkenntnisse und ohne grossen Zeitaufwand ihren Kunden teuer verkaufen.

Wenn Warren z.B. schreibt: „The loop structure is mathematically identical“, dann stimmt das nicht. In dem Archetypus „Eroding Goal“ werden Soll-Zustand (Ziel) und Ist-Zustand als Differenz verglichen („Lücke“). Das führt zu einer linearen Struktur. Im Archetypus „Escalation“ hingegen werden die Resultate beider Parteien zueinander in Relation gesetzt, was nicht-linear ist.

Dass die Loopstruktur dennoch gleich ist, liegt daran, dass die Stories sehr verwandt sind. In beiden Stories versuchen die Parteien, durch Anstrengung ein Ziel zu erreichen. Während jedoch in „Escalation“ das Ziel durch die andere Partei immer höher gesetzt wird, wird es in „Eroding Goal“ durch den „inneren Schweinehund“ immer mehr gesenkt.

Fluktuationen

Eine andere Aussage Warrens fordert mich zu einer Präzisierung heraus. Er schreibt: „For example, if A and B start with the same results, there is no escalation“. Das ist rein rechnerisch zwar richtig, verkennt aber die Funktionsweise lebender Systeme. In einem System, das weit vom Gleichgewicht entfernt ist, wird die Dynamik stets von sogenannten Fluktuationen geprüft. Fluktuationen sind in Stärke und Ort zufällig vorkommende Störungen, die gegen die herrschende Struktur verstossen.

In „Escalation“ versuchen die beiden Parteien ständig, sich selbst zu verbessern, ganz ungeachtet vom Resultat der Konkurrenz. Das führt auf alle Fälle zu Differenzen in den jeweiligen Resultaten, sogar, wenn beide Parteien mit exakt denselben starten würden.

Warrens Behauptung gilt bloss für Systeme, die sich in völligem Gleichgewicht befinden. Solche Systeme sind aber tot. In ihnen bewegt sich gar nichts mehr. In der Tat gäbe es auch keine Eskalation mehr.

Jedem CLD seine Story!

Für Warren ist erst ein System Dynamics Modell ein Modell. Für mich ist ein fachgerecht erstelltes CLD jedoch bereits ein (qualitatives) Modell. Allerdings steckt für mich bedeutend mehr hinter einem CLD, als bloss ein paar Parameter, die mit Pfeilen wirr verbunden sind.

Wenn also die generischen CLD der beiden Archetypen „Eroding Goal“ und „Escalation“ fast nicht unterschieden werden können, anhand ihrer Stories und weiteren Analysen lassen sie sich jedoch wohl unterscheiden. Das bedeutet für mich: zu jedem CLD gehört eine Story! Das erreichen Sie am besten, indem Sie sich zu Beginn fragen: „Welche Archetypen stecken in der zu untersuchenden Situation“ und die Modellierung auf diesen Archetypen aufbauen. Dann tragen Sie auch stets die Story mit. Zu einem einfach mal so hingeworfenen CLD eine passende Story zu finden, dürfte ungleich schwieriger sein.

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

Unmündigkeit ist ja so bequem!

In Man schlägt den Esel und meint den Sack habe ich ein typisches Migrationsprojekt vorgestellt, das dem Computerhersteller Hewlett-Packard HP mindestens 160 Millionen US-Dollar Verlust verursachte. Kleine unvermeidliche Programmierfehlerchen führten dazu, dass Bestellungen stecken blieben, ohne dass es jemand merkte. Einige der erzürnten Kunden erkundigten sich nach dem Liefertermin. Deren Bestellungen konnten gesucht und nachträglich erfüllt werden. Schlimmer war die Situation mit denjenigen Kunden, die gar nicht erst reklamierten, sondern gleich zu der Konkurrenz – z.B. Dell oder IBM – abwanderten.

Warum sind kleine Programmierfehler unvermeidlich? Weil der Entwickler niemals alle Eventualitäten voraussehen kann, auf die seine Software reagieren muss. Unerwartete Situationen sind unvorhersehbar, andernfalls wären sie nicht unerwartet. In solchen Fällen wird eine Software meistens eine Fehlermeldung ausgeben. Ganz selten – und hier war es der Fall – gibt es keine Fehlermeldung, und die Anwender merken zu spät, dass etwas schief gelaufen ist. Bei der europäischen Trägerrakete Ariane V wurde die Navigationssoftware der Vorgängerrakete Ariane IV angepasst. Dabei wurde eine Kleinigkeit übersehen, was zum Absturz der Rakete führte. In der Software eines Marslandungsgerätes wurde an einer Stelle metrische mit US- Masseinheiten verwechselt, was ebenfalls zum Verlust des Geräts und zum Abbruch der Mission führte.

Der Autor der HP-Fallstudie betont, dass das Risikomanagement in den meisten IT-Projekten Sache des Business und Auftraggebers sein müsse. Stattdessen wird das Risikomanagement einfach auf die IT abgewälzt: „Seht zu, dass Ihr keine Fehler macht!“. Wie wir gesehen haben, können unscheinbare Programmierfehler riesige kommerzielle Konsequenzen haben. Das ist eine Art Schmetterlingseffekt. Das Business schneidet sich also selber ins Fleisch, wenn es die Risikoverantwortung einfach an die IT delegiert.

Die Grafik zeigt die Situation als Systemarchetypus der Problemverschiebung. Es gibt grundsätzlich zwei „Lösungen“, eine symptomatische und eine fundamentale. In unserem Fall ist die symptomatische „Lösung“ die Delegation der Risikoverantwortung an die IT. Was kann sie tun? Sie schickt ihre Leute – Entwickler und Projektmanager – in die Ausbildung und delegiert ihre Verantwortung gerade noch einmal. Immerhin: wenn die Projektmanager ein Zertifikat als „Project Management Professional“ vorweisen können, dann muss doch einfach alles gut gehen….

Wie immer ist der Weg zu der fundamentalen Lösung steiniger und mühsamer, als derjenige zu der symptomatischen. Daher wird dieser bevorzugt. Mit der Delegation der Verantwortung an die IT, entmündigt sich der Auftraggeber selbst, denn je mehr die symptomatische Lösung präferenziert wird, desto unwahrscheinlicher wird es, dass der Auftraggeber die fundamentale Lösung überhaupt versucht. Der Pfeil, der von der „Qualität der Projektführung“ zum „Veranwortungsdruck auf das Business“ führt, verringert letzeren Parameter. Je besser und kompetenter die Projektführung, desto unnötiger erscheint es, dass sich das Business zusätzliche Gedanken zum Risikomanagement macht. Was kann denn bei zertifizierten Projektmanagern noch schief gehen?

Dennoch sollte die fundamentale Lösung begangen werden, nämlich dass der Auftraggeber das Risikomanagement übernimmt.  Wenn ich diese Aufgabe erhielte, würde ich sämtliche Bestellungen, die in das alte Order Entry System (ERP) hinein gegangen sind, in den Produktions- und Speditionsaufträgen suchen. Wenn ich keine eindeutige Zuordnung machen könnte, würde ich die Alarmglocken läuten (siehe die beiden Abbildungen in Man schlägt den Esel und meint den Sack).

Es ist nicht Sache der IT diese Kontrolle durchzuführen, es sei denn, sie erhält einen Auftrag zur Entwicklung einer Software, die Eingänge und Ausgänge vergleicht. Das wäre ein anderes Projekt als das ursprüngliche Migrationsprojekt, welches in seinem Budget solche Kontrollen nicht vorgesehen hat. Zudem muss damit gerechnet werden, dass auch die Vergleichssoftware fehlerbehaftet ist. Daher müssen zusätzliche (menschliche) Kontrolleure eingesetzt werden.

Doch welcher Manager wagte es, solche Entscheidungen zu treffen? Wie oft hört man: „Nur keine schlafenden Hunde wecken“, bis dann einer der Hunde eben doch zubeisst.

7 Schritte im intuitiven Umgang mit Komplexität

Dass Reduzieren und Vereinfachen keine angemessenen Methoden im Umgang mit Komplexität sind, ist mittlerweile ja wohl allenthalben akzeptiert (es gebe aber immer noch Bildungsinstitute, sogar in der Schweiz, die davon noch nichts gehört haben!). Dass die Art und Weise, wie unser Gehirn komplexe Situationen verarbeitet, „Intuition“ genannt wird, erstaunt offenbar immer noch einige Zeitgenossen. Dass aber Intuition Denken nicht ausschliesst, ist wohl noch weitgehend unbekannt. Zur Verwirrung tragen sicher auch Experten bei, die sagen: „Rationales Durchdringen ist keine gute Strategie im Umgang mit Komplexität. Die einzige Strategie, die wirklich greift, ist die Intuition“. Das ist zwar richtig, kann aber falsch verstanden werden. Intuition ist nicht nur auf die regelbasierte Ebene unseres Gehirns beschränkt. Man kann auch intuitiv denken! Peter Senge macht es uns vor1.

Projektleiter wollen nicht einfach schlafwandlerisch-intuitiv durch das komplexe Projekt hindurch stolpern, sondern verlangen nach systemischen Denkwerkzeugen, die die Intuition unterstützen. Das gibt es, nur sind sie schwierig anzuwenden. Wer glaubt, er könne einfach ein paar Zahlen in eine Vestermatrix pressen und bekäme auf bequeme Art – so quasi, ohne zu denken – eine Entscheidungshilfe oder, noch besser, eine Handlungsanweisung heraus, der sucht vergeblich nach Lösungen. Gefragt ist intuitives Denken!

Ich mache das jeweils so:

  1. Erfasse die Situation in einem Kawa oder Kaga von Birkenbihl2. Das ist eine ausgesprochen intuitionsunterstützende Massnahme. Manchmal muss man Schritt 2 vorher machen, manchmal unterstützt eine Kaga die Archetypenbildung.
    Kaga heisst übrigens „kreativ – Analograffiti – grafisch – assoziativ“. Kawa heisst dementsprechend „kreativ – Analograffiti – Wort – assoziativ“.
    Hier ein Beispiel aus einem Projekt, in welchem mir der Gegensatz zwischen immer grösser werdenden Verzögerung und schlechter (Produkte-)Qualität zu schaffen machte. Ein Kaga muss nicht immer derart figürlich sein. Das ist eine Charakterfrage des Zeichners. Ich würde auch lieber nichtfigürliche Grafiken machen. Das sähe „gescheiter“ aus. Aber immer kommen bei mir solche figürlichen Kagas heraus, weil es meiner Intuition entspricht.

    Klicke auf Grafik zum Vergrössern
    Klicke auf Grafik zum Vergrössern
  2. Formuliere die wesentlichen Charakteristiken des komplexen Systems als Senge Archetypen1. Die richtigen zu finden, geschieht intuitiv. Man darf aber nicht starr an Senges Darstellungen kleben, sondern muss seine Archetypen auf die eigene Situation anpassen. Auch das geschieht weitgehend intuitiv.Der Umgang mit den Archetypen will gelernt sein. Die Archetypen mögen mit einfachen Werkzeugen vergleichbar sein. Das richtige Führen eines Stechbeutels oder einer Feile bedarf aber einiger Stunden Trainings.
    Das Abbilden der aktuellen Situation in Archetypen ist eine schwierige und langwierige Angelegenheit. Sie erfordert viel Geduld. Wer meint, schnell, schnell einen Archetypen zu zeichnen und die Parameter zu benennen, der wird enttäuscht.
  3. Wende die „Seven Action Steps“ an, die Bob Braun zu jedem Archetypen entwickelt hat3. Sie sind leider nicht immer Eins-zu-Eins anwendbar, sondern müssen ebenfalls an die aktuelle Situation angepasst werden. Z.B. geht Braun davon aus, dass der Archetypus „Success to Successful“ auf einer Konkurrenzsituation zweier Individuen basiert. Häufig sind es aber zwei Handlungsalternativen, die gegenseitig im Widerstreit stehen (Dilemma). Die eine setzt sich dann plötzlich durch und bindet uns an eine Pfadabhängigkeit. Das muss in den betreffenden „Seven Action Steps“ berücksichtigt werden.
  4. Wenn ein Dilemma besteht, formuliere es als Dilemmawolke von Goldratt4. Gehe nach Goldratts Regeln zum Lösen von Dilemmawolken vor. Dazu müssen die Hypothesen formuliert und hinterfragt werden, die den Pfielen in der Wolke entsprechen. Die „Injections“, die zur Auflösung der Dilemmawolke führen, sind kreative Einfälle, die auf Intuition basieren. Sie kann gefödert werden, indem man den Archetypus aus Schritt 1 „anstarrt“ oder damit herum spielt.
  5. Versuche, die Hypothesen aus Schritt 3 mit den „fünf Warums“ von Rick Ross zu Fall zu bringen 5. Wenn die Hypothese allen fünf Warums standhält, ist das ein Indiz, dass die Hypothese „gut“ ist. Die Anführungszeichen weisen darauf hin, dass die Bewertung intuitiv ist.
  6. Intuitionscheck! Achte darauf, wie Du in Schritt 2 zum Archetypen gekommen bist, wie in Schritt 3 zu der Formulierung neuer „Seven Action Steps“, in Schritt 4 zu den Hypothesen und den „Injections“ und in Schritt 5 zu den Warum-Fragen. Hat irgendwo eine der folgenden Denkfallen ihr Unwesen getrieben?6:
    • Anchoring and Ajustment
    • Verfügbarkeitsheuristik
    • Repräsentativitätsheuristik
    • Frequency Gambling und Similarity Matching
    • Einkapselung
    • Thematisches Vagabundieren
    • Reduktive oder magische Hypothesenbildung und dogmatische Verschanzung
    • Übermässiges Vertrauen und Hang zur Bestätigung
    • Überbewertung des aktuellen Motivs
    • Horizontale oder vertikale Flucht

    Wenn ich mich ertappt habe, dann muss ich die Findings in den Schritten 2-4 korrigieren.

  7. Nachdem ich mich bis dahin „durchgekämpft“ habe, weiss ich sehr viel mehr über die komplexe Situation und würde sie als Senge-Archetypen vielleicht anders formulieren, als ich es am Anfang tat. Daher beginne ich gegebenenfalls wieder mit Schritt 1.

1Peter Senge. Die fünfte Disziplin. Die fünfte Disziplin. Kunst und Praxis der lernenden Organisation. Schäffer-Poeschel Verlag , März 2011
2 Vera F. Birkenbihl. Birkenbihls Denkwerkzeuge: gehirn-gerecht zu mehr Intelligenz und Kreativität. mcg Verlag, Heidelberg 2007
siehe z.B. Kaga zum Thema „Ideen auftauchen“
http://www.analograffiti.ch/index_102_50_kaga_vfb_01.html
3
William Braun. The System Archetypes. http://www.anchor.ch/archetypen.pdf
4
Paul Bayer, Problemdilemma, 2010. http://www.wandelweb.de/blog/?p=870
und Paul Bayer. Efrats Wolke. 2008. http://www.wandelweb.de/blog/?p=91
5
Rick Ross, Die fünf „Warums“ auf S. 125 in Peter Senge et al. Das Fieldbook zur fünften Disziplin. Klett-Cotta Verlag, Stuttgart 2000
und Bella Achmadulina. Fünf „Warums“ 2009. http://www.gedankenteich.de/2009/01/20/funf-warums/
6
Peter Addor. Projektdynamik – Komplexität im Alltag. Liebig Verlag. Frauenfeld 2010. http://www.anchor.ch/Projektdynamik