Archiv der Kategorie: Komplexität

Ammenmärchen

Komplexität kann und soll man weder reduzieren, noch in die Umwelt auslagern, wie ich auch schon gehört habe. Das Gerede von der Reduktion der Komplexität ist ein Ammenmärchen. Komplexität haben wir als hochstehende raum-zeitliche Informationsstrukturen kennen gelernt, die unter vielen „Fluktuations- und Instabilitätsschmerzen“ geboren wurden und unter ständiger Aufbietung von Ressourcen genährt werden. Wer nun diese Strukturen „reduzieren“ will, ist in höchstem Masse destruktiv. Unsere ganze Welt – die Sterne, die Pflanzen, die Tiere, unser Gehirn – das sind alles hochkomplexe Strukturen. Will eine Unternehmung bestehen, muss sie einen immer höheren Komplexitätslevel erreichen. Alle organisatorischen Institutionen einer Unternehmung, die der Wettbewerbsfähigkeit dienen wie z.B. IT-Integration, Qualitätsmanagement, Supply Chains, etc., sind komplexe Strukturen. Wie kann man nur auf die Idee kommen, diese reduzieren zu wollen? Der Titel eines Buches lautet „Management von Komplexität – Ein integrierter, systemtheoretischer Ansatz zur Komplexitätsreduktion“. Das Buch habe ich zwar gekauft, weil so viele Widersprüche in einem einzigen Titel natürlich neugierig machen. Darüber hinaus ist es nur peinlich. Für mich ist die Komplexität die Seele eines lebenden Systems. Wenn jemand von Komplexitätsreduktion spricht, zucke ich buchstäblich zusammen, weil es mir weh tut.

