Wir können Ungewissheit nicht einschätzen, Mr. Goldratt!

Goldratts Theory of Constraints ist durchaus faszinierend und vielversprechend. Aber sie ist halt eben eine regelbasierende Theorie, während es mein Credo ist, dass die heutige Komplexität wissensbasiertes Vorgehen erfordert (siehe Reasons Handlungs- und Denkmodell). Regelbasiertes Vorgehen genügt nicht mehr, um die Stabilität derart komplexer Systemen sicherzustellen, wie wir sie bis zum heutigen Tag in Gesellschaft, Wirtschaft und Politik geschaffen haben. Bei Goldratt ist alles sehr einfach und glatt. Zwar treffen seine Protagonisten zuweilen auch Widerwärtigkeiten an, aber nur, bis sie zu den Einsichten Goldratts gelangen. Dann geht alles wie durch Butter, sie erreichen die in sie gesteckten Ziele und werden auf den erträumten Posten befördert. Die Bücher hinterlassen keine offenen Fragen. Genau das ist es aber, was mir Unbehagen bereitet. Die Welt präsentiert sich uns ausschliesslich in Form offener Fragen. In einer neue Situations gibt es zu wenig Regeln. Wir müssen uns jedes Mal erneut auf die wissensbasierte Ebene begeben und die Situaion analysieren. Das ist zwar mühsam und aufwändig, stellt aber die einzige Möglichkeit dar, um die Komplexität zu bewältigen. Wenn immer Sie eine komplexe Situation ausschliesslich über Regeln lösen wollen, destabilisieren Sie das System noch mehr als vorher. Daher werden die wirtschaftlichen Instabilitäten, die wir seit 1929 in immer kürzeren Perioden durchleben, immer heftiger bis zum Kollaps.
Seine Kritische Kette1 beginnt Goldratt mit der Skizze einer Wahrscheinlichkeitsverteilung für die Durchführungsdauer eines Tasks. Der Tasks braucht meistens z.B. 5 Tage. Auch im günstigsten Fall wird man z.B. nicht vor 3 Tagen fertig. Goldratt zeichnet folgende Skizze:

Er behauptet dann, dass die meisten Projektplaner soviele Tage für den Task einstellen, dass sie mit 80-prozentiger Sicherheit fertig werden. In unserem Bild wären das also gute 17 Tage. Stattdessen sollte man für alle Tasks eines Projekts nur diejenige Zeit einplanen, in der man mit 50-prozentige Sicherheit ans Ziel kommt und dafür am Schluss des Projekts einen grosszügigen Puffer einräumen, den man ständig überwacht. Goldratt sagt, dass wir einen Task nicht innerhalb der 50%-Marke terminieren können, wenn etwas Unvorhergesehenes passiert. Dafür ist dann der Puffer da. Aber auf dem Gebiet der Migrations- und Integrationsprojekten kenne ich niemand, der alle siene Tasks mit einer hohen Sicherheit einplant. Ich meinte, alle Projektleiter, die ich kenne, haben die realen Zeiten genommen und am Schluss einen Sicherheitszuschlag von 10-20% eingerechnet (der ihnen vom Sales natürlich wieder abgezogen wurde). Aber was sind “reale Zeiten”? Woher sollen wir diese Zeiten kennen? Ein Projekt ist per Definition ein erst- und einmaliges Unterfangen. Also ist es gar nicht möglich, Erfahrungswerte zu haben – zumindest nicht immer. Und woher kennen wir die Wahrscheinlichkeitsverteilung eines Tasks? Sie könnte nämlich auch so aussehen:

