Vagabundieren Sie auch ab und zu?

Ein Beispiel für die Bildung einer eher abstrakten komplexen Struktur ist das Zustandekommen einer öffentlichen Meinung. Kontrollparameter sind z.B. Veränderungen der wirtschaftlichen Lage oder Überhandnehmen eines innenpolitischen Drucks. Solche Veränderungen erschüttern das Vertrauen in eine bisherige Meinung. Dadurch wird das System instabil. Es bilden sich zunächst eine Menge konkurrenzierender Alternativmeinung aus. In dieser Situation kann eine einzelne Gruppe von Menschen, von Avantgardisten oder aktiven Revolutionären, ja manchmal sogar einzelne Individuen zum Kristallisationspunkt einer neuen Meinung werden. Hermann Haken schreibt: Unvorhersehbare, scheinbar lokale Ereignisse bekommen bei einem Zustand der Instabilität eine enorme Ausstrahlungskraft, die sie in normalen Zeiten nie gehabt hätte. In jenen Zeiten wäre die Aktionen derartiger einzelner Gruppen eine schnell vergessene Episode geblieben.1 Die vorherrschende öffentliche Meinung ist eine Mode, die die Bürger „versklavt“. Ist aber einmal eine solche Mode zustande gekommen, muss sie laufend genährt werden, um zu bestehen. Die komplexe, relativ stabile Struktur eines Systems, ist nie statisch. Sie fällt in sich zusammen, wenn sie nicht durch Energie, Material und/oder Information genährt wird. Umgekehrt muss eine Gesellschaft, die soviel Strom, Benzin, Erdöl, Zeitungen, Batterien, Fernseher, News, Inetrnet, Mails, etc. konsumiert und verarbeitet, zwangsläufig einen hohen Komplexitätslevel haben.

Wenn Projekte als instabile und chaotische Phasen angesehen werden, die einer Veränderung vorangehen, dann können also kleinste zufällige Ereignisse enorme Ausstrahlungskräfte auf das Projekt entwicklen. Wie reagiert ein Projektmanager in dieser Situation? Eigentlich sollte er ständig auf der wissensbasierten Ebene agieren. Tut er das? Dietrich Dörner hat herausgefunden, dass die Menschen in fluktuativen, unsicheren Situationen hauptsächlich zwei Verhaltensweisen zeigen, die für das Projekt nicht immer förderlich sein müssen2. Den ersten Verhaltensmodus nennt er Thematisches Vagabundieren. In fluktuativen Zeiten erreichen uns zahlreiche Hiobsbotschaften. Wenn wir beginnen, uns mit der Schadensbegrenzung des ersten Ereignisses zu beschäftigen, trifft die nächste Hiobbotschaft ein, bevor wir fertig sind. Da in unserer Wahrnehmung immer gerade das aktuellste Thema auch das wichtigste zu sein scheint, und da wir unsere Unfähigkeit erahnen, das erste Ereignis befriedigend in Griff zu bekommen, verlassen wir es und starten sofort Schadenbegrenzungsaktionen für das neu aufgetauchte Ereignis. Immer wenn der (Projekt-)Manager Schwierigkeiten im Umgang mit einem Thema hat, lässt er es fallen, so dass er seiner eigenen Hilflosigkeit nicht mehr als nötig gegenüberstehen3 muss.

Den zweiten Verhaltensmodus, den Dörner nachwies, nennt er Reduktive Hypothesenbildung. Alle Phänomene werden einer einzigen Ursache zugeschrieben. Ich selbst habe einmal in einem sehr fluktuativen Projekts den kleinkarierten Charakter des Kunden als einzige Ursache für den harzigen Fortschritt identifiziert. Ein Beispiel für eine reduktive Hypothesenbildung ist die Dolchstosslegende, nach der es angeblich die Juden, Jesuiten und Freimaurer waren, die für die Niederlage Deutschlands im Ersten Weltkrieg verantwortlich waren. Und jener absonderliche Hagelschlag im Sommer 1953 wurde damals auf die Atombomberversuche zurückgeführt. Verkürzten oder reduktive Hypothesen sind sehr attraktiv. Sie reduzieren mit einem Schlag die Unsicherheit und verstärken das Gefühl, man verstehe, was vor sich geht. Dörner schreibt: Wenn man einmal zu wissen meint, was die Welt im Innersten zusammenhält, so gibt man ein solches Wissen ungern auf. Informationen, die einer reduzierten Hypothese zuwider laufen, werden einfach nicht zur Kenntnis genommen. Im Endeffekt verschanzt sich der Manager hinter einem dogmatischen Hypothesengerüst, welches die Realität in keinster Weise abbildet (Dogmatische Verschanzung4). Wir kennen das auch von Leuten, die angesichts der Komplexität der modernen Welt in fundamentalreligiöse oder esoterische Ideen flüchten. Können Sie sich vorstellen, wie sich die reduzierte Hypothese eines (Projekt-)Managers auf ein Projekt oder eine Unternehmung auswirkt? Beide Verhaltensweisen befolgen einfache Regeln. „Wenn Du einsiehst, dass Du nicht fähig bist, das Problem zu lösen, dann widme Dich einem anderen Thema“ und „Wenn die Situation unübersichtlich und unbestimmt ist, dann suche einen einfachen, zentralen Grund für die Probleme und reduziere alles auf diesen“. Letztere Regel verhindert, dass Unbestimmtheit Angst erzeugt, eine vor 100’000 Jahren sehr nützliche Regel. Wer aber als Projektmanager in komplexen Situationen diese Regeln anwendet, der nutzt sein wissensbasiertes Potential nicht aus!

1Hermann Haken. Erfolgsgeheimnisse der Natur – Synergetik: Die Lehre vom Zusammenwirken. Deutsche Verlags-Anstalt. Stuttgart 1981.
2Dietrich Dörner. Die Logik des Misslingens – Strategisches Denken in komplexen Situationen. Rowohlt Taschenbuch Verlag. Reinbek bei Hamburg 1994.
3Dietrich Dörner. On the difficulties people have in dealing with complexity. In J. Rasmussen, K. Duncan and J. Leplat (Eds.). New Technology and Human Errors. Wiley, London 1987
4Harald Schaub. Störungen und Fehler beim Denken und Problemlösen. In J. Funke (Hrsg.). Denken und Problemlösen. Enzyklopädie der Psychologie: Kognition – Band 8. Hogrefe Verlag, Göttingen 2006
Schaub gibt hier eine erschöpfende Zusammenstellung von Kognitionsfehler im Umgang mit Komplexität. Lassen Sie sich aber von der langen Liste nicht entmutigen. Viele der Fehler sind identisch oder hängen sehr stark miteinander zusammen. Wem sie bekannt sind, der kann sie klassifizieren und erkennt sie in fluktuativen Situationen wieder.

Komplexität revisited