Und wie steht es mit dem Auslagern von Komplexität? Was kann damit gemeint sein? Warum soll ich meine nützlichen Strukturen „auslagern“? Ich glaube, wer so spricht, der schlägt den Sack, wenn er eigentlich den Esel meint. Nicht die Komplexität soll ausgelagert werden, sondern etwas, das sich Entropie nennt. Das ist eine sehr unanschauliche Grösse, die Chaos und Unordnung misst. Sie ist in den fluktuativen und instabilen Phasen, also gerade während Projekten, am grössten. Systeme, die sich verändern, erzeugen Entropie. Können sie diese in die Umgebung exportieren, dann gelingt es ihnen, einen höheren Komplexitätsgrad zu erreichen. Wir können daraus eine Voraussetzung für Systeme ableiten, die wettbewerbsfähige Strukturen bilden können: sie müssen offen sein, um negative Entropie aus der Umgebung aufnehmen und Entropie an die Umgebung abgeben zu können. Unternehmen, die nicht offen sind – die z.B. ihre Produkte nach proprietären, geheim gehaltenen Standards designed haben und wenig kompatibel mit der Industrienorm sind – haben wenig Überlebenschancen. Wie sieht der Entropieexport in der Praxis aus? Wie wir gesehen haben, werden komplexe Systeme ständig von Energie-, Material- und/oder Informationsfluss durchströmt. Diese Flüsse erzeugen Drücke und Kräfte, die die Systemteile veranlassen, sich zu ordnen. Eine globale Ordnung nannten wir Mode, welche wiederum die Systemteile versklavt („Eschers Hände“). Damit die Mode aufrecht erhalten bleibt, muss das System laufend Energie, Material und Informationen dissipieren, also verarbeiten und von hochwertig zu niederwertig umwandeln1. Aus höherwertiger Energie wird Wärme, aus teurem Material wird Abfall und aus erstmaliger Information wird bestätigte Information. Wir erinnern uns an das Beispiel „Stadt“ eines komplexen Systems. Täglich werden z.B. hunderttausende von Kilowatt elektrischen Stroms in die Stadt herein gepumpt und verlassen sie als Wärme wieder, die in den Himmel hinauf steigt. Täglich kommen hunderte von Tonnen Nahrung herein und verlassen die Stadt in verdautem Zustand wieder. Täglich konsumieren hunderttausende von Leuten in Zeitungen und Fernseher News, die morgen schon wieder veraltet sind. Wenn sie morgen jemandem etwas erzählen, das heute passiert ist, wird er sofort die Aufmerksamkeit abziehen und gähnend bemerken, dass er das schon wisse. Das ist Entropieexport in praxi. Je fluktuativer und chaotischer das System während der instabilen Phase ist, desto mehr Entropie wird erzeugt und desto wertvoller kann die entstehende Struktur dann vielleicht sein. „Wertvoll“ ist hier so gemeint, dass die entstehende Struktur das Ziel der Veränderung trifft. Jantsch schreibt: Für den schöpferischen Aufbau einer neuen Struktur werden keine Kosten gescheut…Nur ein auf Sicherheit ausgehendes etabliertes System muss haushalten2.
Wenn Sie die Unbestimmtheit meinen, die es (während eines Projekts) zu reduzieren gilt, dann kann das insofern geschehen, als dass Sie dafür sorgen, dass immer sehr viel neue Information ankommt. Wir hatten das bereits im Beitrag Investieren Sie in Expertenwissen gesehen. Neues Wissen muss von Anfang an im Überfluss vorhanden sein.
Ein anderes oft gehörtes Ammenmärchen im Zusammenhang mit Komplexität ist die Behauptung, Gleichgewicht sei etwas an sich gutes, und es sei zu vermeiden, dass Systeme aus dem Gleichgewicht geraten. Das Gegenteil ist wahr. Gleichgewicht bedeutet Stillstand und Tod. Da geht nichts mehr. Nur was im Ungleichgewicht ist, kann sich verändern, kann sich verbessern und kann wachsen. Nur das Ungleichgewicht liefert die Spannung, die es braucht, um etwas in Gang zu setzen und zu halten. Denken Sie an eine Uhrfeder. Sobald diese im Gleichgewicht ist, steht die Uhr still. Die relative Stabilität zwischen den instabilen Phasen ist nicht zu verwechseln mit Gleichgewicht. Ein gesunder menschlicher Körper ist überhaupt nicht im Gleichgewicht, obwohl er relativ stabil ist. Ein gesundes Biotop ist ebenfalls weit weg vom Gleichgewicht. Nur so kann das Wasser sauber bleiben. Wenn es „kippt“, sagen die Leute, dass es aus dem Gleichgewicht geraten sei. In Tat und Wahrheit bewegt es sich dann zum Gleichgewicht hin. In Phasen relativer Stabilität ist ein System in einer Art dynamischen Gleichgewichts. Stellen Sie sich vor, auf einer Tennisanlage wären auf beiden Seiten 1000 Bälle am Boden und die beiden Spieler werfen ständig Bälle auf die andere Seite. Wenn beide gleich schnell werfen, dann befindet sich das System in einem dynamischen Gleichgewicht. Mal hat’s auf der einen Seite 1005 Bälle, mal 993, mal 1007, mal 998, etc. Möglicherweise meint man das dynamische Gleichgewicht, das eigentlich gar keines ist, wenn man von „Gleichgewicht“ spricht.

1Die hier dargestellten Zusammenhänge der Entwicklung von komplexen Systemen können Sie in einschlägiger Literatur zum Thema nachlesen, z.B. bei
Hermann Haken. Synergetik. Springer Verlag, 1982
Hermann Haken. Erfolgsgeheimnisse der Natur. Deutsche Verlags-Anstalt, 1981
Eine etwas neuere und ausgezeichnete Darstellung findet sich in
Christian Lapp. Darwinistische Evolutionstheorie und Theorie der Selbstorganisation von Materie: Widersprüchliche Zugänge zum Naturverständnis? Diplomarbeit an der Karl-Franzens Universität. Graz 2001

2Erich Jantsch. Die Selbstorganisation des Universums. Vom Urknall zum menschlichen Geist. dtv. München 1982