Zwar kommen 5 Tage in der Tat am meisten vor, aber die Wahrscheinlichkeit, dass der Task erst nach 10 Tage fertig gestellt wird, ist unwesentlich kleiner, als diejenige für 5 Tage. Natürlich ist eine solche Verteilung ein Extremfall, aber sie kann durchaus vorkommen.
Meines Erachtens den interessantesten Satz in seinem Buch Die Kritische Kette liefert Goldratt fast am Schluss (S. 226): Was ist ein vernünftiger Massstab für die Ungewissheit eines Projekts? – Der Projektpuffer. Verstehen Sie, was das heisst? Den Projektpuffer haben wir ja aufgrund unserer Einschätzung dimensioniert. Und jetzt soll er also ein Mass für die Ungewissheit sein, die wir per Definition nicht einschätzen können, sonst wäre es keine Ungewissheit mehr. Da scheint sich irgendwer irgendwo zu beissen.
Bis jetzt kenne ich nur folgenden Projektverlauf: Projekt mit knappen Fertigstellungsterminen geplant – es taucht etwas Unvorhergesehenes auf – man aktiviert die wissenbasierte Ebene und analysiert die Situation – man konstruiert situationsgemässe Lösungen, wenn man kann – man überwindet die Hürde und setzt das Projekt fort, meist nicht mehr plangemäss, aber für die Neuerstellung eines Plans hat man keine Zeit mehr, so dass spätestens nach Auftreten einiger unvorhergesehener Ereignissen das Projekt nur noch “intuitiv” vorangetrieben wird.
1Eliyahu Goldratt. Die Kritische Kette – Das neue Konzept im Projektmanagement. Campus Verlag. Frankfurt a.M. 2002

Das Alte war gut. Die Entwickler des Neuen haben keine Ahnung!

In seinem Buch Die Kritische Kette sinniert Eliyahu Goldratt auf der Basis der Theory of Constraints über die Wahrscheinlichkeit nach, mit der ein Task, eine Phase oder ein ganzes Projekt nach einer bestimmten Zeit terminiert wird1. Er macht dabei den Vergleich zu dem Nachhauseweg nach der Arbeit. Unter 20 Minuten können Sie nicht zu hause sein. Meist sind es 30 Minuten. Wenn viel Verkehr ist, dann benötigen Sie sogar 40 Minuten. Und wenn Sie noch einen Kollegen treffen und mit ihm ein Bier trinken, sind Sie nicht vor 120 Minuten zu hause. Goldratt fragt dann, mit welcher Terminierungswahrscheinlichkeit wir planen sollen. Meines Erachtens ist das in Migrations- und Integrationsprojekten (MIP) die falsche Frage. Ganz abgesehen davon, dass Sie die Terminierungswahrscheinlichkeiten für einzelne Tasks und Phasen in MIP gar nicht kennen, werden typische MIP-Tasks nie fertig. Das kommt daher, dass z.B. bei einer Migration ein bestehendes System abgelöst werden soll und das neue System den Kunden vorerst niemals zufrieden stellen kann, weil es doch etwas anderes ist, als das ihm vertraute alte System. Stets vergleicht er das neue System mit dem abzulösenden, dem er tief in seinem Herzen eine Träne nachweint. Zudem kennt er das neue System noch nicht so gut und muss die Bedienung vieler Funktionen zuerst kennen lernen. Wer von uns kennt das nicht? Bis man mit einem Gerät wirklich vertraut ist und seine Stärken und Macken kennt, muss man es viele Male bedient haben, um nicht zu sagen, man müsse es in sein Leben integriert haben. Unsere Fernseher, Waschmaschinen, Autos, PCs oder Musikanlagen sind doch ein Teil unseres Lebens geworden. Wenn wir ein solches Teil jemals ersetzen müssen, finden wir eine Menge von Mängel am neuen Teil. Aber nach paar Wochen ist auch das neue Gerät ein Teil unseres Lebens geworden, und wir wissen schon gar nicht mehr, wie das alte bedient werden musste. Das Projekt “neues Gerät anschaffen und in Betrieb nehmen” ist beendet, wenn das neue Gerät angeschlossen und betriebsbereit ist. Genau in dieser Phase haben wir allerlei zu bemängeln und herum zu nörgeln. Ich nenne das das Umgewöhnungssyndrom. Leider können wir als kleine Endkunden dem Lieferanten das Gerät nicht um die Ohren schlagen. Wenn aber z.B. eine Bank von einem Systemhaus eine neue Bankenlösung kauft und für die Migration Dutzende, wenn nicht Hunderte von Millionen bezahlt, dann kann sie den Lieferanten solange festnageln, bis sie sich endlich an das neue System gewöhnt hat. Das verzögert das Projekt ungemein.