Es wird Zeit, dass wir uns wieder einmal mit dem Begriff der Komplexität beschäftigen. Sie erinnern sich, dass ich im Beitrag Bestimmt die Anzahl Moden die Komplexität? erklärt hatte, dass Komplexität von der Anzahl Moden und dem Vorhandensein von (dynamischen) Nichtlinearitäten abhängt. Das ist aber nur die halbe Wahrheit. Um auch den Rest zu verstehen muss man wissen, wie sich ein System entwickelt. Dazu wollen wir uns nach einem physikalischen System umsehen, weil diese gegenüber lebender Systeme recht einfach zu verstehen sind. Ein in der Physik bekanntes System, das genügend komplex ist, aber dennoch transparent genug, um daraus Erkenntnisse zu ziehen, ist eine horizontale Flüssigkeitsschicht, die einen gewissen Energiestrom verarbeiten muss. Zu Beginn soll die Flüssigkeit langsam von unten erwärmt werden. Vorher ist die Flüssigkeit auf einem niederen Komplexitätslevel. Es gibt einzelne lokale Strömungen, verursacht durch Temperaturschwankungen oder – wer mag – kann auch die Abhängigkeit mit der Erdrotation einbeziehen. Ein schwacher Energiestrom kann die Flüssigkeit ohne weiters verkraften, ohne sich raum-zeitlich speziell strukturieren zu müssen. Durch Wärmestrahlung werden irgendwo im Systems einzelnen Flüssigkeitspaketen Energie zugeführt. Dadurch nehmen die lokalen zufälligen Strömungen zu, das System wird leicht chaotisch. Durch lokale Wärmeunterschiede der Heizplatte beginnen dann einzelne Flüssigkeitspakete Richtung Oberfläche aufzusteigen. Sie erzeugen lokale Konvektionsströmungen, sogenannte Fluktuationen, die durch Reibung und Abkühlung zunächst noch unterdrückt werden. Diese Ströme einzelner Flüssigkeitspaketen wird immer ungestümer in Zahl und Kraft, so dass an der unteren Begrenzung der Flüssigkeitsschicht ein regelrechtes Brodeln entsteht, das bald die ganze Flüssigkeit erfasst. Sobald eines der Flüssigkeitspakete genug Energie hat, um die Oberfläche zu erreichen, reisst es seine Umgebung mit und verdrängt an der Oberfläche kühlere Flüssigkeit, der nur noch der Abstieg an die untere Begrenzung möglich ist. Dabei reisst auch sie Flüssigkeitspakete aus der Umgebung mit. Damit entsteht eine zirkuläre Konvektionsströmung, die sich instantan über die ganze Flüssigkeitsschicht ausweitet und diese in Konvektionszellen strukturiert. Interessanterweise nehmen die Zellen von oben gesehen meist eine fünf- oder sechseckige Gestalt an.

Sie werden als Bénard-Zellen bezeichnet, nachdem Charles Bénard dieses Phänomen vor ca. 100 Jahren entdeckt hat. Nun hat das Flüssigkeitssystem mit seiner neuen Organisationsform einen höheren Komplexitätslevel erreicht, der es in die Lage versetzt, den erhöhten Energiedurchfluss auszuhalten. Das ist eine Entwicklung, die vor allem für lebende Systeme typisch ist:

  1. Das System hat eine stabile Struktur
  2. Energie- und Materiedurchflüsse führen innerhalb des Systems zu Spannungen
  3. Die einzelnen Teile versuchen, sich individuell und unabhängig voneinander so auszurichten, dass die Kräfte möglichst wenig an ihnen zerren können
  4. Das System ist als ganzes in einem instabilen, chaotischen Zustand
  5. Es gibt nur einige wenige Moden, wie sich die einzelnen Teile gegenseitig ausrichten können, damit die Kräfte der Durchflüsse ihnen möglichst wenig anhaben können und ohne dass sie sich gegenseitig stören (z.B. können die Konvektionströme der Bénard-Zellen im Uhrzeigersinn oder im Gegenuhrzeigersinn rotieren)
  6. Einer dieser Moden wird als resultierende Struktur realisiert. Welche Mode gewählt wird, ist nicht im voraus bestimmt kann prinzipiell nicht vorhergesagt werden.
  7. Die neue Struktur ist relativ stabil, solange die Energie- und/oder Materieflüsse durch das System aufrecht erhalten bleiben und liegt auf einem höheren Komplexitätsniveau, als die Struktur vor der Veränderung.

Sie können das Bild durch anklicken vergrössern. Nach einer Phase relativer Stabilität, die immer kürzer ausfällt, gerät das System wieder in eine Phase kritischer Instabilität, in der sich die Möglichkeiten, eine neue Struktur anzunehmen, verzweigt. Der Evolutionspfad des Systems (rot dargestellt) kommt dadurch zustande, dass es in jedem Verzeigungspunkt einen Pfad zufällig auswählt. Die Vertikale hat in diesem Diagramm keine Bedeutung. Es ist eher eine Aufsicht, als ein Diagramm in einem Koordinatensystem. Die stabile Phase 2 ist in jedem Fall komplexer als die stabile Phase 1 und stabile Phase 3 ist komplexer als Phase 2. Der Komplexitätsparameter gibt an, wie viel Druck auf das System ausgeübt wird, z.B. durch Energie-, Material- oder Informationsflüsse, die das System durchströmen. Man denke dabei an eine Stadt. Das ist ein höchst komplexes, weil strukturiertes System, das aber nur solange aufrecht erhalten werden kann, als dass jeden Tag hunderte von Tonnen Material in Form von Nahrung, Kleider, etc. hinein- und in Form von Abfall heraus gepumpt werden. Parallel dazu existiert ein Energiefluss: hinein hochwertige Elektrizität, hinaus Wärme. Solange diese Flüsse bestehen, solange kann die Stadt einigermassen in einer stabilen Lage gehalten werden. Komplexität ist also im grossen und ganzen eine relativ stabile Angelegenheit. Man denke an den menschlichen Körper. Das ist ganz gewiss ein hochkomplexes System und hoffentlich ein paar Jahrzehnte einigermassen stabil. Nun, paar Beschwerden müssen wir uns schon gefallen lassen. Schliesslich ist ein lebendes System dynamisch, d.h. es verändert sich mit der Zeit und bleibt nicht immer gleich. Zu einer Veränderung gehören jedoch auch Schwankungen um die stabile Gleichgewichtslage. Der Bildung einer relativ stabilen Phase geht immer eine chaotische, also höchst fluktuative Phase voran.

Ein Projekt muss also prinzipiell „chaotisch“ sein, da es definitionsgemäss eine Veränderung zum Ziel hat. Projekte sind die instabile Phase, die jeder stabileren vorangeht. Wenn jemand also sagt, ein Projekt sei sehr komplex, dann meint er vielleicht eben gerade den instabilen, fluktuativen Charakter des Projekts.

