Komplexitätsmanagement in Projekten und Unternehmen

Rezension eines neuen Buches von Andreas Zeuch

Immer mehr Spatzen pfeifen es vom Dach: die herkömmlichen Vorstellungen und Ansichten unserer Entscheidungsträger in Wirtschaft und Politik bedürfen einer dringenden Revision. Andreas Zeuch räumt in seinem eben erschienenen Buch Feel it! Soviel Intuition verträgt Ihr Unternehmen ¹ mit so mancher unternehmerischen Lügengeschichte auf. Eine davon ist der Homo Oeconomicus, der rein rational agierende Mensch, der stets seinen Nutzen maximiert. Noch nie war ein Mensch in der Lage, seinen Nutzen zu optimieren. Das wäre ja noch schöner, wenn jeder optimieren könnte! Optimierungsaufgaben gehören in die Mathematik und bilden dort eine Klasse höchst reiz- und anspruchsvoller Problemstellungen. Entsprechend entwickelte sich eine Wirtschaftswissenschaft, die immer geschliffenere mathematische Modelle aufstellte und den Managern den Eindruck verlieh, ihr Tun sei wissenschaftlich fundiert. Auch diese Ansicht kritisiert Zeuch. Mehr noch: die wirtschaftsmathematischen Modelle sind oft linear, weil nicht-lineare Modelle für Oekonomen zu kompliziert wären. Zeuch macht jedoch darauf aufmerksam, dass Unternehmen und Märkte nicht über lineare Kausalitätsmodelle zu beschreiben sind, weil Komplexität immer nicht-linear ist.

Lügengeschichten
Eine weitere Lügengeschichte, die Zeuch entlarvt, ist die Vorstellung, Gefühle gehörten nicht in eine sachbezogen geführte Unternehmung. Ohne Gefühle würde jeder Laden schlicht stehen bleiben. Die Hirnforschung hat schon vor mehr als einem Dutzend Jahren gezeigt, dass die Wurzeln jeder Entscheidung und Handlung bis weit ins limbische System ragen, wo sich der Sitz der Gefühle befindet.
Wenn Manager glauben, sie müssten “auf der Suche nach Spitzenleistungen” eine Strategie eines Top-Unternehmens fahren, dann hängen sie einer veralteten Sichtweise an, die in der heutigen Zeit völlig überholt sein sollte. Langsam setzt sich die Erkenntnis durch, dass unsere Rationalität, ja unsere

Fähigkeiten schlechthin, sehr begrenzt sind. Eine Fähigkeit ist jedoch ein mächstiges Instrument, um unüberschaubare Situationen auf einen Schlag einzuschätzen und die richtige Entscheidung zu treffen: unsere Intuition. Sie hat es in einer rationalitäts- und realitätsgläubigen Gesellschaft schwer und wird oft zu Unrecht eher unterdrückt, denn als Chance gesehen. Darum geht es Andreas Zeuch vor allem.

Intuition
Er plädiert für professionalisierte Intuition und erklärt, in welchen Entscheidungssituationen Intuition hilfreich und effektiv ist. Intuition können sowohl Experten anwenden als auch Anfänger, die nicht erst mit 45 beginnen sollten, ihre Intuition ernst zu nehmen. Intuition kann in einfachen Situationen eingesetzt werden, als auch in komplexen, wenn Planung ohnehin nicht mehr möglich ist. Und last but not least ist Intuition immer dann wichtig, wenn wir etwas nicht wissen. Wo Daten fehlen, sind wir gezwungen, auf unsere Inuition zurück zu greifen. Nichtwissen entsteht aber nicht nur, wenn Daten fehlen. Nach Zeuch verhält sich Nichtwissen zu Wissen, wie Schatten zu Licht. Wissen schafft Nichtwissen, sagt er. Eigentlich stellte das schon Platon fest (ja Platon, nicht Sokrates), als er sagte: “Ich weiss, dass ich nichts weiss”. Platon wusste ganz bestimmt einiges, vielleicht das Meiste der damaligen griechischen Hochkultur. Gerade dadurch wurde er sich seines Nichtwissens bewusst. Zeuch unterscheidet fünft Situationen des Nichtwissens: Daten fehlen, Daten sind im Überfluss vorhanden, Daten sind nicht vertrauenswürdig, Daten sind unverständlich und Daten sind widersprüchlich.

Fehlerquellen
Zeuch warnt aber auch davor, dass uns Intuition in die Irre leiten kann. Das kann seine Ursache in Wahrnehmungsfehlern haben, aber auch in falsch verstandenem Expertentum. Experten sind nämlich ausgesprochen resistent gegenüber neuen Erkenntnissen und rümpfen möglicherweise nur die Nase, wenn ihnen die Intuition einmal einen Happen zuwirft.
Zeuch besteht denn auch darauf, intuitiv gefundene Lösungen rational zu hinterfragen. Er stellt schon in der Einführung fest, dass bei einer Aufgabe immer rationale und intuitive Prozesse ablaufen. Und der Prozess “intuitives Problemlösen”, der aus fünf Schritten besteht, endet mit der (rationalen) Überlegung: “Welche Auswirkungen hätte diese Lösung im relevanten Umfeld?”. Dieser Schritt liegt mir besonders am Herzen. Denn Improvisation in Ehren, aber die “probieren-wir’s-mal-aus-wird-schon-schiefgehen”-Kultur führt in unserer hochkomplexen Welt immer häufiger zu Katastrophen.

Voraussetzungen einer effektiven Entscheidungskultur
Im letzten Teil seines Buches beschreibt Andreas Zeuch fünf strategische Voraussetzungen einer effektiven Entscheidungskultur: Anfängergeist (hin zur offenen Expertise), Fehlerfreundlichkeit (um Katastrophen zu vermeiden), Möglichkeitsräume (das Gegenteil von Plaung und Steuerung), Selbstorganisation (ist da wohl eher Selbstverwaltung und Selbstmanagement gemeint?), Vertrauen (die Kraft der Kooperation).

