Archiv der Kategorie: Denkmuster

Wie überlisten Sie Ihr Gehirn?

Vorgestern landete in einem Projekt ein schwarzer Schwan zu meinen Füssen1. Zwar wurde er schon seit längerer Zeit immer wieder in der Gegend gesichtet, wie das bei schwarzen Schwänen so der Fall ist. Aber dass er gerade zu diesem Zeitpunkt und ausgerechnet vor meinen Füssen landet, war dann doch überraschend.

Wahrnehmungsverzögerungen

In vielen Fällen wird der schwarze Schwan von Leuten angelockt, die noch immer in linearen Denkmustern verhaftet sind2 und lokal optimieren3, und sie sind leider immer noch in der Mehrheit. Sogar, wenn Sie auf den schwarzen Schwan aufmerksam machen, der über dem Schauplatz kreist, man wird Ihnen kein Gehör schenken, weil man Sie nicht verstehen kann. In meinem Fall ging es unter vielem Anderem z.B. auch um das Verständnis von Verzögerungen. Man muss die Dynamik einer Veränderungsabsicht abschätzen, die auf ein jährlich stattfindendes Ereignis abzielt. Die Absicht ist eine Funktion der Wahrnehmung und verzögert sich ihrerseits gegenüber der Wahrnehmung. Somit verhält sich die Absicht ähnlich, wie eine Verzögerung höherer Ordnung. Das Ereignis findet nur einmal pro Jahr statt, also muss mit einem entsprechend langen Zeithorizont gerechnet werden, um das Ziel zu erreichen. Das war noch das Einfachste, und es dünkt einem, dass es eine Kinderrechnung ist. Dennoch hat die Rechnung trotz mehrmaligem Hinweisen niemand im Team gemacht. Ich glaube nicht, dass das daher kommt, dass unsere Zeit schnelllebig ist, sondern daher, dass Menschen mit Zeitstrukturen ihre liebe Mühe haben.

Verfügbarkeitsheuristik – oder wenn nur das Heute wichtig ist

Der schwarze Schwan habe ich mitverantwortet, da es mir nicht gelungen ist, den Mitgliedern des Teams die Zusammenhänge nahe genug zu bringen. Aber sollen und können Sie die Mitglieder in einem Projekt laufend in systemischem Denken ausbilden?
Zudem muss ich mir den Vorwurf machen, dass ich wider besseren Wissens zu wenig Gedanken gemacht habe, wo der seit längerem gesichtete schwarze Schwan landen könnte. Mit anderen Worten: zwar habe ich viel Inhaltliches geleistet, aber gegenüber der instabilen Situation den Kopf in den Sand gesteckt. Ich hatte kein Modell, keine Risikolandkarte, keine Analyse der archetypischen Denkmuster, die in jedem Zeitpunkt vorherrschten. Zwar versuchte ich mir im Vorfeld des vorgestrigen Ereignisses vorzustellen, wie sich die Situation entwickeln könnte, aber irgendwie verschleierte mein Gehirn den Weg zu den richtigen Gedanken. Das mag mit der Verfügbarkeitsheuristik zusammen zu hängen5. Es kommen einem die Szenarien in den Sinn, wie man sie in letzter Zeit erlebt hat, nicht aber eines, in welchem der schwarze Schwan zuschlägt. Weil man intuitiv weiss, dass das Gehirn just in dem Moment streikt, wo man sich ein Katastrophenszenario vorzustellen versucht, lässt man es bleiben, bzw. verschiebt es auf „morgen“. Ich glaube aber, dass man mit mehreren Anläufen diese Blockaden beseitigen könnte.

Rückschaufehler: das hätte ich vorher sehen können!

