Wie entsorgen Sie weisses Porzellan?

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

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

Migrations- und Integrationsprojekte sind anders

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

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

1 Wiki Softwaretechnik, Artikel Chaos-Report

Wo kann in Projekten und Unternehmen etwas schief gehen?

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

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

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

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

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

Herkömmliche Projektmanagementmehtodik ist noch nicht alles

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

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

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

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

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

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

Verzögerungen erster und höherer Ordnung

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

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

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

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

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

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

Weitere Lektüre:

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

Stephanie Albin. Exponential Material Delays.

Investieren Sie in Expertenwissen!

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

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

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

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

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

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

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

Staus im Produktemanagement

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

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

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

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

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

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

Haben Sie sich auch schon mal überschätzt?

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

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

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

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

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

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.

Was für ein Aufmerksamkeitstyp sind Sie?

Gestern erhielt ich ein Mail mit folgendem Rätsel:

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

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

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

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

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

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

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

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