Projekten in den Rachen geschaut

Eines der ersten Projektmodelle veröffentlichte Ed Roberts 19641. In den frühen achtziger Jahren ebnete das Modell von Pugh-Roberts2 den Weg zum berühmten Modell mit dem sogenannten Rework Cycle. Ausgehend von einem Bestand an unerledigter Arbeit, der entsprechend der vorhandenen Produktivität abgearbeitet wird, fliesst ein Teil der erreichten Resultate in einen Bestand an erledigter und abgeschlossener Tasks, während ein anderer Teil Fehler enthält und in einen Bestand undiscovered Rework fliesst. Das sind also solche Tasks, die unbrauchbar sind und später nachgearbeitet werden müssen. „Später“ ist dann, wenn das Projektteam die Fehler wahrgenommen hat. Dann existiert ein Bestand an unerledigter Rework, der neben der geplanten Arbeit zusätzlich gemacht werden muss. Das führt zu einer Verzögerung in der Projektabwicklung. Folgende moderne Darstellung des sogenannten Rework Cycle lieferte Cooper 19933:

Zum Vergrösseren klicken Sie auf die Figur, die aus dem Überblicksartikel von Lyneis und Ford stammt4. Nach diesem Modell flacht der Fortschritt während der Laufzeit des Projekts vorübergehend ab, bevor er wieder anwächst. Das führt zum bekannten 90 % Syndrom. Nähere Einzelheiten hat James Lyneis in einer aufschlussreichen Powerpointpräsentation festgehalten5. Der Rework Cycle ist eines der best untersuchten Phänomenen im Projektmanagement. Unglücklicherweise betreffen alle diese Untersuchungen vor allem Entwicklungsprojekte und nicht so sehr Migrations- und Integrationsprojekte. Für diese steht ein valides Modell noch aus. In Migrations- und Integrationsprojekte kommt neben dem Rework Cycle vor allem ein „New work Cycle“ in’s Spiel, der viel gravierender ist.

Quellen:

1Ed B. Roberts. The Dynamics of Research and Development. Harper and Row. New York 1964

2Richardson, George P. and Pugh III, Alexander L. Introduction to System Dynamics Modeling with Dynamo. MIT Press. Cambridge, MA 1981

3Kenneth G. Cooper (1993). The Iteration Cycle: Benchmarks for Project Managers. Project Management Journal. Vol. 24, No. 1 and
Kenneth G. Cooper (1993). The Iteration Cycle: How Projects are Missmanaged. Project Management Journal. Vol. 24, No. 1

4James M. Lyneis and David N. Ford. System dynamics applied to project management: a survey, assessment, and direction for future research. In System Dynamics Review, 23/2007, No. 2-3. S. 157-189.

5James M. Lyneis. Dynamics of Project Performance (2003). Powerpoint Presentation. Massachusetts Institute of Technology MIT

Was wäre, wenn Tschechien die Schweiz mit 2:1 geschlagen hätte?

In der Gruppe A der Europameisterschaft 2008 im Fussball wurden sechs Spiele gespielt. Es trafen Portugal (p), Tschechien (s), Türkei (t) und die Schweiz (c) aufeinander. Die Resultate waren:

s schlug c 1:0
p schlug t 2:0
p schlug s 3:1
t schlug c 2:1
c schlug p 2:0
t schlug s 3:2

Aufgrund nur dieser Ergebnisse war z.B. Tschechien besser als die Schweiz. Lassen Sie uns das so schreiben: s < c. Das Gruppenergebnis kann somit in einer Zeile geschrieben werden:

p < t < s < c < p < s und t < c