Nachdem die Katastrophe eingetroffen ist, greift sofort der Rückschaufehler(s. Selbstverständlichkeiten müssen doch nicht gefordert werden, oder?). Es ist Ihnen ganz klar, was abgegangen und vorgefallen ist. Ebenfalls klar ist es Ihnen, dass die Entwicklung ja ganz logisch, ja zwingend war und Sie es eigentlich haben sehen kommen. Ich bin überzeugt, dass man etwas gegen den Rückschaufehler unternehmen kann und glaube nicht, dass wir immer und hoffnungslos den schwarzen Schwänen ausgeliefert sind. In einem Projekt fühlen Sie sich vielleicht schon seit längerer Zeit unbequem, weil nicht alles so läuft, wie Sie es sich wünschen. Als CEO einer Unternehmung merken Sie, dass Ihnen die Entwicklung langsam entgleitet. Dann müssen Sie sich hinsetzen und – unter Umständen mit einem Dritten – über die Ursachen Ihrer Bedenken, die Dynamik und Konsequenzen gewisser Entwicklungen sowie über Denkmuster, die in Ihren Kopf und dem der Teammitglieder auftreten, nachdenken. Tun Sie das nicht erst, wenn der schwarze Schwan schon zum Landeanflug ansetzt. Dann bringt Ihr Gehirn erst recht nichts mehr hervor. Denken Sie nicht, dass Sie sich morgen ganz bestimmt darum kümmern werden. Wenn Sie es heute nicht tun, dann werden Sie es auch morgen nicht tun. Versuchen Sie auch nicht mit der Entschuldigung auszuweichen, dass diese „Baustelle“ ja gar nicht so wichtig sei und Sie eigentlich viel wichtigere „Baustellen“ haben, die aber nicht so instabil sind, dass sie eine Denkpause erfordern.

Stellen Sie laufend Fragen

Womit beschäftigen Sie sich in dieser Zeit, beruflich und privat? Auf dieser Liste wird gewiss auch eine Ihnen nahestehende Bezugsperson auftauchen, mit der Sie sich beschäftigen müssen. Die Beschäftigung mit dieser Person hat ein Umfeld und eine Geschichte. Wissen Sie, wie sich diese Geschichte entwickelt hat, entwickeln kann und entwickeln wird? Welche Parameter können sich ändern? Wovon hängt ihre Änderung ab? Sind es Fluss-, Bestandes- oder Hilfsgrössen? Wie reagieren Sie und wie reagiert die Bezugsperson, wenn sich die Parameter ändern? Wie können Sie und Ihre Bezugsperson die Änderungen wahrnehmen und wie interpretieren Sie sie? Stellen Sie sich diese Fragen für jedes Ihrer Betätigungsfelder. Tun Sie es jetzt und immer wieder.

1Nassim Nicholas Taleb. Der Schwarze Schwan – Die Macht höchst unwahrscheinlicher Ereignisse. Carl Hanser Verlag. München 2008.
2Günther Ossimitz/Christian Lapp. Das Metanoia Prinzip – Eine Einführung in systemgerechtes Denken und Handeln. Franzbecker Verlag. Hildesheim und Berlin 2006.
3Eliyahu Goldratt/Jeff Cox. Das Ziel – Höchstleistungen in der Fertigung. McGraw-Hill Book Company. Maidenhead 1990
4John Sterman. Business Dynamics – System Thinking and Modeling for a Complex World. McGraw-Hill. Boston 2000
5Hanno Beck. Die Logik des Irrtums – Wie uns das Gehirn täglich ein Schnippchen schlägt. Verlag Neue Zürcher Zeitung. Zürich 2008

Lesssons Learned und Tagebücher gegen Schwarze Schwäne

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önnen1. 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.

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

Die zwei Arten schwarzer Projektschwäne