Wann sind Projekte instabil?

Aber was macht denn nun wirklich das aus, was wir gemeinhin, aber fälschlicherweise mit Projektkomplexität bezeichnen, also das Chaotische, das Fluktuative? Wie wir gesehen haben, beginnt das System aus dem Ruder zu laufen, wenn sich die Kontrollparameter ändern. Mit unseren Managementmassnahmen, halten wir das System „über Wasser“ bis es eine neue Mode ausgebildet hat und einigermassen stabil wird, also in ruhigere Gewässer treibt, um bei dem Bild zu bleiben. Die Frage ist somit: welches sind gängige Kontrollparameter in einem Projekt? Ich habe in den letzten Jahren eine Liste derjenigen Faktoren geführt, die mir in meinen Projekten jeweils zu schaffen gemacht haben, also Ursache für Mehraufwand waren. Folgende Faktoren habe ich bisher in zufälliger Reihenfolge identifiziert. Sicher gibt es noch mehr. Bitte schreiben Sie Ihre Erfahrungen in einem Kommentar zu diesem Eintrag.

1. Anzahl Subcontracors
Es ist allgemein bekannt, dass mit der Anzahl der Subcontractors die Stabilität des Projekts sinkt. Hierin sind sich sicher alle einig.

2. Geographische Distanz zu den Subcontractors
Auch in einer globalisierten Zeit spielt eben die geographische Distanz durchaus eine Rolle. Wenn sich irgend ein Inzident ereignet, dann ist der zuständige Subcontracter nicht zur Stelle. Ist er in einer anderen Zeitzone, kann man ihn vielleicht nicht einmal telefonisch erreichen. Kommt er aus einem anderen Kulturkreis, versteht er nicht immer alle Umstände, die ein Eingreifen regeln. Dadurch kann es zu einer Unruhe kommen, die das Projekt destabilisiert.

3. Ist der Auftraggeber ein Kunde oder eine interne, bzw. konzerneigene Stelle?
Das ist ein grosser Unterschied. Der Kunde bezahlt, so dass das Projekt zum Unternehmenserfolg beiträgt. Ein internes Projekt verursacht nur Kosten. Das Ziel eines internen Projekts kann z.B. sein, organisatorische Massnahmen einzuführen, die es erlauben, künftige Kundenprojekte effizienter abzuwickeln, was zu Einsparungen führen könnte. Mit anderen Worten: mit Kundenprojekten verdient man, mit internen Projekten spart man. Das hat auf das Laufzeitverhalten eines Projekts zumindest kognitive Auswirkungen.

4. Sind Verträge zwischen Kunden, Lieferant und Unterlieferanten vorhanden?
Es gibt verschiedene Szenarien, warum Verträge nicht oder nur lückenhaft vorhanden sind. Z.B. kann manchmal der Kunde gewisse Spezifikationen (für ein Folgeprojekt) erst zu einem späteren Zeitpunkt machen. Sie müssen aber ihre Subcontractors bereits jetzt binden. Deren Offerten laufen ab, bevor die Kundenspezifikationen vorhanden sind.
Hierhin gehört auch die Frage, ob der Kunde tatsächlich eine Bestellung gemacht hat und machen konnte, die dem entspricht, was im Vertrag/der Offerte steht1

5. Auf welchen Berechnungen basieren Offerten und Verträge?
Denken Sie z.B. an die Schwierigkeiten, die Menschen mit Verzögerungen haben. Projektpläne und Aufwandberechnungen berücksichtigen Verzögerungen meistens falsch. Das zeigt sich erst während des Projekts und kann dann zu heftigen Instabilitäten führen.