1Carsten Jäger. Untersuchungen einer kohärenten Marangoni-Bénard-Konvektionszelle. Diplomarbeit. Aachen, 1996

Wie entsorgen Sie weisses Porzellan?

Bei der Altglassammelstelle am Bahnhof Oerlikon beobachtete ich gestern um 17.30 Uhr einen jungen Mann, der mit einer Kiste Altglas daher kam. Wahrscheinlich musste er für ein Restaurant oder ein Take away das Altglas entsorgen. Er ging zuerst zum Container für weisses Glas. Als er fälschlicherweise nach einer grünen Flasche griff, legte er diese wieder ordentlich zurück, denn dieser Container ist ja ausschliesslich für weisses Glas bestimmt. Er arbeitete also durchaus sorgfältig. Dann allerdings warf er noch ein paar Stück weisses Porzellan in diesen Container. Der Mann hatte wohl den Auftrag, das weisse Porzellan mit dem weissen Altglas zusammen zu entsorgen. Vermutlich dachte sein Chef: „Weiss ist weiss und wenn man es fallen lässt, zerbricht das Porzellan wie Glas, also kann man es wie weisses Glas behandeln“. Aber ich traute meinen Augen nicht, denn ich war mir fast sicher, dass damit das Altglas in diesem Container für jegliches Recycling verloren war und nur noch in einer Grube der Endlagerung zugeführt werden kann. Es braucht nicht viel Phantasie sich vorzustellen, was passiert, wenn die Glasschmelze von Altporzellan verunreinigt ist. In der Tat fand ich einen Artikel unter dem Titel Keramik und Porzellan gefährden Glas-Recycling, in welchem der Autor schreibt: Zu Problemen bei der Wiederverwertung von Altglas sorgen immer wieder Keramik und Porzellan, die im Altglascontainer liegen. Solche Fremdstoffe lassen sich auch mit moderner Technologie nicht aussortieren und führen bei der Glasschmelze zu unbrauchbaren Flaschen mit Fehleinschlüssen. Klar, Porzellan ist Grubengut und gehört in den entsprechenden Container, der bei öffentlichen Abfallsammelstellen bereit steht. Unter dem Titel Trennverfahren lese ich allerdings, dass es sogenannte KSP-Abscheider gibt, die Keramik-, Stein- und Porzellanteile im Altglas erkennen und sie mit Druckluft entfernen. Nun gut, also hat der Mann noch einmal Glück gehabt, obwohl es ihn wahrscheinlich herzlich wenig interessierte.
Diese Geschichte zeigt sehr schön, was James Reason Enkodierdefizite nennt1. Das ist ein Fehler auf der regelbasierten Ebene. Sie erinnern sich an Reasons Dreiebenenmodell, das ich am 29. Juli 2008 im Beitrag Wo kann in Projekten und Unternehmen etwas schief gehen? vorgestellt habe. Entweder sind bestimmte Eigenschaften des Problemraumes überhaupt nicht oder sie sind ungenau enkodiert. Er berichtet, dass Ellingstadt, Hagen und Kimball 1970 Kontrollausübungen erfahrener Autofahrer mit denen von Anfängern verglichen. Anfänger mit weniger als zehn Stunden Fahrerfahrung neigten dazu, die Aufgabe zu vereinfachten, indem sie die Kontrolle der Geschwindigkeit praktisch ignorierten2. Das entspricht genau unserem Mann an der Glasentsorgungsstelle. Er blendete einfach die Materialfrage aus und bog die Regel „Wenn weisses Glas, dann in den Container, auf dem Weisses Glas steht“ einfach um zu „Wenn weiss und zerschlägt wie Glas, dann in den Container, auf dem Weisses Glas steht“.
Der Sinn von PMI- und IPMA-Zertifizierungen ist es, dem Projektmanager Regeln zur Hand zu geben, die in Projekten universell anwendbar sind, so dass er in kritischen Momenten nicht auf die langsame wissensbasierte Ebene hinauf gehen muss. Das ist der Sinn von jeder Ausbildung schlechthin. Reason berichtete auch von einem Experiment, das Siegler 1983 durchführte. Er liess fünfjährige Kinder ein Training durchlaufen, in welchem sie auf die Bedeutung des Abstands eines Gewichts vom Aufhängepunkt einer Waage aufmerksam gemacht wurden, nachdem er fand, dass die Kinder diesen Faktor ständig ausblendeten und daher an Aufgaben zu Balkenwaagen scheiterten3. Solange es den Kindern nicht gelang, auf den Abstand zu achten, konnten sie ihn nicht enkodieren. Er kam in den Regeln, mit denen sie Balkenwaageprobleme lösten, nicht vor.
Genau das kann passieren, wenn erfahrene Projekt- und andere Manager auf der regelbasierten Ebene ihre Projekte und Unternehmen führen. Wenn sie einen Faktor antreffen, der in den ihnen bekannten Regeln nicht vorkommt, biegen sie die Regel so, dass sie sofort weiter arbeiten können, anstatt dass sie versuchen, das Problem auf der wissensbasierten Ebene zu lösen. Klar kann man Porzellan einfach in den Container werfen, auf dem Weisses Glas steht. Aber zu einem späteren Zeitpunkt wird die falsche Anwendung einer Regel zu einem Riesenproblem führen. Vor allem in Projekten kann das dann ganz schön unangenehm sein.

1James Reason. Human Error. Cambridge University Press 1990.
2James Reason. Menschliches Versagen – Psychologische Risikofaktoren und moderne Technologien. S. 114. Spektrum Akademischer Verlag. Heidelberg 1994.
3ebenda, S. 113

Migrations- und Integrationsprojekte sind anders

Der Standish Chaos Report erscheint seit 1994 alle zwei Jahre. Er beruht auf einer Umfrage unter mehr als 300 amerikanischen Entwicklungsunternehmen und untersucht über 8000 Projekte. Aus der Reihe der bisher erschienenen Reports geht hervor, dass der Anteil erfolgreicher Projekte bei ungefähr 28% konstant blieb, während der Anteil derjenigen Projekte, bei denen der Kosten- oder Zeitrahmen beträchtlich gesprengt wurde, zu Lasten der abgebrochenen Projekte konstant angewachsen ist. Aber es handelt sich ausschliesslich um Softwareentwicklungsprojekte. Als Grund, dass immer weniger Projekte abgebrochen werden, wird die Anwendung formaler Methoden angegeben1. Aber trotz dieser formalen Methoden – was immer das für welche sind – schiessen doch um 70% aller betrachteten Projekte an den Zielen vorbei. Als wichtiger Grund für das Scheitern von Entwicklungsprojekten ist die ungenügende Benutzereinbindung genannt. Wie soll denn das geschehen? Wie soll z. B. Microsoft die hunderten von Millionen Benutzer einbeziehen, die auf der ganzen Welt verstreut sind und in verschiedenen Kulturkreisen leben? Erhöhte Komplexität aufgrund der Globalisierung lässt grüssen. Microsoft kann nicht einmal ein signifikantes Sample von Benutzern begrüssen, das ist schlicht unmöglich. Selbstverständlich gehört eine tiefgehende Marktuntersuchung allem voran, aber von einer Benutzereinbindung kann keine Rede sein. Oder wie soll ein Hersteller von Telekommunikations- oder Bankenlösungen die Benutzer einbeziehen? Benutzer sind nämlich nicht die Betreiber, die die Lösungen kaufen und bezahlen, sondern deren ihre Kunden, also die vielen Millionen Endkunden, die telefonieren oder via E-Banking ihre Zahlungen machen.

