Archiv der Kategorie: Denkmuster

An den Schalthebeln des Projektmanagements

Lassen sich Turbulenzen in Migrations- und Intergrationsprojekten (MIP) über die im Eintrag Wann sind Projekte instabil? vom 3. August 2008 genannten Faktoren tatsächlich mindern? Natürlich nicht, denn der Projektmanager kann keinen der Faktoren beeinflusst. Es sind keine Hebel des Projektleiters, sondern reine Randbedingungen des Projekts. Sie beschreiben das Projektumfeld, das der Projektleiter hinzunehmen und in die Planung einzubeziehen hat. Achten Sie bei der Planung Ihrer Projekte auf solche Randbedingungen? Fiel Ihre Planung bisher tatsächlich anders aus, wenn im Projekt z.B. Personen aus drei verschiedenen Nationen mitarbeiteten, als wenn alle demselben Sprachraum zugehören, in welchem das Projekt durchgeführt wird?

Was sind Hebel?

Hebel sind Projektparameter, die Sie als Projektmanager aktiv beeinflussen können. Zwar nicht immer mit Erfolg, das gebe ich zu, aber Sie können in jedem Fall Einfluss nehmen. Der Faktor von Nittbaur und Ernst, auf den ich im Nachtrag noch aufmerksam machte, ist ein solcher Hebel. Es liegt im Ermessen des Projektleiters, ob er ein Kickoff machen will und wen er dazu einlädt. Selbstverständlich können Sie darüber diskutieren, ob viele Teilnehmer förderlich oder kontraproduktiv sind. Selbstverständlich könnten Sie auch von allen Eingeladenen Absagen erhalten, so dass das Kickoff in’s Wasser fällt. Aber Sie können etwas tun.

Welche Resultate soll das Projekt ergeben?

Schreiben Sie einmal auf, welche Resultate oder Zielsetzungen Sie in Ihrem Projekt erreichen müssen und wie der aktuelle Stand eines jeden Resultats ist. Klar, da sind einmal die drei Resultate des magischen Dreiecks, oft auch als magisches Viereck dargestellt, nämlich

  • Termintreue
  • Kostentreue
  • Optimale Qualität
  • Ablieferung und Installation der geforderten Inhalte

Zusätzliche Resultate können sein:

  • Kundenzufriedenheit
  • Vertrauensbildung beim Kunden in das Lieferunternehmen und seine Produkte
  • Befriedigung der Interessen aller Stakeholders

Welche Hebel haben Sie?

Und jetzt machen Sie eine Liste aller Hebel, die Ihnen zur Verfügung stehen, also all derjenigen Faktoren, die Sie als Projektmanager direkt beeinflussen und regeln können. Schreiben Sie auch dazu, welche Ist- und welche Soll-Einstellung die einzelnen Hebel gerade haben. Ich weiss, das ist gar nicht so einfach, wie man zunächst glaubt. Aber überlegen Sie, welche Mitigations Sie bei erkannten Risiken angeben. Dort finden Sie Ihre Hebel. Sie werden schnell einsehen, dass es in MIP gar nicht so viele Faktoren gibt, auf die Sie wesentlichen Einfluss nehmen können. Diese Tatsache lässt alle gut gemeinten Ratschläge für ein aktives Projektmanagement hinter sich. Die Liste kann für Entwicklungsprojekte lang sein, aber in MIP gibt es weniger Hebel. Beispiele für Hebel können sein:

  • Durchführungsentscheid Kickoffmeeting
  • Teilnehmerzahl Kickoffmeeting
  • Aktualität des Projektplans
  • Detailreichtum des Projektplans
  • Zeitpunkt für das Vorlegen eines Projektplans
  • Häufigkeit von Projektmeetings
  • Teilnehmer an den Meetings
  • Zeitpunkt und Inhalt von Eskalationen
  • Insistierungsgrad bezgl. Ressourcen (wer am lautesten bellt, erhält den grössten Knochen)
  • Beantwortungspolitik von Change Requests