Nassim Nicholas Taleb spricht von Schwarzen Schwänen1, wenn etwas Unvorhergesehenes passiert und zeigt auf, dass das viel häufiger vorkommt, als wir denken. Allerdings blenden wir diese Tatsache gerne aus. Das hat mit bekannten wissensbasierten Fehlern unseres Denkapparats zu tun – Selektivität, Hang zur Bestätigung und übermässiges Vertrauen –, die Taleb offen legt. In Migrations- und Integrationsprojekten verhindern schwarze Schwäne regelmässig ein planmässiges Vorgehen. Natürlich legt jeder Projektleiter zu Beginn des Projekts einen Plan vor, auf Grund dessen die Manager dann berechnen, was das Projekt kosten wird und ein entsprechendes Budget sprechen. Die Tatsache, dass wahrscheinlich weniger als 10% aller Migrations- und Integrationsprojekten planmässig abgeschlossen werden können (leider gibt es von der Standish Group für diese Projektsparte keine zuverlässigen Zahlen) zeigt, dass schwarze Schwäne gerade in Projekten sehr häufig sind. Wenn ich hier an das Operhaus von Sydney erinnere, dann werden die meisten Leser ausrufen: „Ja gut, das ist jetzt gerade ein sehr ausgefallenes Beispiel“ (geplant: 6 Jahre, 7 Mio, gehabt: 14 Jahre, 100 Mio), und diese Reaktion zeigt, dass unsere Wahrnehmung und unser Denken solche Ereignisse als „ausgefallen“ abstempelt und isoliert. Das Beispiel ist aber höchstens im Hinblick auf den Umfang des Schadens ausgefallen, aber dennoch typisch für Projekte. Jedes Projekt hat mindestens einen schwarzen Schwan. Wir müssen jedoch zwei verschiedene Unterarten schwarzer Schwäne unterscheiden. Die eine sind Emergenzen – Konrad Lorenz sprach von Fulgurationen (fulgur: Blitz). In Projekten könnte man auch von Katastrophen sprechen. Das sind plötzlich auftretende und unvorhergesehene Ereignisse, die das Projekt in Frage stellen. In einem Projekt mussten wir ein Telekommunikationssystem migrieren. Eines schönen Sonntags rief mich der Kunde an und informierte mich, dass das neue System gehackt wurde. Nicht nur warf uns dieses Ereignis im Projektplan beträchtlich zurück, es wurde auch in der Presse breit geschlagen, was einen Imageverlust für Kunde und Lieferant bedeutete. Das war ganz klar ein schwarzer Schwan der Unterart „Katastrophe“. Fast mehr zu schaffen gibt die Unterart „Feststecken“, man denke an den buchstäblichen Granit beim Tunnelbau. Während die Unterart „Katastrophen“ nicht antizipiert werden kann, tauchen schwarze Schwäne der Unterart „Feststecken“ zuweilen in Risikoanalysen auf. Z. B. verhielt sich das oben erwähnte Telekommunikationssystem in der neuen Umgebung nicht, wie erwartet und niemand war in der Lage zu erklären, wo der Hund begraben ist. In dieser Situation gibt es nur die Hoffnung, durch minutiöses Erforschen, Testen und Reproduzieren der Sache auf die Spur zu kommen. Wie lange das aber dauert, kann niemand sagen. In der zu Beginn des Projekts durchgeführten Risikoanalyse steht als mögliche Massnahme, die in diesem Fall ergriffen werden: „Zusätzliche Ressourcen und Testmittel einbeziehen, direkte Involvierung der Entwicklung“, als hätten Entwicklung und Ressourcen gerade auf diesen Fall gewartet. Das funktioniert natürlich nie, eben gerade weil wir nicht das Opernhaus in Sydney bauen. Was kümmert es denn die (weltweite) Entwicklung, wenn in irgend einem Projekt irgendwo „im Balkan, wo die Völker aufeinander prallen“, etwas schief läuft? Wenn Ihr Projekt auf einen schwarzen Schwan der Unterart „Feststecken“ stösst, dann können sie sich schon mal auf eine grössere Verzögerung gefasst machen und sich eine Ausrede für das Steering Board ausdenken.
Projekte werden geplant und wie geplant durchgeführt, bis der erste schwarze Schwan auftaucht. Danach schwebt der Plan als Pulverdampf über dem Projektgelände und das Projekt wird meist per Reparaturdienstverhalten weiter getrieben. Im Falle des Auftretens eines schwarzen Schwans müsste das Projekt eigentlich suspendiert werden. Alle interessierten Parteien – insbesondere Auftraggeber, Management, Controlling von beiden Seiten, Kunde und Lieferant – müssen dann die Situation auf der wissensbasierten Ebene analysieren und entscheiden, wie es nun weiter gehen soll. Auf Grund dieser Entscheidungen wird ein neuer Projektplan erarbeitet, der da aufsetzt, wo das Projekt suspendiert wurde. Dann arbeitet man gemäss dem neuen Plan weiter, bis der nächste schwarze Schwan auftaucht.

1N. N. Taleb. Der Schwarze Schwan – Die Macht höchst unwahrscheinlicher Ereignisse. Carl Hanser Verlag. München 2008

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

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
    – Vertikale Flucht, Einkapselung

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