Das Buch ist nicht immer sehr präzise. Vier Beispiele sollen das belegen:
1. Ich habe nirgends eine erschöpfende Definition des Begriffs “Intuition” gefunden. Es entstand bei mir der Eindruck, dass Zeuch den Begriff gerade so verwendet, wie er in den Kontext passt.
2. Der Begriff “Selbstorganisation” wird im Buch anstelle von Selbstmanagement, oder Selbstverwaltung, verwendet. Selbstorganisation ist dagegen ein systemtheoretisches Phänomen, wonach die Kooperation einer sehr grossen Anzahl von Systemteilen diese “versklavt”. Es entsteht eine emergente raum-zeitliche Struktur. Wahrscheinlich ist auch die Intuition selber ein Selbstorganisationsphänomen.
3. Im zweitletzten Kapitel stellt Zeuch Axelrods Experimente des Gefangenendilemmas vor, um zu zeigen, dass Vertrauen zu befruchtender Kooperation führt. Er schreibt, dass die nicht-kooperierenden Programme gegenüber dem freundlichen Siegerprogramm “Tit-for-Tat” ausgestorben seien. Das stimmt so nicht. Was Zeuch da beschreibt, ist eine kollektiv stabile Strategie. Axelrod hat nie gesagt, dass Tit-for-Tat kollektiv stabil ist, sondern acht Theoreme bewiesen. Theorem 2 lautet: “Tit-for-Tat ist genau dann kollektiv stabil, wenn der Diskontparameter einen gewissen (hohen) Wert annimmt”. Der Diskontparameter widerspiegelt die Wichtigkeit der Zukunft (oder Vergangenheit, je nach Sichtweise). Ein Fischer, der für jedes Kilo einen bestimmten Betrag erhält, fischt, was das Zeug hält, auch wenn er letzten Monat viel verdient hat. Das Geld ist aber mittlerweile ausgegeben und er hat jetzt Hunger. Mit anderen Worten, im Fischereikonflikt ist der Diskontparameter niedrig und daher kommt es dort nie zu einer Koopertation. Die Meere werden leergefischt.
4. Spams als unerwünschte Form von E-Mails werden als Kehrseite des World Wide Webs bezeichnet, obwohl E-Mail ja überhaupt nichts mit dem Web zu tun hat. Mail und Web sind zwei völlig getrennte Internetdienste.
Das sind aber Kleinigkeiten. Der Leser weiss intuitiv, was gemeint ist.

Empfehlung
Zeuchs Buchs enthält eine Fülle von lebendigen und anschaulichen Fallstudien, die als Beispiel dienen und das Lesen der knapp 260 Seiten kurzweilig machen. Viel Interessantes in Zeuchs Buch bleibt hier unangesprochen. Es ist ein vielseitiges und vielschichtiges Buch. Es ist auch ein notwendiges Buch, denn obwohl das Meiste seit Jahrzehnten oder gar Jahrtausenden (z.B. Nichtwissen) bekannt ist, braucht es noch viele solcher Bücher, damit unsere Entscheidungsträger - wichtiger: Bildungspolitiker, die für die Ausbildung von Entscheidungsträgern verantwortlich sind - endlich verstehen, worauf es in unserer immer komplexer werdenden Welt ankommt.

¹Zeuch, Andreas. Feel it! So viel Intuition verträgt Ihr Unternehmen. Wiley-VCH Verlag. Weinheim 2010.
ISBN 978-3-527-50467-1

Unter dem Titel Verhalten des Linienführungskräfte im Projektmanagement veröffentlichte Dr. Stefan Hagen in seinem pm-blog eine interessante Liste mit 10 häufigen Managementfehler¹. Der zweite und elfte Eintrag der Liste lautet

Die Projektteams werden direkt oder indirekt gezwungen, den Best-Case zu planen. Wenn dieser dann nicht eintritt, wird das Team oder der/die Leiter/in verantwortlich gemacht

Das ist leider nur allzu wahr. Allerdings handelt es sich um ein einfaches Gefangenendilemma, aus dem es noch immer kein Entkommen gibt. Wenn das Unternehmen das Projekt gewinnen will, muss es ein attraktives Angebot machen. Da man heute Attraktivität mit “billig” oder gar “gratis” verwechselt, erhält derjenige mit dem niedrigsten Preisangebot den Zuschlag. Daher bietet der Verkäufer das Projekt 10% unter dem Preis an, der der Projektleiter gerechnet hat, nachdem ihm der Verkäufer sagte, er soll nur den best-case rechnen.

Ein weiterer Eintrag der Liste heisst:

Unklare Aufträge, kaum klare Zielvorgaben

Das ist meines Erachtens kein Fehler. Ich nenne das unterspezifizierte Initialkonditionen². Stellen Sie sich vor, alle Wissensspeicher (Bücher, Web, etc.) sind auf einmal weg. Nur das Wissen in den Köpfen der Menschen existiert noch, und Sie hätten den Auftrag, innerhalb einer kurzen Zeit ein Lexikon zu schreiben. Sie müssen aufschreiben, was Ihnen in den Sinn kommt. Na, was glauben Sie, wie vollständig die erste Auflage Ihres Lexikons würde? Es ist äusserst schwierig, sich etwas aus den Fingern zu saugen, wo noch nichts da ist. Das Wissen, was man will, bildet sich erst im Verlauf des Projekts. Ein Projekt ist eine Wissensgenerierungsmaschine.

Folgendes ist ein Fehler, der schlicht auf Ignoranz beruht:

Die Ressourcen werden bewusst permanent überlastet