Sehr schön studieren kann man den eben beschriebenen Effekt bei Acceptance Tests, die ein wichtiger Teil von jedem MIP sind. Dazu wird ein Testdrehbuch benötig, das die durchzuführenden Tests enthält zusammen mit Angaben über Durchführungsdauer, Start- und Endzeitpunkt, Testverantwortliche, zu erwartende Resultate, etc. Sollen z.B. 100 Tests durchgeführt werden die je 15 Minuten dauern, dann wird die Projektplanung 25 Stunden vorsehen. Erfahrungsgemäss sieht die Planung und die dazugehörende Fortschrittskurve so aus:

 

Eine solche Planung passt eher in ein Straflager. Auch noch so arbeitsame Mitarbeiter gehen mal einen Kaffee holen oder müssen die Toilette besuchen. Ab und zu muss das Testdrehbuch diskutiert oder ein Bedienungsmanual konsultiert werden. Zudem kommen Telefone und die Mails müssen gecheckt werden. Die effektive Produktivität einer Ressource beträgt normalerweise zwischen 70 und 80 Prozent.
In den letzten paar Jahren habe ich die effektiven Testfortschritte aus mehreren Projekten ausgewertet und stets folgendes gefunden:

 

Am Anfang wird ein Initialaufwand dazu führen, dass die Ausführung der Tests der Planung etwas hinten her hinkt, weil der Projektleiter die Rüstzeiten vergessen hat. Diese sind aber schnell eingeholt, und weil alles so gut geht überholen die aktuellen Tests die Planung sogar. Das kommt daher, dass man zuerst die einfachen und unproblematischen Tests durchführt. Der Projektleiter muss bei jeder Steeringboard-Sitzung den Projektfortschritt vorweisen. Er wird quasi am Fortschritt gemessen. Daher wird er solange unproblematische Tasks oder Pfade bearbeiten, wie er kann. Goldratt schreibt: Weil ein Fortschritt auf einem Pfad eine Verzögerung auf einem anderen Pfad kompensiert. Also scheint ein rascher Fortschritt auf einem beliebigen [auch nicht-kritischen] Pfad angebracht2. Das schafft Vertrauen. Doch dann beginnt es zu harzen. Einige Tests müssen wiederholt werden. Schwererwiegende Probleme müssen sogar mit der Entwicklung besprochen werden. Es gibt Fälle, in denen das Verhalten des Systems zunächst unerklärlich ist und analysiert werden muss. Das kostet viel Zeit, die nie mehr eingeholt werden kann. Und schliesslich wird der Kunde genau in diesem Zeitpunkt, in welchem die Fortschrittskurve abflacht, vom Umgewöhnungssyndrom erfasst. Das neue System passt ihm (noch) nicht so recht, weil er es noch nicht kennt. Er möchte, dass es wie das alte funktioniert und wird viele Einwände, Wünsche oder zumindest Fragen haben. Er wird verlangen, dass Testfälle ein wenig verändert und wiederholt werden. Das Problem ist also weniger die Terminierungswahrscheinlichkeit, die die Theory of Constraints untersucht, noch der Rework Cycle, wie er von System Dynamics vorausgesagt wird. Das Problem in Migrations- und Integrationsprojekten ist das Umgewöhnungssyndrom. Daher werden die Acceptance Tests nie fertig. Man muss sie irgend einmal einfach “gewaltsam” als abgeschlossen erklären. Ganz ähnlich verhält es sich mit ganzen Migrations- und Integrationsprojekten. Auch diese werden nie so richtig fertig.