Lessons Learned ist tot, es leben die Learning Stories

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 Storytelling1. 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“2 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.
1http://www.consulting4quality.de/seminare.htm
2Art Kleiner & George Roth. Field manual for a learning historian. MIT-COL and Reflection Learning Associates, Boston 1996.

Selbstverständlichkeiten müssten doch nicht gefordert werden, oder?

Für letzten Samstag musste ich ein Clubfest mit 90 Personen organisieren. Ich wollte das Fest an einem etwas originelleren Ort durchführen, als in einem Hotel. Aber wo nimmt man gleich einen Festraum für 90 Personen her? Ich beauftragte also eine mir bekannte Eventagentur zur Durchführung des Anlasses. Damit ist die vertragliche Rahmenstruktur eines Migrations- und Integrationsprojektes gegeben.

Ein Lieferant (L) mit möglicherweise einem oder mehreren Unterlieferanten (UL), ein Kunde (K) und eine Menge von Endkunden oder -benutzern, die vom Kunden bedient werden. Die Projektpartner sind der Kunde und der Lieferant. Mit den vertraglichen Abmachungen zwischen dem Lieferanten und seinen Unterlieferanten hat der Kunde nichts zu tun, genau so wenig, wie der Lieferant mit den Endbenutzerverträgen etwas zu tun hat. Typisch ist ein Telekommunikationsanbieter, der bei einem Lieferanten beispielsweise einen Voice Switch bestellt und damit Tausenden von Endkunden einen Telefonservice anbieten will. Die Material- und Informationsflüsse hingegen, können sich durchaus über die vertraglichen Bindungen hinweg setzen. So kann es sein, dass ein Unterlieferant Material direkt beim Kunden anliefern muss, während Endkunden Retouren direkt zum Lieferanten schicken können.

In meinem Eventprojekt musste ich zunächst dem Organisator meine Erwartungen bezüglich eines Raumes spezifizieren, in welchem das Fest stattfinden soll. Das ging Hand in Hand mit dem gewünschten Rahmenprogramm. Dazu legte er mir einen Katalog vor. Ich wählte „Erlebniszene Schweiz“ mit vielen bäuerlichen und ländlichen Szenen drin. Dazu passte die Scheune eines Bauerhofs als Veranstaltungslokal perfekt. Der Organisator suchte also eine Scheune in dem Raum, den ich vorgängig bestimmt hatte. Er fand ihn in Form eines Neubaus, der vom Bauherrn, dem Bauer, gerade noch nicht bezogen worden ist. Somit musste der Bauer nur noch überredet werden, die Scheune zu vermieten, was dem Organisator gelang. Nun konnte die Feinorganisation beginnen. Wer ist wofür verantwortlich? Einen Anlass „off shore“ zu organisieren ist immer teurer, als wenn der Anlass z.B. in einem Hotel stattfindet, denn man muss jeden Dessertlöffel mitbringen. Alle Tische, jeden Stuhl, jedes Salzfässchen, einfach alles muss transportiert werden, ja sogar Toilettenhäuschen mit fliessendem Wasser. Dazu brauchte es einen Wasseranschluss, die mobile Küche benötigte einen zusätzlichen Stromanschluss, etc. Es steckt viel hinter der Organisation eines solchen Anlasses, was sich im Preis der Bankettkarte niederschlug. Dennoch reichte nicht, was die Gäste zahlten. Der Club musste subventionieren. Aber eine Clubkasse ist meist bescheiden gefüllt, so dass wir uns bei jedem Extra wohl überlegten, ob oder ob nicht. Wir waren uns bewusst, dass es in der zweiten Septemberhälfte nicht mehr laue Abende gibt, entschieden uns aber dennoch gegen eine Heizung. Es genügte, dass sich in der Erfahrung des Organisators eine Heizung erübrigte. Wir hatte noch viele andere, wichtigere Dinge zu überdenken und die Zeit drängte. Soviele Leute in einem relativ kleinen Raum werden diesen schon aufwärmen. Das entsprach zwar der Erfahrung des Organisators, hat sich dann nicht bewahrheitet. Es lag vor allem an der Tatsache, dass just in diesen Tagen ein empfindlicher Kälteeinbruch stattfand und an der Architektur des Raumes: grosse, einfach verglaste Fensterscheiben erzeugten eine Kaltluftkonvektion. Hinzu kam, dass sich in der Diele eine Luke befand, so dass jedesmal, wenn die Türe geöffnet wurde, ein Zug entstand. Und die einzige und kleine Türe war fast permanent offen, weil immer jemand der Servicecrew etwas bringen oder holen musste. Resultat: alle Gäste froren und verliessen das Fest beim erst möglichen Aufbruchzeitpunkt mit der Bemerkung, dass eine Heizung ja doch eine Selbstverständlichkeit gewesen sei.