Manager meinen, sie müssten ihre Ressourcen immer zu 100% auslasten. Dabei wird aber das Unternehmen höchst ineffizient, wie schon Elyahu Goldratt bewies³. Stellen Sie sich vor, Sie hätte nur zwei Mitarbeiter. Der erste erledigt eine Arbeit in 5 Minuten, der zweite braucht zur Weiterverarbeitung 10 Minuten. Was glauben Sie, was passiert, wenn beide zu 100% ausgelastet werden? Das Unternehmen wird schnell seine Tore schliessen und die Bilanz deponieren. Natürlich darf in diesem Beispiel die erste Ressource stets nur zu 50% ausgelastet sein. Im Alltag, und vor allem wenn Wissen verarbeitet wird, ist die Sache natürlich nicht so eindeutig. Aber dennoch lässt sich mit ein wenig Nachdenken verstehen, dass Leute nicht zu 100% ausgelastet werden dürfen, wenn die Zusammenarbeit effizient sein soll.

Stefan Hagens Lösungsansätze können mit “aktive Managementawareness” zusammen gefasst werden.
Die besten Erfahrungen habe ich dort gemacht, wo periodisch unkomplizierte Steeringboards stattgefunden haben, die aus Mitgliedern des Top-Managements bestanden. Als Projektleiter konnte ich meine Sorgen auf den Tisch legen und direkt mit dem höchsten Chef besprechen. Dieses Vorgehen hat mindestens zwei Voraussetzungen:

1. Der Top-Manager muss die Projektleiter kennen und mit ihnen schon mal ein Bier getrunken haben.
2. Die Unternehmenskultur muss so sein, dass ich Probleme auch dann beklagen kann, wenn mein direkter Vorgesetzte anwesend ist

Die beiden Voraussetzungen sind leider ziemlich anspruchsvoll.

¹Hagen, S. Verhalten der Linienführungskräfte im Projektmanagement. pm-Blog, 29. April 2010.
http://pm-blog.com/2010/04/29/verhalten-der-linienfuhrungskrafte/

²Addor, P. Projektdynamik - Komplexität im Alltag. S. 151. Reinhold Liebig Verlag. Frauenfeld 2010

³Goldratt, E. & Cox, J. Das Ziel. Campus Verlag. Frankfurt a.M. 2008

Karl Heinz Däppler fragt, welche Rolle bei der projektübergreifenden Lessons Learned Wissenskultur die Thematik “Lean Managment” spiele. Komplexitätsmanagement fordert ein Management, das der (in den letzten Jahren in schwindelerregende Höhe gewachsenen) Komplexität angepasst ist und sich Strategien bedient, die es erlauben, die Entropie eines komplexen Systems in die Umgebung auszulagern. Die Entropie ist das Mass für die Unsicherheit, die komplexen Systemen inhärent ist. Projektübergreifendes Lessons Learned Wissensmanagement ist eine solche Strategie. Wenn Lean Management ebenfalls zum Entropieexport beitragen kann, dann könnte es eine wichtige Rolle spielen.

Der Begriff “Lean” könnte jedoch falsch verstanden werden. Ich habe hier immer wieder darauf hingewiesen, dass die Aufrechterhaltung der von uns geschaffenen Komplexität etwas kostet. Leider habe ich in keinem Budget je den Posten “Komplexitätskosten” gesehen. Ich denke daher, dass dieser Posten bei Lean Management erst recht unter den Tisch fällt. Da sich “Lean” die Vermeidung von Verschwendung auf die Fahne geschrieben hat, befürchte ich, dass dabei lokal optimiert wird. Wir haben aber sowohl beim Bierspiel als auch in der Theory of Constraints gesehen, dass lokales Optimieren dem System als Ganzens schadet. Am einfachsten ist das an einer Produktionslinie von z.B. drei Fertigungseinheiten zu verstehen. Um ein Erzeugnis herzustellen, benötige die erste fünf, die zweite 11 und die dritte sieben Zeiteinheiten. Die Produktionslinie stellt also alle 11 Zeiteinheiten ein Stück her, das verkauft werden kann. Es hat keinen Sinn, wenn die erste Fertigungseinheit mehr als ein Stück pro 11 Minuten herstellt, denn das würde zu teuren Beständen zwischen der ersten und der zweiten Fertigungseinheit führen. Wenn nun ein Lean Management Berater findet, es sei Verschwendung, wenn die erste Fertigungseinheit nur zu 5/11 oder 45% ausgelastet sei, dann ist Lean sicher nicht der richtige Weg. Wenn jedoch Lean Management bedeutet, dass die erste Fertigungseinheit genau ein Halbfabrikat bereit stellen soll, wenn die zweite Einheit bereit ist, eines zu verarbeiten, weil jede weitere Aktivität der ersten Einheit Verschwendung wäre, dann kann Lean Management ein interessanter Ansatz sein.

Der Begriff “Verschwendung” ist eben nicht eindeutig, und ich habe in den Artikeln über Lean Management eben sowenig eine exakte Definition gefunden, wie eine dezidierte Distanzierung von jeglichem lokalem Optimieren. Solange ich keinen derartigen Hinweis finde, muss ich jedoch befürchten, dass unter “lean” nichts anderes als “lokales Optimieren” gemeint ist.

Wenn wir Bedürfnisse als “inhaltliches Verständnis der Funktionen” begreifen, dann können wir in Migrations- und Integrationsprojekten einen kooperativen Prozess des Bewusstwerdens der Anforderungen beobachten, der drei Dimensionen hat:

• Inhaltsdimension: u(p_i,f_j) ist der Grad des inhaltlichen Verständnisses für die Funktion f_j bei dem Stakeholder p_i. u ist ein Skalarfeld.
• Dokumentationsdimension: d ist der Grad der Dokumentation aller Funktionen f_j, für die u(p,f_j)>0 für mindestens einen Stakeholder p.
• Dimension der Tests: C ist die Anzahl der Testfälle, die nicht erfolgreich durchgeführt werden konnten (”conditional passed” oder “failed”), also (Total durchgeführte Testfälle C_tot - erfolgreich durchgeführte Testfälle C_passed).

Ein Testfall ist ein Run eines Programmteils, welcher eine Funktion vermittelt. Im produktiven Betrieb sind Runs Endkunden- oder Operatorinterventionen. Ein Run kann mit einem Fehler terminieren. Je mehr Testfälle, desto höher der Grad inhaltlichen Verständnisses, aber desto höher die Zahl manifester Fehler.

Ein mögliches Modell dieser Zusammenhänge könnte so aussehen (klicken Sie zum Vergrössern auf die Grafik):

Schon 1993 identifizierte Klaus Pohl drei Dimensionen¹, das inhaltliche Verständnis der Funktionen, Grad der Dokumentation und der Grad der Ãœbereinstimmung aller am Prozess beteiligten Stakeholder. Diese Sicht kann aber zu Verwirrungen führen. Die inhaltliche Dimension hängt natürlich vom einzelnen Stakeholder und von der in Frage stehenden Funktion ab. Vielleicht könnte man über alle Stakeholder einen Durchschnitt bilden, aber mindestens betreffend der einzelnen Funktion ist die Inhaltsdimension zu indizieren. Wie wir in Bye, bye Requirements Engineering gesehen haben, sind uns die meisten Funktionen gar nicht bewusst, so dass ein inhaltliches Verständnis von Funktion zu Funktion sehr unterschiedlich aussehen mag. Für einige Funktionen wird es gar nie ein Verständnis geben und braucht es auch gar nicht zu geben. Dadurch fällt die Ãœbereinstimmung als Dimension weg, denn der Ãœbereinstimmungsgrad der Funktion j ist gegeben durch den Wert u(p,_j) über alle p.

¹Klaus Pohl: The Three Dimensions of Requirements Engineering. CASE 1993: 275-292

Der Anlass für ein neues System sind immer Wünsche und Bedürfnisse, die jemand hat. Man hat z.B. das Bedürfnis mit jemandem zu sprechen, wo immer man sich befindet. Also kauft man sich ein Mobiltelefon. Wenn man dieses eine Weile gebraucht hat wünscht man sich, man könne die am meisten gebrauchten Nummern speichern. Also kauft man sich ein Mobiltelefon mit Speicher. Nach einer Weile wünscht man sich, die Leute, die einem anrufen, könnten eine Nachricht hinterlassen, wenn man den Ruf nicht beantworten konnte. Also abonniert man eine Voice Mailbox. Dann sieht man jemand, der mit dem Mobiltelefon Musik hört oder ein Spiel macht. Also hat man plötzlich den Wunsch, ebenfalls mit dem Mobiltelefon Musik hören zu können, obwohl man von alleine gar nie auf diesen Wunsch gekommen wäre. Etc., etc.

• Bedürfnisse sind zunächst diffus und allgemein. Sie haben folgende Eigenschaften:
• Bedürfnisse können sich sowohl auf operative als auch auf strategische Funktionen beziehen
• Bedürfnisse können nicht scharf formuliert werden
• Bedürfnisse sind mehr Gefühl als Wissen und können daher nur eingeschränkt kommuniziert werden
• Man ist sich zu keinem Zeitpunkt allen Bedürfnissen bewusst
• Bedürfnisse entstehen während man sich mit dem System beschäftigt

Hat man sich lange genug mit dem System beschäftigt, dann werden einem die Bedürfnisse bewusst und man kann sie als Anforderungen formulieren. Dies geschieht aber meistens erst im Verlauf oder gar gegen Ende des Projekts. Anforderungen werden als Funktionen spezifiziert. Auch Eigenschaften eines Systems können als Funktionen formuliert werden. So sind z.B. die räumlichen Masse eines Autos eine Funktion, wenn es darum geht, das Auto in eine schmale Garage einzuparkieren.
Andreas Ninck et al. unterscheiden in Systemik - Vernetztes Denken in komplexen Situationen¹ funktionale von nicht funktionalen Zielen. Nicht funktionale Ziele sind nach Ninck z.B. Wartbarkeits- oder Erweiterbarkeitsanforderungen. Aber auch die Wartbarkeit kann man als Funktionen spezifizieren. Z.B. ist die Forderung nach einer Backup-Funktion eine Wartbarkeitsanforderung. Soll ein System ausbaufähig sein, dann muss es Funktionen geben, um zusätzliches Memory oder eine zweite CPU zu erkennen, etc. Ein systemtheoretisch zentrales Thema ist die Lebensfähigkeit eines Systems. Auch diese lässt sich über autopoietische Funktionen diskutieren. Stafford Beer meint, dass ein System sich an seine sich stetig verändernde Umgebung anpassen können muss, damit von Lebensfähigkeit gesprochen werden kann. Es muss seine Identität bewahren, Erfahrungen aufnehmen und verwerten können, und es muss lernen und sich weiterentwickeln können. Das sind alles Systemfunktionen. Beer definiert in seinem Viable Systems Model fünf Systemlevel. Das sind Funktionskomplexe des Unternehmenssystems². Man kann sich trefflich streiten, ob es nun noch etwas anderes gibt, als funktionale Ziele. Wir wollen zumindest in diesem Blog davon ausgehen, als seien alle Bedürfnisse und Ziele als Funktionen formulierbar.

Definitionen:

• Bedürfnisse, Wünsche: (erstes) vages Bild mit diffusen Strukturen
• Funktionen: möglichst klar strukturierte Bedürfnisse; möglicherweise können sich mehrere Funktionen überlappen
• Anforderungen: Katalog von priorisierten Funktionen (muss, wenn möglich, kann, nice to have, etc.)