Das liest sich so: Portugal ist besser als die Türkei, die ist besser als Tschechien, das ist besser als die Schweiz, die ist besser als Portugal, etc. Oder kurz: Portugal ist besser als Portugal, oder noch etwas pointierter ausgedrückt: Portugal schlägt sich selbst! Man sagt, dass diese Reihenfolge nicht transitiv ist. Das ist der Fall, wenn man sich nur auf die erzielten Resultate abstützt. Daher müssen noch andere Kriterien als nur die gespielten Resultate in die Berechnung einbezogen werden. Ohne auf das genaue Verfahren einzugehen, ist eines sicher: wäre das Spiel Schweiz gegen Tschechien mit 1:2 statt mit 0:1 ausgegangen, hätte das auf das Gruppenresultat keinen Einfluss gehabt. Nach wie vor wären Portugal auf Rang 1 und die Türkei auf Rang 2 geblieben. Und das entspricht auch unserem Gerechtigkeitssinn: Werden irrelevante Alternativen verändert, hat das keinen Einfluss auf die Gesamtrangliste.
Wenn Sie Toto spielen, dann müssen Sie einen Tip für die sechs Spiele geben, z.B. könnten Sie folgenden Tip abgeben:

c:s Tip 2
p:t Tip 1
s:p Tip 2
c:t Tip 2
c:p Tip 1
t:s Tip 1

Damit tippen Sie auf dieselbe Rangordung, wie die Mannschaften dann auch erspielt haben. Bei einer Wahl oder Abstimmung legen also alle Wähler ihre Präferenzen der Alternativen vor.

Wo Teams an der Arbeit sind, muss aus den Rangordnungen der Mitglieder eine Rangordnung des Teams extrahiert werden. Oft geht das mit Mehrheitsbeschluss. Aber, wie ich eingangs gezeigt habe, ist dieses Vorgehen nicht immer schlüssig, wenn mehr als zwei Alternativen vorliegen. Wenn die Alternative A gegenüber der Alternative B bevorzugt wird und wenn Alternative B gegenüber der Alternative C bevorzugt wird, so sollte Alternative A gegenüber der Alternative C bevorzugt. Das haben wir eine transitive Rangordnung genannt. Klar? Sie meinen, das sei selbstverständlich? Betrachten Sie ein Dreierteam, das sich zwischen den Alternativen A, B und C zu entscheiden hat.
Person 1 präferenziert A vor B und B vor C
Person 2 präferenziert B vor C und C vor A
Person 3 präferenziert C vor A und A vor B
Fragen Sie plump in das Plenum, wer für A, B oder C sei, werden Sie jeweils nur eine Stimme haben und zu keiner Entscheidung kommen. Also fragen Sie vielleicht, wer A der Alternative B vorziehe, wer B der Alternative C vorziehe und wer A der Alternative C vorziehe und sie werden für jede Frage je zwei Zustimmungen erhalten. Zwei Stimmen sind die Mehrheit in einem Dreierteam. Also zieht nach demokratischen Spielregeln das Team die Alternative A der Alternative B vor, diese der Alternative C und C wiederum der Alternative A. Der Mehrheitsbeschluss verletzt also die Transitivität.

Inwieweit können Teams überhaupt konsensfähig sein, wenn mehr als zwei Alternativen zur Auswahl stehen? Die Antwort auf diese Frage ist für eine erfolgreiche Projektarbeit sehr wichtig. Wenn Sie als Projektmanager mit einem Team arbeiten und es gibt mehrere Alternativen, wie entscheiden Sie dann? Z.B. könnten Sie abstimmen lassen und hoffen, dass sich für eine Alternative eine Mehrheit findet. Dann habe Sie ein Verfahren, um aus den einzelnen Individualpräferenzen eine Teampräferenz zu machen. Aber reflektiert sie auch wirklich die Meinung der einzelnen Mitglieder? Wir wissen es nicht, aber unser Verfahren soll doch ein paar Erwartungen erfüllen:

  1. Es soll keinen Diktator geben, also kein Individuum soll dem Team die Alternative vorschreiben dürfen, die es als Team bevorzugen soll.
  2. Die Individuen sollen sich zwischen je zwei Alternativen entscheiden können. Das bedeutet, dass sich jedes Individuum zu einem beliebigen Paar von Alternativen einer der beiden den Vorzug geben oder beide als gleichwertig einstufen kann. „Ist mir doch wurscht“ wollen wir nicht gelten lassen.
  3. Wenn alle Individuen die Alternative A der Alternative B vorziehen, dann soll auch das Team als ganzes die Alternative A gegenüber der Altenative B bevorzugen.
  4. Die Präferenzen der Individuen gegenüber Alternativen, die selber keine
    Aussicht haben, kollektiv gewählt zu werden (irrelevante Alternativen), sollen keinen Einfluss auf die Alternative haben, die kollektiv gewählt wird. Im Beispiel des Fussballspiels Schweiz gegen Tschechien haben wir angenommen, dass es mit 1:2 statt mit 0:1 ausgegangen ist und gesehen, dass dies auf die Sieger Portugal und die Türkei keinen Einfluss gehabt hätte.