Genau das ist es, was in Migrations- und Integrationsprojekten sehr oft zu Streitereien führt. Entweder glauben die Endkunden ? oder noch schlimmer ? der Kunde, dass etwas, das nicht im Anforderungskatalog steht, eine Selbstverständlichkeit sei. Der Lieferant argumentiert, es sei nie gefordert gewesen, während der Kunde behauptet, das sei auch nicht nötig gewesen, denn es sei ja klar, dass das dazu gehöre. Mit „das“ kann eine Leistung, eine Einrichtung oder ein System gemeint sein.
In den meisten Fällen handelt es sich um etwas, woran weder Lieferant noch Kunde zuvor gedacht haben. In unserem Fall haben wir den Einsatz einer Heizung sogar noch diskutiert. Aber eine Heizung mit entsprechendem Kaliber hätte das ganze wesentlich verteuert. Dazu kommt, dass sich der Organisator auch nicht darum riss, noch eine Heizung zu installieren. Somit war die Heizung weder im Interesse des Lieferanten, noch des Kunden. In einem solchen Fall verschiebt sich Unzufriedenheit vom Kunden zu den Endkunden, so dass sie das Projekt nur indirekt tangiert. Aber grundsätzlich bleibt das Problem dasselbe: Geht etwas schief, wird eine Partei ? normalerweise der Lieferant ? zum Sündenbock erklärt, der eine Selbstverständlichkeit vergessen hat. In den meisten Fällen führt das dazu, dass der Lieferant einen Preisnachlass gewähren muss und so eine gewichtige Margeneinbusse verzeichnet.
Fast immer ist der Grund für die Unterlassung einer „Selbstverständlichkeit“ in einer Reihe von wissenbasierten Fehlern zu entdecken.
Hang zur Bestätigung: Eine vorläufige Hypothese, die auf ersten, ziemlich dürftigen Daten basiert, stört spätere Interpretationen reichhaltiger Daten1. Die Erfahrung des Organisators, dass in der zweiten Septemberhälfte noch keine Heizung nötig ist, hat uns beim Augenschein des Lokals „blind“ gemacht. Wir haben die Luke in der Diele sowie die grossen, einfach verglassten Fensterscheiben als Kältequelle übersehen.
Übermässiges Vertrauen: Beim Planen versucht man, den einmal eingeschlagenen Handlungsstrang zu rechtfertigen, indem man sich auf Anhaltspunkte konzentriert, die diese Handlungsweise nahe legen, und indem man widersprüchlichen Anzeichen keine Beachtung schnekt. Dazu kommt noch eine Bewertungsverzerrung durch einen abgeschlossenen Handlungsplan. Ein Plan ist auch eine Theorie über den zukünftigen Zustand der Welt. Er bringt Ordnung mit sich und verringert die Besorgnis1. Unser Plan hat alle beruhigt. Er enthielt die Theorie, dass es am 20. September nicht so kalt sein werde, dass man heizen müsse. Die meisten, die mit der Organisation etwas zu tun gehabt haben, haben den Plan als genügend bewertet.
Verzerrte Überprüfung: Der Planer wird zu einem bestimmten Zeitpunkt seinen Plan nochmals in Gedanken durchgehen und alle in Betracht kommenden Faktoren überprüfen. Diese Suche wird wahrscheinlich mit einer scheinbar zufriedenstellenden Anzahl berücksichtigter Faktoren enden1; doch Shepard2 wies darauf hin: „Obwohl wir uns erinnern, dass wir zum einen oder anderen Zeitpunkt jeden der verschiedenen Faktoren bedacht haben, merken wir nicht, dass wir selten mehr als einen oder zwei gleichzeitig in Erwägung gezogen haben“. Reason spricht hier von der „alles-klar-Täuschung“.
Rückschaufehler: Das Wissen um den Ausgang eines vergangenen Ereignisses führt zu einem Anstieg der wahrgenommenen Wahrscheinlichkeit dieses Ausgangs. Langer3 nannte dies „Kontrollillusion“1. Dass der Organisator im September schon oft ähnliche Anlässe mit Erfolg ohne Heizung durchgeführt hat, erhöhte die wahrgenommene Wahrscheinlichkeit, dass es auch diesmal ohne Heizung geht. Man beachte, dass nur die wahrgenommene Wahrscheinlichkeit gestiegen ist, die mit der moteorologischen Wahrscheinlichkeit, dass es im September warm genug ist, um ohne Heizung auszukommen, nichts gemeinsam hat.
Reduzieren der Komplexität: Wenn immer jemand das Gefühl hat, etwas sei selbstverständlich und einfach, dann hat er einfach die dahinter steckende Komplexität nicht verstanden, bzw. sie in Gedanken derart reduziert, dass sie kein Problem mehr darstellt. Das kann Ignoranz sein oder einfach nur Unwissen. Die Komplexität der heutigen Welt ist dermassen hoch, dass sie alles durchzieht, wie lokal und detalliert es auch sein mag. Wir haben Komplexität als höhere Strukturiertheit begriffen. Um etwas Selbstverständliches zu erreichen, müssen wir also bestehende Strukturen entwirren und neu knüpfen. Das ist so aufändig und zeitintensiv, dass es nicht mehr selbstverständlich ist. Der Vorwurf, jemand sei bloss zu bequem oder zu geizig, um eine Selbstverständlichkeit zu leisten, ist wahrscheinlich ebenso verfehlt, wie der Vorwurf, dass Vergesslichkeit auf Faulheit basiere. In beiden Fällen ist es eine Überforderung unseres 10’000 Jahre alten Gehirnmodells gegenüber der Komplexität, wie sie sich in den letzten paar Dutzend Jahren gebildet hat.