¹Andreas Ninck, Leo Bürki, Roland Hungerbühler, Heinrich Mühlemann. Systemik - Vernetztes Denken in komplexen Situationen. Verlag Industrielle Organisation. Zürich 2004.

²Malik Management Zentrum. Das Modell Lebensfähiger Systeme (Stafford Beer). St. Gallen, 2006

Von Zeit zu Zeit erhalte ich per E-Mail ein “Projektmagazin” zugeschickt, das jeweils nur die ersten paar Zeilen seiner Artikel präsentiert. Wer mehr wissen will, muss den Artikel kaufen. Hohe Dynamik in Projekten - Wo Methodenwissen nicht mehr weiter hilft erregte meine Aufmerksamkeit, und ich habe mir den Artikel entgegen meinen Gepflogenheiten erworben¹. Endlich mal jemand, der den Methodismus im Projektmanagement hinterfragt. Der Autor spricht Projekte an, die einen hohen Anteil an Dynamik haben, und in denen daher immer wieder Überraschungen auftauchen. Methoden sind Regelwerke und deshalb nicht geeignet, mit Überraschungen umzugehen. Das einzig wirksame Mittel - so der Autor - seien Ideen. Nur der Erfolg im Markt entscheidet, ob aus einer guten Idee eine marktgängige Innovation wird. Offenbar adressiert auch dieser Artikel vor allem Entwicklungsprojekte, denn in Migrations- und Integrationsprojekten sind marktgängige Innovationen weniger zentral. Auch wenn er drei Möglichkeiten der Problemlösung in Unternehmen vorstellt, denkt der Autor dabei wohl kaum an Migrations- und Integrationsprojekte:

• Die Alltagsorganisation der Linie (das Management transfomiert das Problem in eine Anweisung)
• Das konventionelle, methodisch durchgeführte Projekt (das Management transfomiert das Problem in einen Projektauftrag)
• Das dynamikrobuste Projekt (Zerlegung des Problems in einen methodischen und einen dynamischen Teil)

Leider verschweigt der Autor, wer diese Zerlegung macht und behauptet ohne Quellenangabe, dass 95% methodische und 5% dynamische Anteile seien. Der einzige Lietraturhinweis ist ein Werk, das aus seiner eigenen Feder stammt. Schade, stellt er in seinem Artikel immer wieder unreferenzierte Behauptungen auf. So z.B. auch, nachdem er löblicherweise den Unterschied zwischen Aufgaben und Problemen erklärt und dann behauptet, Probleme seien äussere Reize, die ein Unternehmen nicht aussuchen könne. Bei niedriger Dynamik übersetze das Unternehmen Probleme in Aufgaben. Bei hoher Dynamik machen erfolgreiche Unternehmen Probleme sichtbar und suchen intern nach passenden Problemlösern. Ob er das eigenen Untersuchungen oder einem käuflichen Survey entnimmt, vernimmt der Leser nicht.

Das dynamikresistente Projekt steht im Zentrum seines Artikels. Ganz abgesehen davon, dass erfolgreiche Projekte hoffentlich nicht dynamikresistent sind, weil sonst kaum eine neue Struktur daraus erwächst, verstehe ich seine reduktionistische Aufteilung in 95% methodische und 5% dynamische Anteile nicht. In einer späteren Grafik über duale Prozessgestaltung scheint eher der dynamische Anteil 95% auszumachen. Niemand kann ein Problem ein für allemal in einen methodischen und einen dynamischen Teil aufsplitten. Während der methodischen Projektabwicklung entsteht laufend Dynamik. Eine neue Struktur, das Ziel eines jeden Projekts, kommt durch nichtlineare Dynamik zustande. Dynamik ist der wichtigste Bestandteil eines Projekts. Prigogine und Stengers schreiben: “Lange wurde Turbulenz mit Unordnung … gleichgesetzt. Heute wissen wir jedoch, dass das nicht der Fall ist”. So irregulär und chaotisch Turbulenz auch erscheinen mag, sie führt zu makroskopischen Strukturen². Ein Projekt ist gewissermassen die turbulente Phase, die es braucht, um eine komplexe Struktur aufzubauen.

Der Autor zählt eine Reihe von Fluchtverhalten auf - er nennt sie destruktiven Schutzräume -, die in überforderten Projekten beobachtet werden können. Neben Kommunikationsfehlern nennt er Konsequenzen des Reparaturdienstverhaltens, reduktiver Hypothesenbildung, horizontaler und vertikaler Flucht und Einkapselung sowie dem Parkinsonschen Gesetz, ohne sich jedoch an die in der Fehlerliteratur üblichen Terminologie zu halten³. Sehr gewöhnungsbedürftig ist die Art, wie Wohland die Begriffe Können und Wissen braucht. Er behauptet, dass Ideen nicht aus Wissen abgeleitet werden können. Ideenproduzenten seien Könner, weswegen der Bedarf an Können bei hoher Dynamik steige. Nach Rasmussen und Reason werden Probleme aber gerade auf der wissensbasierten Ebene gelöst, nicht durch Ideen, sondern durch Analyse der abstrakten Beziehungen zwischen Struktur und Funktion des Problemzustandes und durch anschliessende Diagnose³. Das Können läuft auf der fähigkeitsbasierten Ebene weitgehend automatisch ab. Damit kann man höchstens Routineprojekte abwickeln.