Interessanterweise werden in der Literatur fast ausschliesslich Softwareentwicklungen untersucht, wenn es um IT-Projekte geht. Andere IT-Projekte werden eher stiefmütterlich behandelt. Dabei sollten doch auf ein Entwicklungsprojekt mehrere Dutzend Migrations- und Integrationsprojekte (MIP) folgen, denn schliesslich möchte man ja auch ausrollen, was man einmal mühsam entwickelt hat. Warum denn MIP in der Literatur ein derart steifmütterliches Dasein fristen, kann ich nicht verstehen. Es ist zu befürchten, dass sich die Zertifizierer, wie PMI und IPMA, und auch andere Herausgeber formaler Projektmanagementmethoden, an den Gegebenheiten von Entwicklungsprojekten orientieren. Aber die viel zahlreicheren MIP gehorchen anderen Gesetzen. Der mangelnde Einbezug des Kunden ist da z. B. kein Thema. Vielmehr laufen MIP die Gefahr, dass der Anwender den Hersteller zu wenig einbezieht. Es besteht momentan ein Trend weg vom Projektleiter des Herstellers. Die Anwender denken, dass es reicht, wenn sie den Projektleiter stellen. Aber wie man sich denken kann, funktioniert das nie, denn wer sorgt z.B. dafür, dass dem Projekt genügend Expertise seitens Hersteller-Entwicklungscenter zukommt? Sicher nicht der Projektleiter des Kunden, der aus der Sicht des Entwicklungscenters irgendwo auf der Welt in einem unbedeutenden Land sitzt. Sie erinnern sich ja an den Beitrag Staus im Projektmanagement vom 25. Juli 2008. Natürlich sind das Angelegenheiten, für die sich der Kunde nicht interessiert, und natürlich ist es verständlich, wenn er in der Offerte keinen entsprechenden Posten sehen will. Aber der Projektleiter des Lieferanten ist am Abend auch hungrig und kann die Arbeit nicht für Gottes Lohn machen. Hier entwickelt sich gerade eine neue Mode, die zur Komplexität beiträgt. Die Kräfte, welche die Randbedingungen liefern sind:
• Preisstandards für die Services, die mit dem System angeboten werden sollen
• Globalisierte Herstellerorganisationen vs. national operierende Betreiber
• Zunehmende Spezialisierung der Systeme für immer mehr konvergierende Applikationen
Die Players sind die Hersteller und ihre Subcontractors, die Betreiber entlang einer mehrstufigen Supply Chain sowie Millionen von Endbenutzern. Alle diese Players richten sich im herrschenden Kräftefeld so aus, dass sie das kleinste Leid haben, so wie sich ein Windzeiger in den Wind stellt, damit er der Windkraft am wenigsten ausgesetzt ist. Das führt möglicherweise zu einer Mode, die die Players „versklavt“, so dass sie schlussendlich ihre Ausrichtung nicht mehr selber wählen können. Was die Begriffe Mode und versklaven anbelangt erinnern Sie sich gewiss an den Beitrag Was ist komplex am Bierspiel vom 21. Juli 2008.

1 Wiki Softwaretechnik, Artikel Chaos-Report

Wo kann in Projekten und Unternehmen etwas schief gehen?

Ich weiss schon, es mag seltsam klingen, wenn ich sage, dass wir für das Projektmanagement Skills und Regeln/Tools haben, nur das Wissen noch fehle. Dabei ist doch das PMBOK des PMI in neun Wissensgebiete aufgeteilt. Bitte lassen Sie mich ganz kurz ein wenig ausholen.

Etwa Mitte der 1960er Jahre rückte die Aufmerksamkeit ins Rampenlicht der Psychologie. In den 70er Jahren wurden diese ersten Ergebnisse mit verschiedenen Theorien angereichert, so der Ressourcentheorie, die die Aufmerksamkeit als ein einziges Reservoir an Informationsverarbeitungsressourcen betrachtet oder die Mehrkanalprozessoren-Theorie, die annimmt, dass jede komplexe Aufgabe von einer Reihe unabhängiger Prozessoren bearbeitet wird. 1972 stellten Newell&Simon den General Problem Solver vor, eine Theorie, die wesentlich zum Verständnis der Art und Weise menschlichen Problemlösens beitrug. Dann kamen Konzepte wie das Arbeitsgedächtnis oder Skripts hinzu, die anfangs der 80er Jahren zu brauchbaren Aufmerksamkeits-Handlungs-Theorien führten. 1982 stellte Rasmussen ein Modell der kognitiven Kontrollmechanismen vor, das auf drei Ebenen beruht: Skill- oder fähigkeitsbasierte Ebene, regelbasierte Ebene und wissensbasierte Ebene1. Rasmussens Modell war deutlich von Newells und Simons General Problem Solver beeinflusst und zielte auf Fehler, die während Notfällen in riskanten Industrie- und Prozessanlagen begangen werden. 1986 erhielt Rasmussens Modell in Tschernobly tragische Bestätigung. 1990 stellte James Reason im Buch Human Error, aus dem übrigens der obige Abriss der geschichtlichen Zusammenhänge stammt, sein Generic Error Modelling System vor1. Der Name des „Systems“ ist ziemlich ungeschickt gewählt. Eigentlich ist es gar kein Fehlermodellierungssystem, sondern eine geraffte Darstellung von Rasmussens Modell menschlichen Verhaltens.