Kenneth Arrow zeigte 1951, dass bei mehr als zwei Alternativen diese vier Bedingungen nicht gleichzeitig erfüllt sein können. Genau zeigte er, dass wenn in üblichen Abstimmungsverfahren die Bedingungen 2, 3 und 4 erfüllt sind, es dann einen Diktator gibt1. Das bedeutet, dass wir mit Teammeinungen im Management sehr vorsichtig sein sollten, denn demokratische Entscheidungsverfahren existieren nicht bei mehr als zwei Alternativen.

Im Anschluss an den Beitrag Wann sind Projekte instabil? vom 3. August, habe ich auf eine Darstellung der Methode Team Syntegrity verwiesen, in welcher die Autoren behaupten, dass die Entscheidungs- und Konsensfindung bei grossen Projekten, bei denen viele unterschiedliche Sichtweisen und Interessen bestehen, … durch eine grössere Anzahl von Personen erfolgen muss. Sie berichten von einem Fall, in welchem die Teilnehmer rund hundert Massnahmen erarbeitet hätten2. Nicht überliefert ist die Antwort auf die Frage, wie diese Massnahmen priorisiert wurden. Genau das ist nämlich nach Arrow unmöglich und führt zwangsläufig zu Konflikten. Ein anderes Beispiel, in welchem eine Rangordung des Teams aus den Rangordnungen der Teammitglieder extrahiert werden muss, ist das Risikomangement. Dies wird meist im Team angegangen, in der Hoffnung, dass viele Köpfe alle Risiken aufzählen können, die im Moment vorstellbar sind. In diesem Fall bin ich sehr skeptisch, denn wenn man mögliche Risiken einfach durch ein Brainstorming sucht, kommen bestimmt nur diejenigen zum Vorschein, die in den Griff zu bekommen man fähig ist. Das ist eine Art selektive Wahrnehmung. Jedem Risiko muss dann jeweils eine Eintrittswahrscheinlichkeit zugeordnet werden. Jedes Teammitglied tut das für sich. Es gibt dann keinen Weg, um zu einer Rangordung der Eintrittwahrscheinlichkeiten zu kommen, die dem Team entspricht. Der Projektmanager kann diese Rangordnung gerade so gut alleine erstellen.

Eine etwas ausführlichere Darstellung des Unmöglichkeitssatzes von Arrow findet sich unter
Lenk, Thomas u. Volkmar Teichmann. Arrows Unmöglichkeitstheorem. In: Das Wirtschaftsstudium (WISU), 28. Jg., Heft 6 (Juni 1999), S. 866-870.

1Arrow, K., Social Choice and Individual Values. 2. Auflage. New Haven 1963
2Nittbaur/Ernst. Team Syntegrity: Lösungen finden bei komplexen Fragen. Projektmagazin, 2003 http://danicos.dk/artikler/Projektmagazin.pdf

Jede Anwenderumgebung verhält sich anders

Migrations- und Integrationsprojekte (MIP) sind deshalb so schwierig, weil sie von lokalen Integratoren durchgeführt werden, die nur beschränkte Produkte- und Engineeringwissen haben können. Sie nehmen Produkte aus dem eigenen Konzern oder von Drittanbieteren und integrieren diese in den Umgebungen der Auftraggeber. Da die Produkte proprietär sind, kann der Integrator von den Produkteinternals nur beschränkt Kenntnisse haben. Damit fehlen ihm fast sämtliche Hebeln.

Wenn das Produkteverhalten nicht den Erwartungen entspricht, kann häufig nur der Hersteller sagen, ob es sich um einen Produktefehler oder um einen Installations- oder Bedienungsfehler handelt. Da aber die Experten beim Hersteller ebenfalls rar sind, kann das Projekt unter Umständen lange warten, bis schlüssige Informationen vorliegen. Der lokale Integrator ist jedoch der Geschäftspartner des Kunden, so dass sich dieser nicht interessiert, ob der Hersteller Zeit und Lust hat, das Projekt zu supporten. Nicht selten führt dieser Umstand zur völligen Erosion der Marge des Integrators.