1Eliyahu Goldratt. Die Kritische Kette – Das neue Konzept im Projektmanagement. Campus Verlag. Frankfurt a.M. 2002.
2 ebenda, S. 80.

Wo ist denn nun die Katze hingekommen?

In Wie man Kosten, Zeit und Ärger spart habe ich einige typische Denk- und Handlungsfallen aufgezählt, wie sie im Unternehmens- und Projektmanagement häufig auftauchen. Einer nennt sich Rückschaufehler und führt schnell zu der Illusion, die Kontrolle über das Geschehen zu besitzen. Wenn wir nach gehabtem Schaden die Ereignisse Revue passieren lassen, dann haben wir oft das Gefühl, dass “es uns wie Schuppen von den Augen fällt” und es eigentlich ganz einfach gewesen wäre, hätten wir nur dann und dann auf das und das Signal geachtet. Erfahrene Regeln verallgemeinern wir gerne und erzeugen so eine Kontrollillusion. Aber wenn wir uns mitten im Schlamassel befinden, dann ist nichts einfach oder klar. Alles stürtzt auf uns ein und wir wissen nicht, worauf achten und wo wehren.

Der Artikel Hinten und Vorne nicht drauskommen… der Mathematikpädagogin und -therapeutin, Margret Schmassmann enthält eine einfache Geschichte, die zeigt, was ein Rückschaufehler ist. Erfahren hat ihn ein fünfjähriger Stefan, über den wir uns hier amüsieren können, weil wir seine Unbeholfenheit als “süss” empfinden. Schmassmann schreibt: Stefan zog sein Lieblings-T-Shirt an, das mit der Katze vorne drauf und stellt sich erwartungsvoll vor den Spiegel. Aber die Katze ist nirgends zu sehen….Er dreht und wendet sich …. und entdeckt [die Katze] plötzlich [am Rücken]. Da er sie ja vorne haben will, zieht er … das Leibchen wieder aus, legt es mit dem Katzenbild nach oben vor sich auf den Boden und schlüpft hinein. Aber die Katze ist wieder nicht da… Er geht nun systematisch vor: Er zieht das Leichen aus, hält es … an seinen Oberkörper, legt es dann umständlich und sorgfältig auf den Boden und schlüpft schnell hinein…. Der Aufwand hat sich gelohnt…. Er hat sich ein Stück Raum-Vorstellung erarbeitet und erwartet, dass sich diese nun bei ähnlicher Gelegenheit anwenden lässt…. Diese Angelegenheit kam gleich darauf in Form einer Strumpfhose, bei der es sehr störend im Schuh ist, wenn die Fersen, statt hinten an ihrem Platz zu sein, verwurstelt vorne in Falten liegen und drücken. Er legt also die Strumpfhose so vor sich auf den Boden, dass die Rückseite sichtbar ist und die Öffnung zu ihm zeigt. Er schlüpft hinein. Die Verwirrung ist gross! Denn was für’s T-Shirt galt, gilt für die Strupfhose nicht mehr.