6. Welche organisatorische Distanz besteht zwischen dem jeweilige CEO und den Projektmanageren sowohl des Kunden als auch der Lieferanten?
Natürlich kann sich der CEO nicht um jedes Projektchen kümmern. Bei den Lieferanten sind Kundenprojekte aber Tagesgeschäft und müssten den CEO interessieren. Wenn der Projektmanager in fluktuativen Phasen eskalieren muss und der CEO keine Ahnung hat, worum es geht, verpufft die Eskalation und das Projekt dümpelt steuermannslos im seichten Wasser.

7. Anzahl Sprachen
Gemeint sind sehr wohl die gesprochenen Sprachen der Projektstakeholders. Wenn in einem Projekt die Leute über die ganze Welt verteilt sind und alle in einer anderen Sprache denken, dann ist es schon dann schwer, wenn sich alle auf Englisch unterhalten können. Auch wenn alle Beteiligten hervorragend Englisch sprechen, dann ist und bleibt es für die meisten eine Fremdsprache, und Missverständnisse sind an der Tagesordnung.

8. Anzahl Stakeholders und beteiligte Businesseinheiten
Stakeholders sind diejenigen Leute, die am Projekt interessiert sind und daher mitreden wollen oder zumindest mitdiskutieren. Neben den eigentlichen Projektmitarbeiter reden auch Linienmanager, Vertreter vom Verkauf und vom Marketing, Qualitätsverantwortliche im Konzern oder Kontroller mit. Alle Mensche haben eine andere Welt im Kopf, alle haben andere mentale Modelle. Je mehr Leute mitreden, desto kleiner ist das Gemeinsame all dieser Modelle. Es kann zu endlosen Diskussionen über Vorgehen und Planung kommen.

9. Lieferketten und Prozesslängen
Je länger die Zwischenstationen von Material, Produkte, Informationen, Wissen, etc. ist, desto instabiler der Projektlauf. Aber zählen Sie die Stationen nicht nur zwischen den Subcontractors, Lieferanten, Zulieferer und Kunde, sondern insbesondere innerhalb der jeweiligen Lieferkettenmitglieder. Gerade innerhalb eines Unternehmens sind die Prozesse häufig ziemlich verschlungen.

10. Hierarchiestufen im Unternehmen
Kommt es zu Uneinigkeiten, kann in einer flachen Hierarchie schneller ein Schiedsurteil gefunden werden. Das hat etwas mit der Prozesslänge innerhalb eines Unternehmens zu tun. Während Anfrage und Begründung für einen Entscheid über eine lange Hierarchieleiter hinauf und wieder hinunter müssen, kann im Projekt ein Sturm wüten und Schiffe unter gehen.

11. Anzahl technischer Experten vor Ort
Sie erinnern sich an den Eintrag Investieren Sie in Expertenwissen vom 26. Juli 2008. Muss der Projektmanager ständig um technische Spezialisten kämpfen, dann trägt das nicht gerade zur Beruhigung des Projekts bei. Wenn dieser Umstand dann noch zum Kunden durch dringt und auch er findet, man nehme ihn zu wenig ernst, dann kann das Projekt wieder in sehr turbulente Zeiten geraten.

12. Routinegrad und Komplexität des Projektgegenstandes
Natürlich sind das Streichen einer Küchendiele und die Migration eines Bankensystems auch als Projekte nicht vergleichbar. Ein guter Maler sollte genügend Routine im Streichen von Küchendielen haben. Zudem ist die Komplexität, die in einer frisch gestrichenen Küchendiele stecken kann überschaubar. Ich kann mir nicht vorstellen, dass es viele Moden gibt, die das System Küchendiele-Farbe-Maler-Benutzer einnehmen kann. Die Frage ist auch, wieviel Wissen in den Produkten/Dienstleistungen steckt.

13. Vertrauensgrad des Auftraggebers/Nutzniesers in den Projektführer
Manchmal hat ein Unternehmen supergute Produkte, aber Gerüchten nach funktionieren sie einfach nicht beim Kunden. Wenn auf solche Produkte migriert werden soll, ist der fluktuative Charakter des Projekts schon vorgezeichnet. Der Kunde erwartet gleichsam, dass das Projekt schief laufen wird, was eine self-fullfilling prophecy ist..