Gibt es das nur in der IT? Auch im Bauwesen sind Integratoren am Werk. Ein Fensterlieferant oder ein Bauschlosser müssen Teilgewerke in einem Hauptgewerk intergrieren. Auch sie haben die Produkte vielleicht nicht selber gemacht, sondern von einem Lieferanten eingekauft und an die projektspezifischen Gegebenheiten angepasst. Dabei könnte es sich durchaus auch zeigen, dass die Produkte Mängel haben, die eine Integration an Hauptgewerk beinahe verunmöglichen. Aber ein grosser Unterschied besteht gegenüber der IT. Die Subsysteme im Bauwesen sind statisch, während sie in der IT ein Laufzeitverhalten aufweisen, das Unbestimmtheit über die eigentliche Installation hinaus mit sich bringt.
Neue Subsysteme verhalten sich fast immer instabil bei der Integration in spezielle Kundenumgebungen, auch wenn sie die Entwicklungstests (Factory Acceptance Tests) bestanden haben. Aber jede Kundenumgebung ist anders. Die Firma mValet hat 2007 eine Umfrage unter 10 der Fortune 500 IT-Anwendern durchgeführt, um tieferen Einblick in die versteckten Kosten von Migrationsprojekten zu erhalten.

Fazit:

Frequent inconsistencies and errors in so-called „environmental variables“ – applications that work in development experience difficulties when promoted into QA or other pre-production phases owing primarily to environmental differences (e.g., configuration settings of application infrastructure components being out of sync)1.

Die vielen Fehler und Instabilitäten, die während der Integration auftauchen, verlangen eine minutiöse Analyse und Reproduktion im Labor des Integrators. Er muss die Fehler genau dokumentieren, bevor er sie an den Hersteller oder ins Entwicklungscenter weiter geben kann. Ohne detaillierte Dokumentation des Fehlers, hören die Entwickler gar nicht erst zu. mValet schreibt dazu:

High change rates for applications in pre-production phases – these changes contribute to system instability and extended troubleshooting efforts which result in scheduling delays. Extensive analysis that wastes hours and days of IT staff time is required to diagnose and remediate the configuration setting differences that cause this issue1.

mValet errechnete, dass die Migrationsprojekte pro befragtem Unternehmen einen Anteil an den direkten Lohnkosten von zwischen 500 und 800 Tausend Dollars jährlich verschlingt. Eigentlich unverständlich, warum sich die Literatur vor allem auf Entwicklungsprojekte fokussiert, wo doch MIP viel mehr Unbestimmtheit aufweisen!

1mValet. Large Application Migration Projects Consume Significant and Consistent Hidden Costs. Business Wire 2007-12-12

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

Pipeline-Verzögerungen

Als gutem Projektleiter ist es Ihnen natürlich nicht entgangen, dass wir noch einen offenen Task haben. Noch sind nicht alle Fragen aus dem Beitrag Verzögerungen als Dimension der Projektkomplexität vom 24. Juli gelöst.
Die Aufgabe mit dem Brennofen macht sicher niemandem Mühe. Wenn ich – sagen wir mal – ein Palett (ja, ich weiss, dass es korrekt „die Palette“ heisst; aber das widerstrebt mir; in der Schweiz sagt man „das Palett“), wenn ich also ein Palett mit 1000 Tassen einmalig in den Ofen schiebe, dann haben wir dieselbe Situation, wie mit den Tauben und den Briefen. Es geschieht eine Stunde lang rein gar nichts, dann kommen alle 1000 Tassen zusammen aus dem Ofen, genau so wie ich sie rein geschoben habe. Der Output verteilt sich nicht über eine gewisse Zeit, wie bei den Briefen. Eine solche Verzögerung heisst Verzögerung mit fester Verzögerungszeit oder Pipeline-Verzögerung, gegenüber den bereits bekannten Verzögerungen erster, zweiter oder höherer Ordnung.