1James Reason. Menschliches Versagen. Spektrum Akademischer Verlag. Heidelberg 1994
2R.N. Shepard. On subjectively optimum selections among multiattribute alternatives. In M. Shelley & G. Bryan (Eds.), Human Judgements and Optimality. Wiley. New York, 1964
3E.J. Langer. The illusion of control. Journal of Personality and Social Psychology, 7/1975, pp185-207

Margenpflege und gemeinsames Schulterklopfen

Eine wichtige Quelle von Projektfehlern ist die Rationalisierung. Wenn es gelingt, Arbeiten zu bündeln oder Abkürzungen zu nehmen, so kann man Aufwand sparen und dadurch die Marge erhöhen. Eine andere Rationalisierungsstrategie ist es, bei verschiedenen Kunden gleiche Projekte parallel durchzuführen.
In einer Zeit, in der „Geiz geil ist“ und niemand mehr etwas bezahlen will aber dennoch alle höchste Ansprüche haben, können die Anbieter ihre geschätzten Aufwendungen nicht mehr voll verrechnen, ohne von der Konkurrenz unterboten zu werden. Deshalb ist die Marge schon zu Projektbeginn so klein, dass kaum ein Anreiz für Qualität besteht. Kleine Auslassungen in Dokumentationen werden meistens nicht bemerkt und haben auch keine Auswirkungen. Verletzung von Qualitätsstandards werden dann im lerntheoretischen Sinne verstärkt: man hat etwas davon, wenn man Arbeiten nicht vollständig und perfekt ausführt. Solange der Kunde nichts merkt und nicht reklamiert, spart man nämlich Aufwendungen und erhöht so die Marge. Benötigt der Lieferant die Dokumentation jedoch schon während des Projekts – z.B. Installations- oder Testdokumentationen – empfiehlt es sich natürlich nicht, zu schlampen. Denn Dokumentationslücken können sich in Aufwand und Verzögerungen manifestieren, die die Einsparung an Zeit bei der Dokumentationserstellung um ein Mehrfaches übersteigen. Wenn in einem globalisierten Unternehmen jedoch mehrere in die Tiefe geschachtelten Abteilungen aus verschiedenen Konzerngesellschaften an der Bereitstellung der Projektergebnisse beteiligt sind, kann nicht mehr sicher gestellt werden, dass immer alle Ergebnisse vollständig und richtig sind.