Sie können das Bild vergrössern, indem Sie es anklicken. Ich schlage vor, das Modell auch im Projektmanagement anzuwenden. Auf der untersten, fähigkeitsbasierten Ebene laufen die Tätigkeiten fast automatisch ab. Möglichst viel wird durch das Langzeitgedächtnis gesteuert, das schnell, energieeffizient und ohne Inanspruchnahme des Bewusstseins arbeitet. Dafür enthält das Langzeitgedächtnis einige archetypische Beurteilungs- und Handlungsmuster, die in einer komplexen Welt vielleicht nicht mehr immer opportun sind. Normalerweise sollte während den fähigkeitsbasierten Handlungen von Zeit zu Zeit ein Aufmerksamkeitscheck durchgeführt werden. Auch das ist einprogrammiert und läuft automatisch ab, kann aber mal versagen. Passiert etwas aussergewöhnliches, schaltet das Gehirn auf die regelbasierte Ebene und grabscht in möglicherweise vorhanden Regeln und Vorschriften, die in ähnlichen Fällen wie dem vorliegenden, das Problem erfahrungsgemäss schon mal gelöst haben. Erst wenn auch das nichts hilft, muss der Problemlöser wohl oder übel im obersten Stock seines Gehirns die Lösung suchen. Die oberste, wissensbasierte Ebene ist etwas wackelig: langsam, teuer, weil sehr energieintensiv und selten gebraucht, also muss mit Stillstandsschäden gerechnet werden. Es ist unser Grosshirn, das Organ, das den Mensch von allen anderen Säugetieren unterscheidet. Ich will damit nicht in den Zynismus Russells einstimmen, der einmal sagte: „Manche Menschen würden lieber sterben, als denken und sie tun’s dann auch“. Dass wir die wissensbasierte Ebene so selten benutzen war ein überlebensnotwendiger Schutzmechanismus, den wir von der Natur mitbekommen haben. Heute stört er leider ziemlich massiv. Die regelbasierte Ebene findet immer etwas, und wenn’s eine falsche Regel ist. Dann gibt es mächtige kognitive und affektive Kräfte, die sich zusammentun, um den Problemlöser glauben zu machen, er solle unangemessene oder unvollständige Lösungen an dieser Stelle als zufriedenstellend akzeptieren3. W. B. Rouse formuliert das so: Menschen, wenn sie die Wahl haben, verhalten sich bevorzugt wie kontextspezifische Mustererkenner, statt dass sie versuchen hochzurechnen oder zu optimieren4. Das heisst, dass Menschen die Probleme lieber auf der regelbasierten Ebene lösen als in die wissensbasierte Ebenen hinauf zu gehen.

Ich denke, dass das Modell auch für Projekt- und andere Manager brauchbar ist. Wir beobachten doch Tag für Tag, dass wir viele Arbeiten völlig routinemässig durchführen und auch durchführen können. Wenn etwas unsere Aufmerksamkeit in Anspruch nimmt, dann reagieren wir mit Regeln und nach Vorschriften, die wir aus Erfahrung kennen. Zum wirklichen Denken – zum Kopfzerbrechen, wie man sagt – haben wir wenig Zeit. Das meinte ich, als ich schrieb, dass wir für das Projektmanagement Skills und Regeln haben, aber zu wenig Wissen. Wir haben zu wenig Wissen, das wir durch Nachdenken selber generiert und nicht aus einem PMBOK entnommen haben.

1J. Rasmussen. Human errors: A taxonomy for describing human malfunction in industrial installation. Journal of Occupational Accidents, 1982, 4, 311-335
2James Reason. Human Error. Cambridge University Press, 1990
3James Reason. Menschliches Versagen – Psychologische Risikofaktoren und moderne Technologien. S. 97. Spektrum Akademischer Verlag. Hedielberg 1994
4W. B. Rouse. Models of human problem solving: detection, diagnosis and compensation for system failures. Vorabdruck für Proceedings of IFAC Conference on Analysis, Design and Evaluation of Man-Machine Systems. Baden-Baden 1981.

Herkömmliche Projektmanagementmehtodik ist noch nicht alles

Die miserablen Erfolgsquoten von IT-Projekten werden überall mit Erstaunen beobachtet. Martin Cobb hat an der von der Standish Group organisierten Chaos University 1995 das nach ihm benannte Paradoxon geprägt: We know why projects fail, we know how to prevent their failure – so why do they still fail?. Markus Körner vom Institut für Betriebswirtschaft der Universität St. Gallen sagte 2005: Project work is expanding – at a consistently high rate of failure. Peter Morris hielt in seiner Präsentation am IPMA World Congress 2003 in Moskau fest: Our understanding of the central core of generic project management has not changed very much (though it has a little) in the last 20 years or so1. Da muss ich ihm mehr als recht geben. Ich würde sogar sagen, dass der „central core of generic project management“ in den letzten hundert tausend Jahren nicht geändert hat. Ein Jagdprojekt war etwas diffiziles. Der Chef – sprich Projektleiter – musste wissen, wann welches Wild verfügbar ist und seine Männer sorgfältig nach ihren Skills auslesen. Er musste wissen, welche Waffen benötigt werden. Er musste wissen, in welcher Richtung man ziehen will, um innerhalb der gewünschten Zeit die benötigte Menge an Fleisch zu erjagen. Er musste etwas von Taktik verstehen. Etc., etc.

Wirklich im Kern gehen wir bei Projekten generisch immer noch gleich vor. Skeptischer bin ich bei Cobb. Wenn das stimmt, was er sagt, wäre es in der Tat ein Paradoxon. Aber die Misserfolgsfaktoren, die die Standish Group regelmässig aufzählt, sind meines Erachtens nicht die richtigen. Sie wurden von IT-Managern in einer Umfrage genannt. Möglicherweise gehen die Projekte ja schief, weil die IT-Manager auf die falschen Faktoren schauen.

Als „Project Challenged Factors“ nennen sie:
1. Lack of User Input
2. Incomplete Requirements & Specifications 12.3%
3. Changing Requirements & Specifications 11.8%

Als „Project Impaired Factors“ werden genannt:
1. Incomplete Requirements 13.1%
2. Lack of User Involvement 12.4%
3. Lack of Resources 10.6%

Ich werde auf diese Faktoren später zurück kommen. Hier nur soviel: Ich glaube nicht, dass das wirklich die ultimativen Misserfolgsfaktoren sind. Wenn Cobb diese meint, dann kann ich seiner Aussage nicht beipflichten. Allen ist klar, dass die heutigen Projektmanagementkonzepte noch nicht genügen. Alle suchen entweder nach Zusätzen oder nach einem neuen Konzept. Jeder, der meint, ein neues Konzept gefunden zu haben, zitiert gerne die eingangs erwähnten Beobachtungen von Cobb, Körner und Morris. Paul Glen, ein amerikanischer IT Consultant und Computerworld Kolumnist meinte: IT project management is part science and part art. But we, as engineers, have the bias that we can engineer solutions to fundamental human problems. Look for flexible minds, and beware of people who beliefe they know the answer2. Projektmanagement ist weder Wissenschaft noch Kunst. Projektmanagement besteht aus Skills, Regeln und Erfahrungen sowie – vor allem – aus Wissen. Skills und Regeln bekommt man bei den diversen Zertifikaten des PMI und IPMA mit. Was weitgehend noch fehlt, ist Wissen. Wissen um Komplexität und systemische Zusammenhänge. Doch davon im nächsten Beitrag. Wenn Glen mit „beware of people who beliefe they know the answer“ Leute meint, die neue Konzepte vorstellen, dann bin ich ganz auf seiner Linie. Ich habe auch keine ultimativen Lösungskonzepte sondern glaube, dass erst eine grundlegende systemische Bildung eine Verbesserung bringt. Wollen Sie die Lebensverhältnisse von Slumsbewohner verbessern? Dann schicken Sie sie in die Schule! Es existiert ein nachweislicher Zusammenhang zwischen Lebensqualität und Schulbildung. Genau so existiert meines Erachtens ein Zusammenhang zwischen Projekterfolg und systemischer Bildung der Projektmanager. Ganz Grundsätzlich bin ich der Meinung, dass es zur Führung unserer Institutionen – Projekte, Unternehmen, politische Institutionen, etc. – allmählich Zeit wird, dass unsere Bildungsinstitute zu einem völlig neuen Curriculum übergehen müssen. Uns fehlen eine ganz beträchtliche Menge Wissen, um die erhöhte Komplexität zu meistern.