¹Gerhard Wohland. Hohe Dynamik in Projekten - Wo Methodenwissen nicht mehr weiter hilft. Projektmagazin 24/08. Das Fachmagazin im Internet.
²Ilya Prigogine, Ingrid Stengers. Dialog mit der Natur - Neue Wege wissenschaftlichen Denkens. Piper Verlag. München 1981
³James Reason. Menschliches Versagen. Spektrum Akademischer Verlag. Heidelberg 1994
sowie
Dietrich Dörner. Die Logik des Misslingens. Strategisches Denken in komplexen Situationen. Rowohlt Taschenbuchverlag. Reinbek b. Hamburg 1992 u. 2002

Der GDI-Trendradar vom 9. Dezember 2008 meldet unter dem Titel Hoffnung: Von schwarzen Schwänen zum leuchtenden Phönix, dass die Zukunft nicht den Untergangspropheten gehöre¹. Zwischen den Zeilen liest man, dass Nassim Taleb² Hysterie verbreite, anstatt neue Ideen für eine bessere Welt. Natürlich gibt es verschiedene Strategien gegen die Zunahme dessen, was man gemeinhin als Komplexität bezeichnet, also gegen Kontingenz, Fluktuation und Entropieproduktion. Man kann sie einfach schön reden, wie es das GDI vorschlägt. Man kann aber auch danach fragen, was denn eigentlich los ist und feststellen, dass wir verschiedene Handlungs- und Denkweisen aufgeben und uns neu orientieren müssen. Auch das ist eine neue Idee für eine bessere Welt. Aber Gewohnheiten aufzugeben und Neues zu lernen ist schmerzhaft und schwierig. Deshalb ist diese Idee vielleicht nicht so populär, wie es sich das GDI wünscht. Es gibt eben keinen Königsweg in eine bessere Welt. Da kann weder Nassim Taleb noch das GDI etwas dafür. Es ist höchste Zeit, dass wir untersuchen, wie sich die Welt in der menschlichen Wahrnehmung verändert hat, wie der Mensch die Unterschiede wahrnimmt, was diese Wahrnehmungen für ihn bedeuten und wie er darauf reagiert. Die Welt wird in unserer Wahrnehmung immer abstrakter. Für die wirklich wesentlichen Aspekte reicht unsere Wahrnehmung offenbar nicht mehr aus. Dies festzustellen ist höchst interessant und führt in keiner Weise zu einer Hysterie. In unserer Wahrnehmung machen wir Fehler, seit es uns gibt. Das ist nichts neues. Aber durch die Zunahme der Komplexität, die wir selber geschaffen haben, hat eben auch die Sensibilität gegenüber den Anfangsbedingungen zugenommen (sog. Schmetterlingseffekt). Daher haben Ungenauigkeiten oder Verzerrungen in unserer Wahrnehmung heute eine verhehrendere Auswirkung als früher. Auch schwarze Schwäne, die nur in unserer Wahrnehmung extrem unwahrscheinlich sind, haben verherendere Auswikungen auf unser komplexes Menschenwerk als früher, als das Menschenwerk noch ein stabiles und robustes Gebäude war. Die neuen Ideen für eine bessere Welt heissen deshalb:

• Verstehen, was wir für eine Welt geschaffen haben und was sie mit uns macht
• Verstehen, was Komplexität ist und wie wir sie wahrnehmen
• Lernen, systemisch zu denken, wahrzunehmen und zu handeln
• Lernen, welchen Einfluss unser Denken auf die Welt hat
• Alte Gewohnheiten zu überwinden und eine neue Sicht der Dinge zu übernehmen

Die alten Gewohnheiten sind insbesondere lineares Denken und ebensolches Handeln sowie die Missachtung von Fern- und Nebenwirkungen. Solange es Leute gibt, die unternehmerische Wissensgenerierung in starre Prozesse pressen wollen oder glauben, komplexe Projekte abschliessend planen zu können, sind allerdings nirgends leuchtende Phönixe zu sehen. Ich weiss nicht, warum das GDI schwarze Schwäne nicht mag. Schwarze Schwäne sind ebenso schön wie leuchtende Phönixe. Diese sind eitel und verblendet, während schwarze Schwäne elegant und anmutig daher fliegen.
Die Zukunft gehört weder den Untergangspropheten, noch den Schönrednern, die einen nichtvorhandenen leuchtenden Phönix beschwören. Die Zukunft gehört denjenigen, die uns den Weg aus dem linearem Denken zeigen.

¹GDI-Trendradar. Hoffnung: Von schwarzen Schwänen zum leuchtenden Phönix. persönlich 9.12.2008. Online Marketingnews der publiswiss.
²Nassim Nicholas Taleb. Der schwarze Schwan. Die Macht höchst unwahrscheinlicher Ereignisse. Carl Hanser Verlag, München 2008