Da können wir schmunzeln. Klar ist es nicht dasselbe, schliesslich schlüpft man von unten in’s T-Shirt, in die Strupfhose aber von oben. Was man mit fünf doch nicht alles lernen muss! Dabei hat Stefan bloss eine “best practice” angewendet, wie wir das auch oft tun. Sind wir zuweilen nicht gleich “süss” wie Stefan, wenn wir in einer viel komplexeren Situation Tatsachen antreffen, die für uns genau so verwirrend sind, wie die Raumvorstellung für Stefan? Im Nachhinein sind wir immer klüger und erleichtert, dass wir beim nächsten Mal wissen, wie wir vorzugehen haben. Aber das ist eine Illusion. Beim nächsten Mal erkennen wir nicht einmal, dass sich die Regel hier nicht anwenden lässt, weil es sich um eine andere Situation handelt und handeln völlig unbeholfen. Schmassmann schreibt, dass viele Dinge nicht gelernt, sondern erfahren werden. In den meisten Situationen, die der Mensch in den letzten paar Millionen Jahren angetroffen hat, hat er durch Erfahrung gelernt. Wir haben uns durch Erfahrung Regeln zurecht gelegt und sie im Langzeitgedächtnis gespeichert. Befinden wir uns auf der regelbasierenden Ebene, können wir auf die Regeln zurück greifen. Aber für die heutigen komplexen Situationen funktioniert das nicht mehr auf diese Weise. Um diese zu meistern ist es unumgänglich auf die wissensbasierte Ebene zu gehen, die Situation zu analysieren und Lösungen neu zu erfinden, ohne im Langzeitgedächtnis zu kramen. Natürlich kann die neue Lösung Komponenten gespeicherten Wissens enthalten, ist aber niemals vorgefertigt. Weil wir immer wieder versuchen, “best practices” anzuwenden, die in der Vergangenheit erfolgreich waren, nehmen Denklücken und mit ihnen auch Zusammenbrüche und Misserfolge in Projekten zu.

Erfahrungen, die wir in komplexen Situationen gemacht haben, müssen zuerst aufbereitet werden, bevor wir sagen können, dass wir sie gelernt haben. Die Aufbereitung ist wissensbasiert und bewusst und kann mit Hilfe von Modellen geschehen, wie z.B. Senges Archetypen1.

1z.B. William Braun. The System Archetypes. 2002

Wie man Kosten, Zeit und Ärger spart

Als ich kürzlich mit meinen Studenten das Handlungsmodell von J. Reason (Was kann in Projekten und Unternehmen alles schief gehen) anschaute und darauf hinwies, wie wichtig es sei, sich über die eigenen Entscheidungen und Beurteilungen klar zu werden, da erzählte mir einer der Studenten, dass ein Freund von ihm angehalten sei, sich alle zwei Wochen eine Viertelstunde Zeit zu nehmen und seinem Vorgesetzen ein kurzes Statusmail zu senden. Ich lobte zwar dieses Vorgehen als grundsätzlich richtig, betonte aber, dass eine Viertelstunde pro zwei Wochen ganz bestimmt dieselbe Wirkung habe, wie die kühlende Wirkung eines Tropfen kalten Wassers auf ein glühendes Stück Stahl. In einem komplexen Projekt ist es ausserordentlich wichtig, dass sich der Projektleiter mindestens einen halben Tag pro Woche – das sind 3-4 Stunden – Zeit nimmt, um über die aktuell ablaufenden Prozesse nachzudenken. Er muss sich folgende Fragen überlegen:

  • Wer erwartet was warum?
  • Welche Interessen stecken hinter diesen Erwartungen?
  • Was gibt es für Koalitionen mit welchen Handlungsalternativen?
  • Wie schätzt er selber die Lage ein?
  • Welche Entscheidungen trifft er?

Dann muss er die Liste der typischen fähigkeits-, regel- und wissensbasierten Fehler durchgehen und sich fragen, ob er gerade im Begriff ist, einem dieser Fehler zu erliegen. Die Liste enthält zwar wohl um 100 Einträge – das schafft er in vier Stunden nicht – aber die wichtigsten sollte er schon anschauen. Für meine Studenten habe ich die Liste wie folgt gekürzt:

Skillbased:
Unaufmerksamkeit:

  • Interferenzfehler (stärkstes Schema)
  • Versäumnisse nach Unterbrechungen
  • Wahrnehmungsverwirrung

Überaufmerksamkeit:

  • Unpassende Kontrollen
  • Versäumnis
  • Wiederholung

Rulebased:
Fehlanwendung nützlicher Regeln:

  • Rigidität
  • Informationsüberlastung
  • Stärke der Regel

Anwendung schlechter Regeln:

  • Enkodierdefizite
  • falsche, schwerfällige oder nicht empfehlenswerte Regel, z.B.
    – Reparaturdienstverhalten
    – Thematisches Vagabundieren
    – Reduktive Hypothesenbildung
    – Vertikale Flucht, Einkapselung