1Stephen Rietiker. Projektbewusstes Management. spm Frühjahrstagung. Zürich 2007. Ich glaube, Rietiker schlägt in der Präsentation genau den richtigen Weg ein. Nur habe ich den Eindruck, dass er nicht richtig aufbricht. Bei jeder Folie denke ich: „Wann kommt er denn jetzt zum Punkt?“ Und dann ist die Präsentation plötzlich fertig.
2Gary Anthes. Projects Get More Troublesome. Computerworld, December 31, 2007.

Verzögerungen erster und höherer Ordnung

Es wird Zeit, dass wir uns den Aufgaben aus dem Beitrag Verzögerungen als Dimension der Projektkomplexität vom 24. Juli zuwenden. Zunächst zu den Tauben. Die Tauben stehen dicht, Leib an Leib, und können sich nicht gross bewegen. Jede Taube hat zuerst fast beliebig viele Körner unter sich und pickt drauf los, was das Zeug hält, vielleicht zwei Körner pro Sekunde. Dann werden es weniger und die Taube muss immer mehr den Hals verrenken, um an ein weiteres Korn zu gelangen. Das braucht Zeit. Vielleicht erreicht sie nur noch ein Korn pro Sekunde. Dann wird’s eng. Es hat noch Körner, aber sie sind in toten Ecken, wo die Tauben in dieser Position nicht hin kommen. Somit muss sich die gesamte Taubenschar verändern, es kommt zu Aggressionen, was wiederum Zeit weg nimmt. So ergattert jede Taube durchschnittlich noch ein Korn pro 10 Sekunden. Schliesslich entdecken ein paar Tiere, dass auf dem Rücken anderer noch welche Körner liegen und picken sie weg. Wenn Sie diese Errungenschaften auf alle Tauben verrechnen, kommen Sie auf einen Schnitt von möglicherweise 1 Korn pro Minute. Und schlussendlich findet eine Taube nach einem Monat noch ein verlorenes Korn in einem Zwischenraum zweier Pflastersteine. Die Abnahme der Körner, die am Boden liegen, hängt also davon ab, wieviele Körner noch am Boden vorhanden sind und von der durchschnittlichen Pickzeit, der Zeit, die eine Taube benötigt, um ein Korn runter zu schlucken. Wir fassen die Körner, die am Boden liegen in einem viereckigen Behälter zusammen und stellen uns vor, dass die Körner die die Tauben picken durch eine Röhre aus dem Behälter fliessen. Die Abflussgeschwindigkeit ist proportional zum Inhalt des Behälters, so:

Sie können dann mit Hilfe einer Excel-Tabelle ausrechnen, wie die Körner abnehmen, nach der Abhängigkeit Körner im Behälter zur Zeit t = Körner im Behälter zur Zeit (t-1) / Pickzeit. Wählen Sie die Zeitschritte möglichst klein. Wie Sie dann sehen, nehmen die Körner exponentiell ab. Wenn Sie passende Grössen wählen, erhalten Sie ein solches Diagramm:

Das nennt man eine Verzögerung erster Ordnung. Es interessiert uns nicht, wieviele Körner nach zwei oder fünf Minuten genau noch vorhanden sind, sondern uns interessiert bloss das qualitative Verhalten einer Verzögerung erster Ordnung.

Die Aufgabe mit den Briefen kann man nun auf die Taubenaufgabe zurückführen. Man beachte aber, dass es von der Aufgabe am lokalen Postschalter bis zur Auslieferung in den USA mehrere Bestände gibt. Zunächst kommen die Briefe mit Tausenden anderen im lokalen Postamt in einen grossen Behälter. Dieser leert sich dann wie der Behälter der Körner für die Tauben. Dann werden die Briefe in ein nächst höheres Porstamt transportiert. Der dortige Behälter füllt sich zuerst auf und leert sich danach wieder wie bei den Taubenkörner, usw. Bis zur Auslieferung in den USA gelangen die Briefe in gut und gerne ein Dutzend Behälter oder mehr. Auch die Behälter in den Transportmitteln können Sie einbeziehen. Dort liegen die Briefe ja auch längere Zeit, wie in den Postämter. Wenn Sie mehrere Behälter auf diese Weise in eine Reihe schalten und annehmen, die Post spezifiziere eine Auslieferungszeit von 10 Tagen und diese Verzögerungszeit auf alle Zwischenbehälter gleichmässig aufteilen, dann erhalten Sie ein solches Diagramm.

Das ist eine Verzögerung höherer Ordnung (hier nahmen wir 20 Zwischenbehälter an und erhielten eine Verzögerung zwanzigster Ordnung). Wie Sie sehen, werden die ersten Briefe bereits nach vier oder fünf Tagen ausgeliefert. Am zehnten Tag werden am meisten Briefe ausgeliefert, nämlich fast 200. Nach 18 Tagen sollten weitgehend alle Briefe den Adressaten erreicht haben, aber vielleicht findet sich nach zwanzig Jahren ja noch ein Brief in einem Liftschacht und wird pflichtbewusst abgeliefert. Die Kurve erreicht nie die Nulllinie. Natürlich reflektieren solche Modelle den Idealfall und nicht die Realität. Der realistische Verlauf des Briefbeispiels mag etwa so aussieht wie die rote Kurve in folgendem Diagramm.

Aber Unternehmens- oder Projketmanager, die in (blauen) Modellen denken, sind erfolgreicher, als solche, die nichts über Verzögerungen wissen. Der genaue Verlauf der roten Kurve ist gar nicht so relevant. Wichtig ist, dass ein Projektleiter Verzögerungen in die Planung einbezieht und weiss, wie sich eine Verzögerung höherer von einer solchen erster Ordnung unterscheiden. Dieses Wissen ist die Basis einer jeden sauberen Planung.

Weitere Lektüre:

John Sterman, Brad Morrison. Structure and Behaviours of Delays.

Stephanie Albin. Exponential Material Delays.

Investieren Sie in Expertenwissen!

Ich möchte nochmals auf die gestrige Geschichte zurück kommen, weil sie in Projekten wichtig ist. Es handelt sich nämlich auch wieder um so eine Mode, die alle Beteiligten – sehr zu ihrem Nachteil – gemeinsam generieren. Jeder meint, der andere sei schuld, aber tatsächlich hat jeder zu gleichen Teilen Schuld an der Misere. Es ist wie im Bierspiel, wo alle dem jeweils anderen oder externen Faktoren die Schuld geben. Hier meint der Kunde, der Lieferant schlampe, ist aber nicht bereit, mehr zu bezahlen. Das Projektmanagement des Herstellers nervt sich über den lausigen Support des Competence Centers (Entwicklung und/oder Produktemanagement), ist aber nicht bereit, das Projekt zu stoppen, wenn nicht mehr Expertenwissen zur Verfügung steht. Das Competence Center klagt darüber, dass das Management zuwenig Ressourcen bereit stellt, ist aber nicht bereit, den Support von zusätzlichen Projekten abzusagen. Das Management schliesslich schimpft auf die Projektleitung, die das Projekt dermassen schlecht abwickelt, dass die Kunden Penaltyforderungen stellen oder gar davon laufen, ist aber nicht bereit, in zusätzliche Ressourcen zu investieren.

Diese Situation wird klarer, wenn wir sie in einem Diagramm darstellen. Sie können das Diagramm vergrössern, indem Sie darauf klicken.

Starten Sie im Kreis B1 bei der Anzahl Migrations- und Integrationsprojekten, die ein Konzern weltweit durchführt. Je mehr das sind, desto mehr kommt der Produktmanager unter Druck, desto weniger Wissen ist also in den einzelnen Projekten verfügbar. Das Projekt kommt in’s Stocken, weil die offenen Fragen nicht schnell genug beantwortet werden können. Der Kunde ist unzufrieden. Die Marktnachfrage nach Produkten dieses Konzerns sinkt, die Anzahl Projekte geht zurück (und damit auch der Erfolg dieses Konzerns). Hier treffen wir wieder eine alte Bekannte, nämlich die Verzögerung. Zwischen der Unzufriedenheit einzelner Kunden und dem Rückgang des Erfolgs ist eine grosse zeitliche Lücke. Wenn das Management den kriechenden Geschäftsgang jedoch wahrnimmt, ist es meistens schon zu spät, um Gegenmassnahmen zu treffen.

Gehen Sie jetzt in den Kreis B2: Jeder Kunde hat eine gewisse Schwelle, ab der er ernstlich böse wird. Dann muss der Hersteller Penalties bezahlen. Spätestens dann stellt das Management fest, dass eigentlich in zusätzliche Expertise investiert werden müsste. Tut es dies dann auch, dann kann das verfügbare Wissen erhöht werden und die Projekte laufen weit erfolgreicher ab. Das Erreichen der angestrebten Expertenkapazität verzögert sich wieder einmal beträchtlich gegenüber dem Zeitpunkt der Investition. Das ist der Grund, weshalb solche Managementinterventionen meist zu spät greifen. Das Management übersieht die eingebauten Verzögerungen.

Der Kreis R1 generiert einfach neue Projekte. Indem der Konzern interessante Produkte anbietet, kann er sie in Migrations- und Integrationsprojekten ausrollen. Je mehr er das tut, desto bekannter werden die Produkte und desto grösser die Nachfrage in Form von RFQs.

Dieses Muster heisst Growth and Underinvestment. Peter Senge hat es 1990 in seinem Buch Die Fünfte Disziplin zusammen mit neun anderen sogenannten Archetypen beschrieben1.
In Growth and Underinvestment nimmt die Variable, an derer Stelle die Anzahl Migrations- und Integrationsprojekte steht, zunächst zu, flacht dann ab und kollabiert danach mehr oder weniger schnell. Dieses Schicksal ereilt jeden Bestand, der anfangs erfreulich wächst, wenn nicht ganz von Anfang an und dann immer parallel zum Wachstum in Kapazitäten investiert wird. Das ist der einzige Hebel, den Sie in diesen Zusammenhängen in der Hand haben. Nutzen Sie ihn!

1Peter Senge. Die Fünfte Disziplin – Kunst und Praxis der lebenden Organisation. Klett-Cotta. Stuttgart 1997

Staus im Produktemanagement

Beim gestrigen Lunch machte mich mein Gesprächspartner auf eine Tatsache aufmerksam, die für Migrations- und Integrationsprojekte (MIP) typisch ist. Die zum Einsatz gelangenden Produkte sollten zwar möglichst neu sein, ohne jedoch die Mängel von Kinderkrankheiten aufzuweisen. Meistens gibt es nur eine oder zwei Personen, die das Produkt wirklich gut kennen. Nicht einmal die Entwickler kennen das Produkt, da sie im Allgemeinen nur an einem bestimmten Modul gearbeitet haben. Der Architekt und der Entwicklungschef kennen das Produkt bloss konzeptionell, aber haben auch keine Erfahrung, wie sich das Produkt im Betrieb verhält. So gibt es wohl nur den Produktmanager innerhalb der Entwicklung, der sich mit dem Produkt in praxi wirklich auskennt. Die Projektleiter, die das Produkt bei den Kunden in aller Welt ausrollen müssen, haben oft keine Produktkenntnisse, und die Mitarbeiter der nationalen Konzerngesellschaften des Lieferanten noch viel weniger.

Figur: Rot sind Einheiten, die zentral irgendwo auf der Welt in einem Competence Center arbeiten. Blau sind lokale Einheiten, die in allen nationalen Konzerngesellschaften anzutreffen sind. Der Ring „Projektmanagement / Produktion“ kann sowohl zentral als auch lokal agieren. Aufgabe des Produktmanagement ist es, das Wissen in konzentrischen Wellen nach Aussen zu befördern.

So muss denn nun der zentrale Produktmanager zunächst seine Kollegen von den Projekten und der Trainingsabteilung schulen. Das kann er aber nicht fulltime tun, denn er muss ja auch immer das Produkt im Auge behalten. Wenn z.B. ein Trainer der Schulungsabteilung eine Frage der Kursteilnehmer nicht beantworten kann, leitete er sie an den Produktmanager weiter, denn auch der Trainer kennt das Produkt bloss theoretisch. Später, wenn sich das Produkt in einer bestimmten Kundenumgebung eigensinnig benimmt, werden die lokalen Ressourcen und der zentrale Projektmanager, versuchen, die Fehler zu reproduzieren und zu dokumentieren. Nur der zentrale Produktmanager kann abschliessend sagen, ob es sich um einen Konfigurationsfehler oder um einen Produktfehler handelt. Es kommt zu Staus und der Propagationsprozess der Produktkenntnisse zieht sich schleppend dahin. Was Sie in meinem gestrigen Artikel über Verzögerungen gelesen haben, lässt hier grüssen. Wir werden darauf zurück kommen.