Eine andere Quelle von Fehlern berichtet Dietrich Dörner. Wir treffen diese Fehler auch in Projekten häufig an. Sie bestehen in der Tendenz einer Gruppe von Fachleuten, sich selbst zu bestätigen, alles richtig und gut zu machen. Ein Team mit einer gewohnheitsmässig hohen Selbstsicherheit „betreibt“ das Projekt nicht mehr „analytisch“, sondern „intuitiv“. Dörner schreibt: Man glaubt zu wissen, womit man zu rechnen hat, und man glaubt sich erhaben über die lächerlichen Projektdokumentationen und Qualitätsstandards, die allenfalls für Projektanfänger gelten mögen, aber nicht für ein Team gestandener Fachleute, die vielleicht sogar noch PMI-zertifiziert sind1. Die Tendenz einer Gruppe, Kritik implizit durch Konformitätsdruck zu unterbinden, hat Janis 1972 als die Gefahr des groupthink bei politischen Entscheidungsteams geschildert2. Wir treffen sie auch zuweilen bei Geschäftsleitungen an. Wenn man „lügen“ als „sich als über alle Probleme erhaben darzustellen“ und „Meineid“ als „Unterbinden von Kritik“ interpretiert, so ist Reinhard Meys Lied eine gelungene Karikatur der beschriebenen Situation:

Der Steuermann lügt, der Kapitän ist betrunken,
und der Maschinist in dumpfe Lethargie versunken,
die Mannschaft: lauter meineidige Halunken,
der Funker zu feig’ um SOS zu funken.
Klabautermann führt das Narrenschiff,
volle Fahrt voraus und Kurs aufs Riff!

Die Ladung ist faul, die Papiere vergilbt,
die Lenzpumpen lecken und die Schotten blockiert,
die Luken weit offen und alle Alarmglocken läuten.
Die Seen schlagen mannshoch in den Laderaum,
und Elmsfeuer züngeln vom Ladebaum,
doch keiner an Bord vermag die Zeichen zu deuten.

Am Horizont Wetterleuchten; die Zeichen der Zeit:
Niedertracht und Raffsucht und Eitelkeit.
Auf der Brücke tummeln sich Tölpel und Einfaltspinsel.
Sie rüsten gegen den Feind, doch der Feind ist längst hier,
er hat die Hand an deiner Gurgel, er steht hinter dir,
im Schutz der Paragraphen mischt er die gezinkten Karten.

1Dietrich Dörner. Die Logik des Misslingens. Strategisches Denken in komplexen Situationen. Rowohlt Taschenbuchverlag. Reinbek b. Hamburg 1992 u. 2002

2I. Janis. The Victim of Groupthink. Houghton Mifflin. Boston 1972

Wahrnehmungen haben eine endliche Geschwindigkeit

In den letzten paar Wochen habe ich gleich mehrmals die relativ frustrierende Erfahrung machen müssen, dass man Pläne nicht ohne weiteres ändern darf, vor allem, wenn die Änderung nur Details betrifft. Beispielsweise habe ich für einen Verein ein Jahresprogramm zusammen gestellt und dieses kommuniziert. Kurz vor dem Inkrafttreten des Programms habe ich eine kleine Änderung vorgenommen und zweimal mündlich darauf aufmerksam gemacht. Aber nein, mindestens die Hälfte der Mitglieder haben die Änderung nicht zur Kenntnis genommen und stellten sich auf den alten Plan ein, was natürlich konfliktträchtig ist, wenn die beiden Planvarianten kollidieren. Planänderungen müssen mit Pauken und Trompeten kommuniziert werden. Sie müssen jeden Betroffenen am Ärmel nehmen, ihm in die Augen sehen und sich bestätigen lassen, dass er die Änderung zur Kenntnis genommen habe. Am besten lassen Sie ihn mit dem eigenen Blut unterschreiben. Aber wer will schon so ein Tamtam machen, wenn die Änderung bloss ein Detail betrifft?