14. Politische Distanz zwischen beteiligten Organisationseinheiten in derselben Unternehmung
Grabenkämpfe innerhalb des Kunden- oder des Lieferantenunternehmens können Projekte enorm destabilisieren. Manchmal kommt das Projekt überhaupt nicht mehr weiter, bis organisatorische oder finanzielle Fragen innerhalb des Konzerns entscheiden sind. Wenn sich dann das Management nicht für das Projekt interessiert und keine Schiedsrichterrolle übernehmen will, dann kann das Projekt aus allen Rudern laufen.

15. Anzahl Schnittstellen zu oder von anderen Projekten
Wieviele andere Projekte, Organisationseinheiten , etc. hängen vom Projekt ab? In welchem Mass hängt das Projekt selber von wie vielen anderen Projekten und Organisationseinheiten ab? Wie sind die Endbenutzer verteilt?

Den meisten dieser Parametern können Sie eine Zahl zuordnen, Sie können sie also leicht messen. Daraus liesse sich ein Stabilitätsfaktor (oder – nicht ganz richtig – Komplexitätslevel) für ein Projekt errechnen. Wer ein Projekt beruhigen will (oder – fälschlicherweise ausgedrückt – wer die Komplexität reduzieren möchte, s. Ammenmärchen) weiss nun, an welchen Rädchen er drehen kann. Diese Parameter sind sozusagen die Hebel des Projektmanagers. Sind es wirklich alles Hebel? Wir kommen später noch auf Hebel zurück.

1Adrian W. Fröhlich. Mythos Projekt – Projekte gehören abgeschafft. Ein Plädoyer. Galileo Press. Bonn 2002. Über das Buch werden wir uns hier wohl noch unterhalten müssen.

Nachtrag vom 4. August 2008: In diesem Zusammenhang ist der Artikel von Gunter Nittbauer und Andreas Ernst, Team Synthegrity: Lösungen finden bei komplexen Fragen, interessant. Nicht so sehr wegen Stafford Beers Open Space ähnlichem Synthegrity-Ansatz, sondern weil Nittbaur/Ernst glauben, einen weiteren Kontrollparameter gefunden zu haben. Sie behaupten, dass an ein Projektkickoff um die 30 Teilnehmer gehören, einfach um die Komplexität in den Griff zu bekommen und den Benutzer genügend eingebunden zu haben. Ich habe einmal in einem Projekt in der Tat Meetings mit ca. 30 Telnehmer gemacht, um von allen ein Commitment zu haben. Resultat: paar Tage nach den Meetings wurden überall in den Kaffeeecken bilaterale Absprachen gemacht, die den Meetingbeschlüssen entgegen liefen.

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

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

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.

Verzögerungen als Dimension der Projektkomplexität

Verzögerungen haben es in sich und zwar nicht nur, wenn wir trödeln. Vorbereitungen, Fahrwege, Entscheidungen, Informationsbeschaffung, Lernen – all das benötigt Zeit. Mit Zeit können wir schlecht umgehen. Mindestens in dieser Hinsicht ist die Behauptung, Zeit sei Geld, falsch. Forscher an der Universität von North Carolina1 haben nämlich herausgefunden, dass vielbeschäftigte Menschen dazu neigen, ihr zukünftiges Zeitbudget zu optimistisch einzuschätzen und dadurch mehr Termine einplanen, als sie seriös wahrnehmen können. Wenn es ums Geld geht, sind die meisten Menschen hingegen realistischer. Geld ist fassbarer und hat als Zahlungsmittel eine bekannte Größe. Zeitbudget und Arbeitsaufwand hingegen variieren von Tag zu Tag. Damit wird es schwieriger, aus Erfahrungen zu lernen.