Knowledgebased:

  • Beschränkung des Workspace
  • Hang zur Bestätigung
  • Übermässiges Vertrauen
  • Rückschaufehler, Kontrollillusion
  • Überbewertung des aktuellen Motivs
  • Verzerrte Überprüfung
  • Halo-Effekt
  • Unterspezifizierte Initialkonstitution
  • Probleme mit der Kausalität
    – Laundry List Thinking
    – Nichtbeachten von Rückkopplungsrichtungen
    – Unterschätzen von Neben- und Fernwirkungen
    – Representativitätsheuristik („Ähnliches verursacht ähnliches“)
  • Probleme mit der Komplexität
    – Reduktion der Komplexität
    – Unterschätzen von Kontingenzen
    – Schwierigkeiten mit Zeitstrukturen und Verzögerungen
    – Unzureichende Berücksichtigung nichtlinearer Zeitverläufe
    – Verwechslung von Fluss- und Bestandesgrössen
    – Verwechseln von Hebeln und Resultaten

Natürlich ist es wichtig, dass man diese Fehler kennt und weiss, was sich dahinter versteckt. Um z.B. die Begriffe „Interferenzfehler“ oder „Unpassende Kontrollen“ der fähigkeitsbasierten Ebene zu verstehen, muss man Reasons Modell und die Definition dieser Fehler kennen. Die meisten der hier aufgeführten Fehler, habe ich in meinem Blog bereits erklärt. Beim Durchgehen der Liste und Versuch herauszufinden, ob man im Begriff steht, einem dieser Fehler zu erliegen, muss der Projektmanager natürlich unbedingt ehrlich sein. Die spezifischen Projektsituationen stellt der Projektleiter am besten mit Hilfe der Sengearchetypen dar1.

Es ist unabdingbar, dass die vier Stunden Reflexion in Abgeschiedenheit durchgeführt werden und sich der Projektleiter nicht ständig durch Telefonate, E-Mails oder Besuche stören lässt. Auf der knowledgebasierten Ebene ist es schwierig, Fehler selber zu entdecken. Es rentiert sich auf alle Fälle, eine Drittperson als Coach beizuziehen. Die Drittperson sollte allerdings mit Reasons und Dörners Fehlertaxonomien2 vertraut sein. Die Probleme mit der Kausalität und der Komplexität sind z.T. ziemlich formale Themen. Je besser der Projektmanager über die nötigen systemtheoretischen Kenntnisse verfügt und in systemischem Denken geschult ist, desto mehr holt er aus der wöchentlichen Reflexionsübung heraus.

In diesem Zusammenhang muss auf einen kardinalen Metafehler aufmerksam gemacht werden: Wenn der Projektleiter die wöchentliche Retraite nicht zum Heiligtum erklärt, wird er sowohl durch externe als auch durch interne Kräfte daran gehindert werden. Auf der einen Seite werden Ereignisse im Projekt just dann des Projektleiters Eingreifen erfordern, wenn er auf Reflexionstour ist. Auf der anderen Seite wird sich sein Gehirn wehren, nach Fehlern zu suchen, die es verursacht haben soll. Schon aus diesen Gründen kann die periodische Reflexionspause wohl nur mit Hilfe einer Drittperson durchgehalten werden.

1Peter Senge. Die fünfte Disziplin. Klett-Cotta Verlag. Stuttgart 1997
2James Reason. Human Error. Cambridge University Press, 1990
James Reason. Menschliches Versagen – Psychologische Risikofaktoren und moderne Technologien. S. 97. Spektrum Akademischer Verlag. Heidelberg 1994
Dietrich Dörner. Die Logik des Misslingens. Strategisches Denken in komplexen Situationen. Rowohlt Taschenbuchverlag. Reinbek b. Hamburg 1992 u. 2002

Die törichte Sonne und der hochmütige Mond

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.