Letzte Woche habe ich ein Seminar zum Thema “Systemisches Projektmanagement” erteilt. Das ist auch der Grund, weshalb dieser Blog (oder heisst’s das Blog?) eine relativ grosse Lücke erfahren hat. Das bedeutet aber nicht, dass keine Beiträge mehr folgen. Ich habe gerade heute mit meinen Studenten im Fach Mathematik festgestellt, dass auch die Primzahlen ausdünnen, je grösser sie werden und dennoch gibt es keine letzte, also grösste Primzahl. Genau so wenig wird dieses Blog versiegen…. (oder heisst’s der Blog?).
Im Seminar habe ich auch über Learning Stories doziert. Da ich das etwas impovisierte, habe ich keine Unterlagen. Das möchte ich hier nachholen.
Schwierige Projektsituationen zeichnen sich durch hohe Entropieproduktion aus. Die meisten Leute nennen das “Komplexität”. Aber Komplexität ist nicht durch Unsicherheit und Instabilität charakterisiert. Alle sind sich einig, dass das Gehirn wohl das komplexeste System auf der Erde ist. Trotzdem ist das Gehirn relativ stabil und durch grosse Strukturiertheit gekenntzeichnet. Was wir in chaotischen Projektsituationen erleben, ist nicht Komplexität, sondern etwas ganz anderes. Etwas, das auf dem Weg zur Komplexität auftritt. Man nennt es Entropieproduktion. Laufend tauchen Hiobsbotschaften auf. Kleinigkeiten und Details haben grösste Auswirkungen. Es spielt eine Rolle, ob Sie als Projektleiter präzis richtig oder annährend richtig reagieren, wenn man diese Unterscheidung überhaupt machen kann; letzteres kann zur Eskalation führen. Und dann machen Sie sich ein Gewissen, tagelang, wochenlang. Hätte ich doch nur eine Sekunde früher…. oder nicht mit dem rechten Auge gezwinkert, etc. Es ist, wie nach einem Autounfall. Er wäre vermeidbar gewesen, wenn Sie auch nur drei Minuten früher aufgestanden wären. Sie leiden unter jedem Ihrer “Fehler”. In der Therapie lässt man Patienten täglich 15 Minuten lang ihre Geschichten erzählen. Wenn Sie in schwieriger Umgebung arbeiten, wo der Zufall eine grosse Rolle spielt, dann werden Sie ständig das Gefühl haben, sich für Ihre früheren Entscheidungen rechtfertigen zu müssen. Ein Tagebuch zu führen ist das Mindeste, was Sie unter diesen Umständen tun können¹. Ein Tagebuch hat nicht nur einen mindernden Einfluss gegenüber Burnout-Effekten, sondern hilft auch bei Lessons Learned Workshops, sich nicht nur an die Ereignisse der letzten Wochen zu erinnern. Lessons Learned Workshops sollen das Projektgeschehen aufarbeiten. Lassen Sie alle Projektmitarbeiter die Ereignisse und den Ablauf aus ihren unterschiedlichen Perspektiven schildern, sowohl das Gute als auch das weniger Gute. Jeder sieht und interpretiert die Wirklichkeit ein wenig anders. Und was für den einen die hinreichende Ursache eines Unglücks, ist für den anderen bloss eine Notwendigkeit, die für sich genommen noch nicht zur Katastrophe hätte führen müssen. Lässt sich denn unter diesen Voraussetzungen überhaupt aus Fehlern lernen. Es gibt Leute, die bezweifeln das. Rückschaufehler führen zu einer übersteigerten Kontrollillusion. Vielleicht war es gar nicht so, wie Sie es wahrgenommen haben. Das Gehirn speichert Erinnerungen wie ein Palimpsest. Jedes Mal, wenn Sie eine Erinnerung abrufen, wird sie neu geschrieben, aber zusammen mit Interpretationen und Verzerrungen. Kausale Ketten werden z.B. umgedreht. Plötzlich geschah A in Ihrer Erinnerung nicht mehr wegen B, sondern B ereignete sich erst, nachdem A schon geschehen war. Wozu also Lessons Learned? Sie könnten uns helfen, unsere Verhaltensmuster zu verstehen. Sie könnten uns auch helfen, Komplexität und Entropieproduktion zu verstehen.
Protokollieren Sie die Geschichten Ihrer Projektmitarbeiter. Interessant sind vor allem die Geschichten ein und derselben Situation. Sammeln Sie solche Episoden. Bringen Sie Muster mit der Unternehmenskultur oder Persönlichkeitsstruktur in Zusammenhang. Verarbeiten Sie die prägnantesten Episoden in Metaphern, Gleichnissen oder gar Fabeln. Auf diese Weise abstrahieren Sie die Ereignisse von den Personen und Organisationen und bringen sie in eine merk-würdige Form. Mit der Zeit werden im Unetrnehmen geflügelte Worte und Geschichten die Runde machen und Wissen konservieren. Das ist Wissensmanagement. Wenn die Geschichten Emotionen wecken, bleiben sie besser im Gedächtnis haften; besser als Präsentationen nüchterner Fakten.

¹Nassim Nicholas Taleb. Der schwarze Schwan. Die Macht höchst unwahrscheinlicher Ereignisse. S. 100. Carl Hanser Verlag, München 2008.

Als Beispiel für eine Learning Story möchte ich das Problem eines kleinen, handlichen Projekts in eine Fabel fassen. Ich kann hier leider nicht näher auf die Projektumstände eingehen, weil es möglicherweise nicht im Sinne der Parteien sein könnte, wenn ich das noch nicht ganz beendete Projekt in die Öffentlichkeit trage. Das ist aber weiter auch nicht nötig, denn eine Learning Story soll ja eben eine Lehre enthalten, die immer wieder auf Projekte angewendet werden kann.

Als die aufsteigende Sonne einmal auf den Mond traf, der sich ebenfalls (noch) am Morgenhimmel tummelte, da dachte sie, wie angenehm es sein müsse, so cool und ruhig zu sein, wie es der Mond ist. Sie war ja ständig am brodeln und litt manchmal etwas unter ihrem inneren Feuer. Da begann sie, den Mond zu loben, wie schön sein Silberschein sei, und dass sie viel darum gäbe, wenn sie dieses Silber einmal für eine kurze Zeit ausprobieren dürfte. Der Mond war geschmeichelt und überlegte sich, dass vielleicht ein wenig vom Glanz und der Grösse der Sonne an ihn abfallen möge, wenn er der Sonne den Gefallen tut und ihr vorübergehend einen Teil seines Silberscheins gibt. Also beredete er mit der Sonne die Einzelheiten der Übergabe. Doch kaum war das bisschen kühlen Silberscheins, das der Mond abtreten konnte, auf der Sonne angekommen, verpuffte er und wurde von der Hitze und dem gleissenden Licht aufgezehrt. Die Sonne verlor nichts. Der Mond jedoch hat seinen noblen Silberschein eingebüsst und zeigt sich von da an mit vielen Flecken.