Stellen Sie sich vor, Sie stünden auf dem Markusplatz in Venedig und wären vom Hunderten von Tauben umgeben, weil Sie eine Tüte mit 1000 Körner in der Hand halten. Sie würden dann die Körner alle auf’s Mal in die Taubenschar streuen. Wie und wie schnell verschwinden diese 1000 Körner in den Mägen der Tauben?

Stellen Sie sich vor, sie würden heute in der Schweiz eine Massensendung von 1000 Briefe an Adressaten aufgeben, die in ganz USA verstreut sind. Wie und wann werden sie ankommen?

Zur Abwechslung etwas Kinderleichtes:

Stellen Sie sich vor, sie bestücken einen Brennofen jede Minute mit einem Palett Brenngut. Das Palett benötigt eine Stunde, um den Ofen zu durchlaufen. Was kommt am anderen Ende des Ofens wann heraus?

Das war ja nun wirklich nicht schwer. Weil Sie’s so gut gemacht haben, bleiben wir noch ein wenig beim Ofen:

Stellen Sie sich nun vor, dass ein findiger Ingenieur einen Porzellan erfunden hätte, der es erlaubt, in der Hälfte der Zeit gebrannt zu werden. Er erhöht also plötzlich die Durchlaufgeschwindigkeit des Brennofen so, dass ein Palett nur eine halbe Stunde benötigt. Sie bespicken aber den Ofen nach wir vor mit einem Palett pro Minute. Was kommt nun am anderen Ende wann heraus?

Stellen Sie sich vor, Sie züchten Weihnachts- oder sonst welche Bäume und verkaufen sie. Sie haben aber nur ein kleines Geschäft und können pro Jahr bloss zehn grosse Bäume verkaufe, wenn Sie überhaupt so viele haben. Zum Glück haben Sie mit einem Bestand von 60 grossen Bäumen gestartet. Sie pflanzen aber trotzdem jährlich 10 junge Bäume an, die sechs Jahre benötigen, bis sie gross genug sind, um verkauft werden zu können. Wie viele grosse, verkaufswürdige Bäume haben Sie oder Ihr Nachfolger in Abhängigkeit der Zeit, also nach einem, nach zwei, nach fünf, nach zehn, nach 20 oder nach 100 Jahren?

Gewiss, diese Fragen sind etwas speziell, aber es gelingt Ihnen sicher locker, sie in bestimmten Projektsituationen wieder zu erkennen. Spätestens dann sollten Sie als erfahrener Projektmanager diese Fragen im Interesse einer reibungslosen Projektabwicklung eigentlich beantworten können. Oder übersehen Sie grosszügig den Faktor Zeit? Haben Sie in Ihrem Projektplan z.B. die Projektmeetings auch nicht mit eingerechnet?

Viel Spass beim Lösen der Aufgaben.

1 Gal Zaubermann and John G. Lynch (2005), Resource Slack and Propensity to Discount Delayed Investments of Time versus Money, Journal of Experiment Psychology: General, 134 (1), 23-37.

Entscheiden unter Ungewissheit

Wir geraten immer wieder in Situationen, in denen wir uns für eine von mehreren Alternativen entscheiden müssen, ohne genau zu wissen, was wir uns da letzendlich einbrocken. Ich gebe es zu: Auch wenn es in einigen der Fällen durchaus möglich wäre, die Ungewissheit herabzusetzen oder quasi zu beseitigen, würden wir unseren Kortex nur etwas anstrengen, es bleiben dennoch echte Härtefälle übrig, in denen die Ungewissheit an uns nagt. Ok, und wie entscheiden wir dann? Die Psychologen wissen, dass wir uns in solchen Fällen der Heuristik Anchoring and Adjustment bedienen. Das tönt so gescheit, dass man versucht ist, sich vor so viel Verstand gleich tief zu verbeugen. Anchoring and Adjustment heisst aber nichts anderes, als dass man einen Anfangswert aus der Luft greift und dann den feuchten Finger in den Wind streckt und den Ankerwert auf die spezielle Situation anpasst.