Was macht man mit Bottlenecks? Gemäss Eliyahu M. Goldratt1 versucht man, die Engpassressource auszubauen. Bis es soweit ist, muss sich alles andere nach dem Engpass richten. Das bedeutet, dass andere Einheiten Wartezeiten haben werden. Auf keinen Fall dürfen die anderen Einheiten weiter arbeiten, denn das baut nur Bestände auf. In MI-Projekten sind das lange Issues- und Aktionslisten (siehe Komplexität im Projektmanagement). Das Projekt zieht sich schleppend dahin, bis das Produkt-Know-How genügend weit zum Kunden hin propagiert ist, dass sich das Projekt ohne zentrale Experten komfortabel durchführen lässt. Das kann aber dauern. Umgekehrt bedeutet die Ausweitung der Engpassressource zwei oder gar drei Produktmanager parallel laufen lassen. Bloss ist keine Kunde bereit, das zu zahlen.

Er wird aber auch nicht bereit sein, das Projekt zu verzögern. Im Gegenteil wird er mit Penalties drohen, das ist vorprogrammiert. Hier muss die nationale Konzerngesellschaft handeln, bevor ein entsprechendes Projekt kommt. Die lokalen Produktmanager müssen rechtzeitig aufgebaut werden, andernfalls baden es die lokalen Projektressourcen aus und das Unternehmen wird einen Imageverlust erleiden.

1Eliyahu M. Goldratt, Jeff Cox. Das Ziel – Höchstleistungen in der Fertigung. McGraw-Hill Book Company, Maidenhead 1990
und
Eliyahu M. Goldratt. Die Kritische Kette – Das neue Konzept im Projektmanagement. Campus Verlag. Frankfurt a. Main 2002

Haben Sie sich auch schon mal überschätzt?

Heute morgen hat mir meine Partnerin gesagt, dass ich bei einem Unterfangen oder Projekt oft nur Hindernisse sähe und ein Misepeter sei, was eigentlich erstaunlich ist, denn Frauen bewerten im Allgemeinen hypothesenkonträre Informationen höher und können besser mit der entsprechenden Unsicherheit umgehen als Männer1. Beim Lunch machte mich dann ein Freund darauf aufmerksam, dass die Leute meist gar nicht wissen wollen, was in einem Projekt alles schief gehen könnte. Das hat mit dem sogenannten Overconfidence Bias zu tun, dem Hang zu übermässigem Vertrauen. Forscher haben herausgefunden, dass man beim Planen zu sehr auf die Korrektheit des eigenen Wissens vertraut2. Man glaubt, der geplanten oder eingeschlagenen Weg werde erfolgreich sein und schenkt widersprüchlichen Anzeichen einfach keine Bedeutung. Und mit steigendem Komplexitätsgrad der zu lösenden Aufgabe steigt das Ausmass an Selbstüberschätzung3. Was glauben Sie, welche der beiden pakistanischen Städte hat mehr Einwohner, Islamabad oder Hyderabad? Wenn Sie sich für eine Antwort entschieden haben, schätzen Sie bitte, wie sicher Sie sind, die richtige Antwort gegeben zu haben. Was immer Sie für eine Wahrscheinlichkeit schätzen, richtig gelegen zu haben: vermutlich ist sie zu hoch, unabhängig davon, ob Ihre Antwort richtig war oder nicht. Islamabad hat 900’000, Hyderabad 1,17 Mio Einwohner. Den Hang zu übermässigem Vertrauen in ihre Diagnosen und Schätzungen finden Sie nicht nur bei Projekt- und anderen Managern, sondern auch bei Ärzten, Anwälten, Piloten, Bankern, etc.

Dazu kommt, dass ein Plan Ordnung mit sich bringt, wodurch er der Zerstreuung von Besorgnis dient. Wer will sich denn unnötig Sorgen machen? Zwar kostet eine solche Bewertungsverzerrung viel Geld und auch schon mal Menschenleben, aber andererseits würde man ja das Gesicht verlieren. Ein Manager, der sich Sorgen macht oder der Mitarbeiter beschäftigt, die sich überlegen, was für Fehler passieren könnten, ist ein schlechter Manager, meint man. Aber sogenannte High Reliability Organisations, also Unternehmen, die ein Hochrisikogeschäft fahren, konzentrieren sich zumindest seit Tschernobyl immer mehr auf das Unerwartete und sind sehr sensibel für mögliche Fehler4. Ich glaube, dass es heute angesichts der hohen Komplexität nicht mehr reicht, ein Unternehmen oder Projekt einfach nach Best Practices zu führen. Es gehört mehr dazu. Warum die Leute vor diesem Mehr Angst haben, ist mir schleierhaft. Es ist nämlich weder schmerzhaft noch sonst unangenehm.

Wenn man sich zu Beginn eines Projekts ehrlich überlegt, was alles schief gehen könnte, schärft dies die Achtsamkeit. In Entscheidungssituationen können wir bewusst Gründe suchen, die gegen die Hypothese sprechen. Dann stossen wir plötzlich auf Informationen, die der ersten Annahme widersprechen und unter den Tisch gewischt wurden. Das bewahrt uns vielleicht vor voreiligen und törichten Entscheiden, die uns hätten das Gesicht kosten können. Am Schluss eines Projekts machen wir eine wirklich seriöse Lessons-Learned-Sitzung, indem wir fragen, wie das Projekt gelaufen wäre, wenn das und das (nicht) eingetreten wäre und wir (nicht) so und so reagiert hätten.

Gegenüber der totalen Projektlaufzeit nimmt all das nicht viel Zeit in Anspruch und vermittelt uns das gute Gefühl der Achtsamkeit. Das hat nichts mit der Kontrollillusion zu tun, der sich vor allem Planer nach dem Prinzip „Planen statt Handeln“ gerne hingeben.

1Janne Chung, Gary S. Monroe. Gender Differences in Information Processing: An Empirical Test of the Hypothesis-Confirming Strategy in an Audit Context. Accounting and Finance 1998, 256-279.
2Koriat, A., Lichtenstein, S., & Fischhoff, B. Reasons for confidence. Journal of Experimental Psychology. Human Learning and Memory, 1980, 6, 107-118
3Hanno Beck. Die Logik des Irrtums – Wie uns das Gehirn täglich ein Schnippchen schlägt. Verlag Neue Zürcher Zeitung, Zürich 2008
4Karl E. Weick, Kathleen M. Sutcliffe. Das Unerwartete manage – wie Unternehmen aus Extremsituationen lernen. Klett-Cotta. Stuttgart 2003

Denken, fühlen, leben