Wenn Du etwas a fonds perdu investierst in der Hoffnung, dass es Früchte tragen mag, dann solltest Du genau abklären, welche Möglichkeiten überhaupt bestehen (sollte eigentlich klar sein….). Nicht nur der Mond musste an der Abklärung interessiert sein. Die Sonne hätte sich ebenfalls fragen müssen, ob ihr Wunsch nach Kühle - auch nur probehalber - erfüllbar sein kann. Denn auch die Sonne hatte natürlich Aufwand. Und so schnell muss sie vom Mond nichts mehr erwarten. Zudem werden sich der törichte Wunsch der Sonne und die hochmütigen Gedanken des Mondes am Himmel schnell herum sprechen und nicht gerade zu ihrem Image beitragen.

Die Reduktion des Hauptproblems des Projekts auf das Allerwesentlichtste und das Finden einer passenden Geschichte, welche kurz und einprägsam das Problem chiffriert, sind zwei Schwierigkeiten, die nicht zu unterschätzen sind. Obwohl das Hauptproblem offenkundig war, war es noch lange nicht klar, welche Elemente wie in einer Geschichte abgebildet werden können. Z. B. lassen die Archetypen, aus denen Geschichten aufgebaut sind, kaum einen Zugang zum Begriff “Unternehmensstruktur”. Natürlich kann man mit König, Prinz, Grafen und Lakaien eine Hirarchie abbilden, aber dennoch lassen sich nicht alle Aspekte einer Unternehmensstruktur ausleuchten. Die Transformation “Projektgeschichten, wie sie die Projektmitarbeiter erzählen —> Integration —> Reduktion auf das Wesentliche —> Learning Story (Fabel, Metapher, Allegorie, Märchen, Witz)” erfordert Kreativität und Talent.

Wie kommt es, dass Sie beim Kaffeeautomaten dem Kollegen mühelos zuhören und ihn verstehen, wenn er von seinen Projekterlebnissen erzählt, dass Sie sich aber mühsam durch die nüchterne Sprache eines Protokolls und durch abstrakte Grafiken quälen, die von genau demselben Projekt handeln? Es kommt daher, dass der Kollege Ihnen eine Geschichte erzählt, in der er der Protagonist und manchmal auch der Held ist. Wenn seine Geschichte wirklich aus dem Projektleben gegriffen und authentisch ist, dann leben Sie mit und sind gierig darauf zu vernehmen, wie die Geschichte ausging. Der Vorteil von Geschichten liegt auf der Hand, wenn es darum geht, komplexe Botschaften zu vermitteln und nachhaltige Veränderungen anzustoßen. Geschichten füllen Fakten mit Leben und beantworten die Frage nach den Gründen. Geschichten helfen uns somit, Komplexität zu verstehen, weil sie unmittelbar anschaulich sind und eine eigene Ästhetik haben. Dadurch rufen sie in uns konkrete Vorstellungen hervor und sprechen nicht nur den Verstand an, sondern auch das Gefühl.
Gestern besuchte ich in München eine Einführung in Storytelling¹. Sigrid Hauser von Consulting4quality ist nicht eine Märchentante, sondern weiss, wovon sie spricht. Sie hat viel Erfahrung mit IT-Projekten und kennt sogar den Zusammenhang zwischen dem kartesischen Produkt zweier Mengen und relationalen Datenbanken, was mich als Mathematiker natürlich besonders freute. Sigrid Hauer zeigte auf, welche Kraft in Geschichten stecken und wie sie als Mittel zur Weitergabe von erfahrenem Wissen genutzt werden können. Natürlich sind die Projektgeschichten des Projektleiters und diejenige des Engineers subjektiv gefärbt. Der Projektleiter des Kunden wird auch kaum dieselbe Geschichte erzählen, wie der Projektleiter des Lieferanten. Aber gerade das macht die Methode wertvoll und griffig. Die verschiedenen Perspektiven werden integriert und ergeben damit eine ganzheitliche aber dennoch lebensnahe Sicht der Ereignisse.
Auf der Arbeit von George Roth zum Thema “Learning Histories”² basierend, habe ich für die Aufarbeitung von Projekterfahrungen folgende sechs Schritte entworfen:

• In Interviews lässt man alle Beteiligte des Projekts ihre ureigenste Geschichte erzählen, um so die verschiedenen Perspektiven zu erfassen.
• Die Interviewer dokumentieren die Geschichten und stellen verschiedene Perspektiven derselben Situation zusammen.
• Das Dokument wird unter den Teilnehmern verbreitet.
• In einem Workshop sucht man gemeinsam nach den archetypischen Handlungsmustern, den vorgeherrschten sozialen Dilemmata und den kognitiven Denkfallen und fragt sich, wann und bei welcher Gelegenheit Schwierigkeiten zum ersten Mal ihre Schatten voraus warfen.
• Die Teilnehmer verarbeiten die Erkenntnisse aus dem Workshop in Metaphern, Gleichnisse oder Fabeln
• An einem Verbreitungsworkshop erzählen die Projektmitarbeiter die neuen Geschichten, die nun die verschiedenen Perspektiven und die daraus gelernten Lektionen in unterhaltender und deshalb einprägsamer Weise integrieren

Die Vorträge können im Intranet in einer unternehmensinternen Clip-Datenbank zugänglich gemacht werden, ähnlich Youtube. Mit der Zeit werden im Unternehmen eine Menge geflügelte Worte und Geschichten kursieren, die das Wissen und die Projekterfahrungen nicht nur konservieren, sondern immer wieder weitertragen und verbreiten.
¹http://www.consulting4quality.de/seminare.htm
²Art Kleiner & George Roth. Field manual for a learning historian. MIT-COL and Reflection Learning Associates, Boston 1996.