Was glauben Sie, wie lange dauert ein Marsjahr? (Es sollen nur diejenigen antworten, die es nicht sicher wissen). Wie finden Sie die Antwort? Sie gehen wahrscheinlich von den 365 Tagen aus, die ein Erdjahr dauert. Das ist der Anchor. Nun wissen Sie (vielleicht), das der Mars weiter von der Sonne weg ist, als die Erde. Also muss er einen weiteren Weg um die Sonne zurück legen und wird wahrscheinlich länger haben, bis er sie umrundet hat. Geben wir ihm – na, sagen Sie etwas! – 100 Tage dazu? Oder 75? Na gut, dann hätten wir 365+75=440 Tage. In der Tat sind es … siehe zweiter Abschnitt in http://www.planetarium-goettingen.de/Aktuell/mars2003.html

Die beiden Psychologen Amos Tversky und Daniel Kahnemann haben bereits 1974 ein einfaches, aber umso denkwürdigeres Experiment gemacht: Sie wählten eine Zufallszahl zwischen 1 und 100 und fragten mal ein paar Leute, ob der Prozentsatz afrikanischer Staaten in der UNO wohl grösser oder kleiner als diese Zufallszahl sei. Nachdem die Leute diese Frage beantwortet haben, sollten sie den genauen Prozentsatz schätzen. Wurde am Anfang die Zufallszahl 65 gelost, schätzten die Versuchspersonen die Anzahl der afrikanischen Staaten in der UNO im Mittel auf 45%. War hingegen die geloste Zahl eine 10, so lagen die geschätzten Werte mit durchschnittlich 25% deutlich niedriger.

Das kann zuweilen traurige Auswirkungen haben.

Englich/Mussweiler baten deutsche Strafrichterinnen mit durchschnittlich 15 Jahren Be­rufserfahrung, aufgrund einer vierseitigen Schilderung einer Vergewaltigung das Straf­mass für den Täter festzulegen. Verlangte der Ankläger 34 Monate Freiheitsstrafe, so lag das Strafmass im Median bei 35,75 Monaten. Verlangte der Ankläger zwölf Monate, wurde der Täter im Schnitt zu 28 Monaten verurteilt. Sogar erfahrenen Richter lassen sich also beeinflussen. Das Beispiel stammt aus http://www.decisions.ch/dissertation/diss_ankereffekt.html)

Tversky, A., & Kahneman, D. (1974). Judgment under uncertainty: Heuristics and biases. Science, 185

Birte Englich/Thomas Mussweiler, Sentencing under uncertainty: Anchoring effects in the Court Room, Journal of Applied Social Psychology 2001, 1535-1551

Tücken im Bierspiel

Eine Pseudokomplexität im Bierspiel ist die Tatsache, dass es zwölf Variablen enthält. Das sind die Kästchen, die im kompliziert ausschauenden Modell unter 

http://www.public.asu.edu/~kirkwood/sysdyn/SDWork/work-4.pdf

auf Seite 32 mit SuppL, Inventory und Backlog bezeichnet sind. Natürlich nehmen die Spieler diese vielen Variablen nicht direkt wahr. Das zeigt, dass eine Situation oder das zu beeinflussende System trotz grosser Variablenzahl noch nicht unbedingt komplex zu sein braucht.

Obwohl das Bierspiel nicht so richtig komplex ist, bietet es doch im wesentlichen zwei Tücken (sonst wär’s ja nicht interessant), aus denen wir auch einiges lernen können. Die beiden Tücken sind:

  • Entscheiden unter Ungewissheit
  • Umgang mit Verzögerungen.

Beide Tücken sind so tückisch und kommen in Projekt- und Unternehmensführung so häufig vor, dass ich jeder mindestens einen eigenen Beitrag leisten möchte. Ich fürchte jedoch, dass sie uns in diesem Blog mehr als einmal hinter einer Ecke auflauern und uns erschrecken, wenn wir zufällig des Wegs gehen.