etc. etc. (Schreiben Sie weitere in Kommentare zu diesem Eintrag!)
Was fällt Ihnen auf, wenn Sie die beiden Listen vergleichen? Kein Resultat erscheint auf der Liste der Hebel und kein Hebel ist ein Resultat. Schlimmer noch: Die Hebel sind nur indirekt und oft über mehrere Ecken mit den Resultaten verbunden1. Mit anderen Worten: Sie können die Ereignisse überhaupt nicht direkt beeinflussen. Wenn Sie 10 Projektmeetings machen, kann das die Kundenzufriedenheit vielleicht fördern, aber es könnte ihr auch abträglich sein.

Wie finden Sie Hebel?

Sie erinnern sich an das Grundmodell von Migrations- und Integrationsprojekten? Siehe Komplexität im Projektmanagement. Dort hatten wir den Feedbackloop

anatomie_mip

Tasks to do liegt in Form einer Issuelist vor. Sie beeinflusst direkt die Termintreue, während von Work in Progress ein direkter Pfeil zu den totalen Projektkosten führt. Welche Hebel Sie für das Wissen haben, zeigte ich in Investieren Sie in Expertenwissen. Jetzt wollen wir dasselbe Schema des Growth and Underinvestment Archetypus anwenden, um einen Hebel für die Issuelist zu finden. Ist das Projekt längst überfällig, mag der Kunde toleranter gegenüber kosmetischer Mängel sein. Er ist qualitätstoleranter, was sich derart auswirkt, dass er nicht mehr gleich für jeden Schönheitsfehler des Produkts oder des Services einen Issue auf die Liste setzt. Das heisst, je grösser die Qualitätstoleranz, desto kleiner die Issuelist.
Ist der Endtermin des Projekts längst überschritten, kann das der Projektmanager des Lieferanten eskalieren. Dies ist sein Hebel! Dadurch erreicht er vielleicht, dass das Management die Notwendigkeit wahrnimmt, mehr Ressourcen aufzubauen, so dass das Projekt schliesslich doch noch fertig gestellt werden kann. Das Gesetz von Brooks gilt bei MIP nicht zwingend (Brooks‘ Gesetz: „Adding manpower to a late software project makes it later“2). Unsere Feedbacks sehen nun so aus:

termintreue

Der Kreis R ist schlecht für die Termintreue. Sie würde zwar durch den Kreis B1 eingedämmt, aber leider erst, nachdem das Projekt bereits aus dem Ruder gelaufen ist. Mit dem Kreis B2 hingegen, könnte der Termin gehalten werden, wenn er von Anfang an greifen würde. Allerdings besteht eine beträchtliche Verzögerung zwischen der Allokation von Ressourcen und ihren effektiven Auswirkungen auf die terminlichen Belangen. Der einzige Hebel in diesem Zusammenhang ist die Eskalation. Das zeigt, dass der Projektmanager mit der Eskalation nicht zu lange warten sollte. Meistens zögern Projektmanager, zu eskalieren oder denken, dass sie den Dingen noch ein wenig zuschauen wollen. Das ist ein Fehler.

1Denis Sherwood. Den Wald vor lauter Bäumen sehen – Reduktion von Komplexität – Anleitung zum systemischen Denken im Management. Wiley VCH Verlag. Weinheim 2003.
(Leider spricht auch Sherwood von Komplexitätsreduktion. Aber ich glaube, das ist bloss eine Verkaufstrick. Er soll dem potentiellen Käufer, der nicht weiss, was Komplexität ist, ein beruhigendes Gefühl geben)
2Frederick P. Brooks. Vom Mythos des Mann-Monats : Essays über Software-Engineering. Mitp-Verlag. Bonn 2003

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.

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

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.

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

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

Was für ein Aufmerksamkeitstyp sind Sie?

Gestern erhielt ich ein Mail mit folgendem Rätsel:

There is a very, very tall coconut tree and there are 4 animlas, a LionLion, a ChimpanzeeMonkey, a GiraffeGiraffe, and a SquirrelSquirrel, who pass by. They decide to compete to seewho is the fastest to get a banana off the tree. Who do you guess will win? Your answer will reflect your personality. So think carefully…Try and answer within 30 seconds.

Got your answer? Now scroll down to see the analysis.

If your answer is:
Lion = you’re dull.
Chimpanzee = you’re a moron.
Giraffe = you’re a complete idiot.
Squirrel = you’re just hopelessly stupid.
A COCONUT TREE DOESN’T HAVE BANANAS. Obviously you’re stressed and overworked. You should take some time off and relax! Try again next year.

Interessant sind die Fälle, in denen die Versuchspersonen die Voraussetzung “Kokosnussbaum” und das Ziel “Banane pflücken” nicht verknüpfen, sondern sich tatsächlich an die Lösung der Aufgabe machen. Ich glaube nicht, dass diese Personen überarbeitet und gestresst sind. Sie denken einfach anders.
Zunächst fällt auf, dass die Begriffe Coconut und Banana so weit wie möglich auseinander liegen. Dazwischen befindet sich diese komische Aufzählung verdoppelter Tiernamen. Wer sich dadurch ablenken lässt, hat schon verloren. Es handelt sich hier eindeutig um einen Aufmerksamkeitsfehler, den James Reason1 Schnitzer (engl. Lapse) nennt.

Das heisst aber nicht, dass es sich um eine Aufmerksamkeitsschwäche handelt. Im Gegenteil könnte es sein, dass die Versuchsperson sehr zielgerichtet auf die Aufgabe los steuert. Sie programmiert ihre Aufmerksamkeit auf die Erkennung der eigentlichen Aufgabe, scant dann den Text ziemlich automatisiert durch und lässt sich „wecken“, sobald die Aufgabenstellung erreicht ist. Der Begriff coconut tree interessiert die Versuchsperson nicht im Geringsten, weil sie zuerst wissen möchte, worum es eigentlich geht. Ein anonymer Autor schreibt in einem Aufsatz über „Aufmerksamkeit“2: Nur die Inhalte, die von einem Individuum mit Aufmerksamkeit besetzt werden, rücken ins Bewusstsein. Das nennt der Autor selektive Aufmerksamkeit. Er erklärt, dass Aufmerksamkeit ein kompetitives System ist, eine Vielfalt von Programmen, die miteinander im Wettbewerb stehen. Das eine Programm will die Aufmerksamkeit vielleicht auf Begriffe wie Coconut oder Banana legen, das andere auf die auffälligen Tiernamen und das dritte auf die effektive Zielsetzung.

Bei dem einen Typ von Versuchspersonen gewinnt das erste Programm, bei einem anderen Typ das letzte. Versuchspersonen vom ersten Typ sind eher integrative Menschen, die alles aufsammeln, was wichtig sein könnte, während diejenigen vom zweiten Typ schnurstracks auf das Ziel los jagen ohne rechts und links zu schauen. Vielleicht sind die ersteren auch die geselligeren und stellen im Gespräch zuerst den Rapport zum Gegenüber her, während die anderen sofort zum Thema kommen. Aber das sind natürlich nur Spekulationen.

Auf alle Fälle können Projektmanager viel aus der Art und Weise lernen, wie sie an die Aufgabe heran gehen. Steuern sie sofort auf das Projektziel los oder „hören“ sie zuerst in die Kundenanforderungen hinein auf die Gefahr hin, das Ziel aus den Augen zu verlieren? Vertiefen sie sich in Spezifikationsdetails (doppelte Tiernamen) und laufen dadurch die Gefahr, den Blick auf das Wesentlichen zu trüben oder gewichten sie alles gleichermassen, können dafür aber nur schwer die Ziele priorisieren?

1 James Reason. Human Error. Cambridge University Press 1990
2 http://paedpsych.jku.at/cicero/GEDAECHTNISGEHIRN/Aufmerksamkeit.pdf