Nun stellen Sie also jede Minute ein Palett in den Ofen. Jedes Palett benötigt eine Stunde, um den Ofen zu durchlaufen. Also kommen eine Stunde, nachdem Sie mit der Beschickung des Ofens begonnen haben, jede Minute ein Palett hinten raus. Während Sie den Ofen gedankenverloren bestücken – je ein Palett pro Minute – läuft jetzt das Band plötzlich doppelt so schnell. Was passiert? Die Paletten stehen in einem Abstand auf dem Band, dass sie sich bei der langsamen Geschwindigkeit im Minutentakt folgen. Nun läuft das Band doppelt so schnell. Also kommen sie nun alle 30 Sekunden am Ende des Ofens an. Die Outputrate verdoppelt sich! Aber wie lange? Wenn sie mit der Präzision einer Turmuhr jede Minute ein Palett in den Ofen schieben, werden auf der anderen Seite grundsätzlich auch jede Minute eines raus kommen. Also können nicht ewig zwei Paletten pro Minute den Ofen verlassen. Von dem Moment an, in welchem das Band auf die doppelte Geschwindigkeit gesetzt wurde, stehen die Paletten auf dem Band doppelt so weit auseinander wie vorher. Es vergeht eine halbe Stunde – die Brennzeit ist ja halbiert worden – bis ein Palett den Ofen wieder verlässt. Also wird die Outputerhöhung eine halbe Stunde andauern. Das sieht dann so aus:

Blau ist der Input. Nach 30 Minuten beginnen wir, den Ofen mit 1 Palett pro Minute zu beschicken und halten diese Rate konstant. Rot ist der Output. Nach 90 Minuten verlässt ein Palett pro Minute den Ofen. Nach 120 Minuten erhöhen wir die Fliessbandgeschwindigkeit, d.h. wir verkürzen die Brennzeit von 60 auf 30 Minuten (schwarze Kurve). Sofort erhöht sich der Output von einem auf zwei Paletten pro Minute, um 30 Minuten später wieder auf den Ausgangswert zurück zu fallen. Grün ist übrigens der Inhalt des Ofens. Können Sie sehen, welcher Gesetzmässigkeit er gehorcht?

Nun zu den Tännchen. Können Sie eine Analogie zum Brennofen bilden? Stellen Sie sich vor, Sie hätten sieben Gehege. In Gehege Nummer 1 stehen frisch angepflanzte Tännchen. In Gehege Nummer 2 stehen jährige Tännchen. In Gehege Nummer 3 stehen zweijährige Tännchen, usw. In Gehege Nummer 6 stehen also fünfjährige Tännchen, also solche, die zwischen fünf und sechs Jahre alt sind, und was in Gehege Nummer 7 steht, können Sie verkaufen. Jedes Gehege ist wie ein Brennofen in der Porzellanmanufaktur. Sie stossen jedes Jahr ein Palett mit 10 Tännchen rein und nach einem Jahr kommt es wieder zum Ofen – pardon – Gehege raus. Natürlich würden Sie nicht jedes Jahr die Tännchen ausgraben und im nächsten Gehege wieder eingraben. Aber sie können sich die Gehege dennoch wie sechs in einer Reihe stehende Brennöfen vorstellen. Gehege Nummer 7 ist das Verkaufslager. Wenn Sie nun in diesem Gehege 60 Tannen haben, von denen Sie jedes Jahr 10 verkaufen, und in jedem der ersten sechs Gehege je 10 Tännchen stehen und wenn Sie jedes Jahr in Gehege Nummer 1 zehn neue Tännchen anpflanzen, dann passiert nichts. Das System ist in einem dynamischen Gleichgewicht. Beachten Sie das Wort dynamisch. Das Gleichgewicht ist dynamisch. Es passiert durchaus etwas. Die Tännchenpopulationen wechseln. Nur zahlenmässig passiert nichts. Und theoretisch – solange alles gut geht. Praktisch sähe die Sache anders aus, wenn Ihnen auch nur ein Tännchen in irgend einem Durchlaufgehege abstirbt. Das würde zwar kein Problem sein, da Sie ja in Gehege Nummer 7 stets 60 Tannen stehen haben. Kommen in einem Jahr nur neuen statt zehn Tannen an, dann haben Sie immer noch 59. Aber schliesslich beginnen Sie ja mit 60 Tannen in Gehege Nummer 7, weil die Tännchen 6 Jahre benötigen, bis sie eine verkaufswürdige Grösse haben. Also nehmen wir mal an, Sie hätten zu Beginn keine Tännchen in den Zuchtgehegen und pflanzen stets an, was sie in diesem Jahr verkauft haben und das sollen konstant zehn sein. Zuerst verkaufen Sie, dann pflanzen Sie an. Z.B. verkaufen Sie zehn am 20. Dezember, dann pflanzen Sie soviele Tännchen an, wie Sie am Vortag verkauft haben. Da Sie aber in Gehege 1 anpflanzen und dort noch 10 fast einjährige Bäumchen stehen, müssen Sie zuerst Platz schaffen, indem Sie die Bäumchen von Gehege n in das Gehege n+1 umpflanzen (nur in Gedanken – tatsächlich werden Sie nur die Namenschilder der Gehege tauschen). Sagen wir, Sie verschieben die Bäumchen am 31. Dezember und pflanzen die neuen am 1. Januar des Folgejahres an. Dann haben Sie am Ende des ersten Jahres noch 50 Tannen in Gehege Nummer 7 und am Ende des sechsten Jahres sind Sie blank. Am 20. Dezember des siebenten Jahres sollten Sie 10 Tannen verkaufen. Sie haben aber keine in Gehege Nummer 7. Streng genommen dürfen Sie keine verkaufen und am darauf folgenden 1. Januar auch keine pflanzen. Spätestens jetzt ist es an der Zeit, dass Sie sich eine Tabelle machen, vielleicht sogar eine Excel-Tabelle mit entsprechenden Formeln. Können Sie das? Bei mir sehen die ersten paar Zeilen so aus:

Was wir hier haben, ist ein (formales) Modell. Modelle sind für das systemische Denken ausserordentlich wichtig. Wenn Sie es schaffen, die Problemstellungen, die Sie im daily Business antreffen, mindestens gedanklich in Modelle zu fassen, lösen Sie Ihre Aufgaben sehr viel leichter. Wenn Sie (und ich) die Tabelle richtig ausgefüllt haben, werden Sie für das Gehege 7 ein interessantes Verhalten beobachten. Bei mir sieht es so aus:

Wie Sie sehen, oszilliert der Baumbestand in Gehege 7. Verzögerungen bewirken in Feedbackschlaufen meistens Oszillationen, wenn der Output des Systems verzögerten Einfluss auf den Input hat, was in unserem Modell der Fall ist. Unser Feebackloop sieht nämlich – etwas vereinfacht – so aus:

Aber natürlich werden wir am 20. Dezember des siebenten Jahres die fast sechs jährigen Tannen verkaufen, die in Gehege 6 stehen. Wie sieht dann das Modelle aus? Meine Excel-Tabelle generiert dieses Diagramm:

Das bedeutet, dass wir mit dem Trick, die knapp sechsjährigen Bäumchen zu verkaufen, die Marktnachfrage gerade befriedigen, haben aber keinen Vorrat in Gehege 7 mehr. Wie Sie sehen, können schon so einfache Dinge, wie Verzögerungen mit festen Verzögerungszeiten unser Gehirn ganz schön fordern. Wenn ich Ihnen jetzt noch sage, dass eine Verzögerung mit der festen Verzögerungszeit T dasselbe ist, wie eine Verzögerung unendlicher Ordnung mit der Verzögerungszeit T, dann sind Sie vielleicht vollends verwirrt. Aber das Verständnis für Verzögerungen aller Art ist in der Projektarbeit nach wie vor wichtig. Funke beschreibt Schwierigkeiten beim Problemlösen in komplexen Umgebungen wenn Verzögerungen mit im Spiel sind1.

1Joachim Funke. Komplexes Problemlösen. In J. Funke (Ed.), Denken und
Problemlösen
(=Enzyklopädie der Psychologie, Themenbereich C: Theorie und
Forschung, Serie II: Kognition, Band 8: Denken und Problemlösen). Göttingen:
Hogrefe. Göttingen 2006.

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

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

Komplexität verstehen