Beim Durchlesen meines Eintrags Glauben Sie, Vergessen sei bloss eine Charakterfrage? vom 12. August ist mir ein interessanter Zusammenhang zwischen dem wissensbasierten Verhaltensmuster Überbewertung des aktuellen Motivs und Verzögerungen aufgefallen, die wir verschiedentlich bereits untersucht haben. Ich stelle mir ein Projektsystem stets als Oberfläche eines Teiches vor. Wo immer im Projekt ein Stakeholder – Projektmanager, Projektmitarbeiter, Linie, Marketing, Ver- und Einkauf, Kunde, Lieferant, etc. – handelt, sendet sein Tun konzentrische Wellen durch das Projekt. Sie lösen bei denen, die sie erreichen, wieder Entscheidungen und Handlungen aus, die sich wellenförmig durch das Projektsystem fortsetzen. Erreichen uns viele dieser Wirkungswellen, empfinden wir das Projekt als komplex, chaotisch, turbulent oder fluktuativ, was zur Folge hat, dass wir selbst zu strampeln anfangen und so noch viel mehr Wellen erzeugen. Dörner nennt den Mach-mal-vielleicht-hilft-das-ja-Ansatz Reparaturdienstverhalten und die Konzentration auf viele Problemfragmente Projektemacherei1.

 

Ein einmal publizierter Plan „durchtränkt“ das Projekt langsam. Es braucht einige Zeit, bis er im Bewusstsein aller ist. Wenn Sie nur ein Detail ändern, dann braucht es seine Zeit, bis dieses Detail durch das Projektsystem propagiert ist, auch wenn Sie die Änderung mehrmals erwähnt haben. Die Leute vergessen es sofort wieder, wenn sie es überhaupt realisiert haben. Denken Sie an Reasons Aufmerksamkeitsfehler auf der fähigkeitsbasierten Ebene oder an den Spurenzerfall im Langzeitgedächtnis. In der Zeit der Propagation einer Planänderung sind gewissermassen beide Planvarianten aktiv. Das müssen Sie als Projektmanager stets bedenken und alle abholen. Wehe, Sie verlassen sich darauf, dass alle Stakeholder die Änderung realisiert haben! Ändern Sie nie einen Plan ohne Pauken und Trompeten und einem mittelkalibrigen Feuerwerk!

Wahrnehmungen erleiden genauso Verzögerung wie die Körner, die von den Tauben aufgepickt werden oder die Paletten im Brennofen. Siehe Verzögerungen erster und höherer Ordnung und Pipeline-Verzögerungen. Angenommen, Sie haben eine Planvariante zu 100% in Ihrem Gedächtnis. Nun wird Ihnen eine Änderung kommuniziert. Das führt nur dazu, dass die ursprüngliche Planvariante nur noch zu vielleicht 90% im Gedächtnis ist, während die neue Variante die restlichen 10% ausfüllt. Wird Ihnen die Änderung ein zweites Mal kommuniziert, gilt die alte Variante für Sie noch zu 80% und die neue zu 20%, usw. Natürlich ist das bloss ein Modell. Entweder haben Sie geschnallt, dass der Plan abgeändert wurde oder Sie haben es nicht mitbekommen. Um jedoch die Tatsache zu verstehen, dass eine Änderung nur nach und nach ins Bewusstsein der Leute dringt, können wir uns dem Modell bedienen, dass der eine Gedächtnisinhalte nach und nach durch einen neueren verdrängt wird. Das könnte man dann so darstellen:

 

Was passiert nun, wenn die Änderung nur einmal, wenn auch deutlich, kommuniziert wird? Der aktuelle Gedächtnisinhalt wird sich wie folgt entwickeln:

 

Zwar nehmen wir eine Veränderung wahr, aber nach mehr oder weniger kurzer Zeit haben wir sie wieder vergessen. Das ist doch genau die Situation, die wir von den Körner und den Tauben her kennen. Interessanterweise verhalten sich Prozessverzögerungen erster Ordnung und Wahrnehmungsverzögerungen erster Ordnung genau gleich, obwohl sie eine ganz andere Struktur haben. Wird die Veränderung konstant gemeldet, dann passt sich die Wahrnehmung langsam der kommunizierten Realität an:

Die rote Kurve zeigt den Plan. Er erfährt eine Änderung in der Woche 5. Die blaue Kurve zeigt die aktuelle Wahrnehmung. Sie gleicht sich langsam der gemeldeten Tatsache an.

1Dietrich Dörner. Die Logik des Misslingens. Rowohlt Taschenbuch Verlag. Reinbek bei Hamburg 1992 (2002)