Archiv für den Monat: August 2008

Margenpflege und gemeinsames Schulterklopfen

Eine wichtige Quelle von Projektfehlern ist die Rationalisierung. Wenn es gelingt, Arbeiten zu bündeln oder Abkürzungen zu nehmen, so kann man Aufwand sparen und dadurch die Marge erhöhen. Eine andere Rationalisierungsstrategie ist es, bei verschiedenen Kunden gleiche Projekte parallel durchzuführen.
In einer Zeit, in der „Geiz geil ist“ und niemand mehr etwas bezahlen will aber dennoch alle höchste Ansprüche haben, können die Anbieter ihre geschätzten Aufwendungen nicht mehr voll verrechnen, ohne von der Konkurrenz unterboten zu werden. Deshalb ist die Marge schon zu Projektbeginn so klein, dass kaum ein Anreiz für Qualität besteht. Kleine Auslassungen in Dokumentationen werden meistens nicht bemerkt und haben auch keine Auswirkungen. Verletzung von Qualitätsstandards werden dann im lerntheoretischen Sinne verstärkt: man hat etwas davon, wenn man Arbeiten nicht vollständig und perfekt ausführt. Solange der Kunde nichts merkt und nicht reklamiert, spart man nämlich Aufwendungen und erhöht so die Marge. Benötigt der Lieferant die Dokumentation jedoch schon während des Projekts – z.B. Installations- oder Testdokumentationen – empfiehlt es sich natürlich nicht, zu schlampen. Denn Dokumentationslücken können sich in Aufwand und Verzögerungen manifestieren, die die Einsparung an Zeit bei der Dokumentationserstellung um ein Mehrfaches übersteigen. Wenn in einem globalisierten Unternehmen jedoch mehrere in die Tiefe geschachtelten Abteilungen aus verschiedenen Konzerngesellschaften an der Bereitstellung der Projektergebnisse beteiligt sind, kann nicht mehr sicher gestellt werden, dass immer alle Ergebnisse vollständig und richtig sind.

Eine andere Quelle von Fehlern berichtet Dietrich Dörner. Wir treffen diese Fehler auch in Projekten häufig an. Sie bestehen in der Tendenz einer Gruppe von Fachleuten, sich selbst zu bestätigen, alles richtig und gut zu machen. Ein Team mit einer gewohnheitsmässig hohen Selbstsicherheit „betreibt“ das Projekt nicht mehr „analytisch“, sondern „intuitiv“. Dörner schreibt: Man glaubt zu wissen, womit man zu rechnen hat, und man glaubt sich erhaben über die lächerlichen Projektdokumentationen und Qualitätsstandards, die allenfalls für Projektanfänger gelten mögen, aber nicht für ein Team gestandener Fachleute, die vielleicht sogar noch PMI-zertifiziert sind1. Die Tendenz einer Gruppe, Kritik implizit durch Konformitätsdruck zu unterbinden, hat Janis 1972 als die Gefahr des groupthink bei politischen Entscheidungsteams geschildert2. Wir treffen sie auch zuweilen bei Geschäftsleitungen an. Wenn man “lügen” als “sich als über alle Probleme erhaben darzustellen” und “Meineid” als “Unterbinden von Kritik” interpretiert, so ist Reinhard Meys Lied eine gelungene Karikatur der beschriebenen Situation:

Der Steuermann lügt, der Kapitän ist betrunken,
und der Maschinist in dumpfe Lethargie versunken,
die Mannschaft: lauter meineidige Halunken,
der Funker zu feig’ um SOS zu funken.
Klabautermann führt das Narrenschiff,
volle Fahrt voraus und Kurs aufs Riff!

Die Ladung ist faul, die Papiere vergilbt,
die Lenzpumpen lecken und die Schotten blockiert,
die Luken weit offen und alle Alarmglocken läuten.
Die Seen schlagen mannshoch in den Laderaum,
und Elmsfeuer züngeln vom Ladebaum,
doch keiner an Bord vermag die Zeichen zu deuten.

Am Horizont Wetterleuchten; die Zeichen der Zeit:
Niedertracht und Raffsucht und Eitelkeit.
Auf der Brücke tummeln sich Tölpel und Einfaltspinsel.
Sie rüsten gegen den Feind, doch der Feind ist längst hier,
er hat die Hand an deiner Gurgel, er steht hinter dir,
im Schutz der Paragraphen mischt er die gezinkten Karten.

1Dietrich Dörner. Die Logik des Misslingens. Strategisches Denken in komplexen Situationen. Rowohlt Taschenbuchverlag. Reinbek b. Hamburg 1992 u. 2002

2I. Janis. The Victim of Groupthink. Houghton Mifflin. Boston 1972

Wahrnehmungen haben eine endliche Geschwindigkeit

In den letzten paar Wochen habe ich gleich mehrmals die relativ frustrierende Erfahrung machen müssen, dass man Pläne nicht ohne weiteres ändern darf, vor allem, wenn die Änderung nur Details betrifft. Beispielsweise habe ich für einen Verein ein Jahresprogramm zusammen gestellt und dieses kommuniziert. Kurz vor dem Inkrafttreten des Programms habe ich eine kleine Änderung vorgenommen und zweimal mündlich darauf aufmerksam gemacht. Aber nein, mindestens die Hälfte der Mitglieder haben die Änderung nicht zur Kenntnis genommen und stellten sich auf den alten Plan ein, was natürlich konfliktträchtig ist, wenn die beiden Planvarianten kollidieren. Planänderungen müssen mit Pauken und Trompeten kommuniziert werden. Sie müssen jeden Betroffenen am Ärmel nehmen, ihm in die Augen sehen und sich bestätigen lassen, dass er die Änderung zur Kenntnis genommen habe. Am besten lassen Sie ihn mit dem eigenen Blut unterschreiben. Aber wer will schon so ein Tamtam machen, wenn die Änderung bloss ein Detail betrifft?

Beim Durchlesen meines Eintrags Glauben Sie, Vergessen sei bloss eine Charakterfrage? vom 12. August ist mir ein interessanter Zusammenhang zwischen dem wissensbasierten Verhaltensmuster Überbewertung des aktuellen Motivs und Verzögerungen aufgefallen, die wir verschiedentlich bereits untersucht haben. Ich stelle mir ein Projektsystem stets als Oberfläche eines Teiches vor. Wo immer im Projekt ein Stakeholder – Projektmanager, Projektmitarbeiter, Linie, Marketing, Ver- und Einkauf, Kunde, Lieferant, etc. – handelt, sendet sein Tun konzentrische Wellen durch das Projekt. Sie lösen bei denen, die sie erreichen, wieder Entscheidungen und Handlungen aus, die sich wellenförmig durch das Projektsystem fortsetzen. Erreichen uns viele dieser Wirkungswellen, empfinden wir das Projekt als komplex, chaotisch, turbulent oder fluktuativ, was zur Folge hat, dass wir selbst zu strampeln anfangen und so noch viel mehr Wellen erzeugen. Dörner nennt den Mach-mal-vielleicht-hilft-das-ja-Ansatz Reparaturdienstverhalten und die Konzentration auf viele Problemfragmente Projektemacherei1.

 

Ein einmal publizierter Plan “durchtränkt” das Projekt langsam. Es braucht einige Zeit, bis er im Bewusstsein aller ist. Wenn Sie nur ein Detail ändern, dann braucht es seine Zeit, bis dieses Detail durch das Projektsystem propagiert ist, auch wenn Sie die Änderung mehrmals erwähnt haben. Die Leute vergessen es sofort wieder, wenn sie es überhaupt realisiert haben. Denken Sie an Reasons Aufmerksamkeitsfehler auf der fähigkeitsbasierten Ebene oder an den Spurenzerfall im Langzeitgedächtnis. In der Zeit der Propagation einer Planänderung sind gewissermassen beide Planvarianten aktiv. Das müssen Sie als Projektmanager stets bedenken und alle abholen. Wehe, Sie verlassen sich darauf, dass alle Stakeholder die Änderung realisiert haben! Ändern Sie nie einen Plan ohne Pauken und Trompeten und einem mittelkalibrigen Feuerwerk!

Wahrnehmungen erleiden genauso Verzögerung wie die Körner, die von den Tauben aufgepickt werden oder die Paletten im Brennofen. Siehe Verzögerungen erster und höherer Ordnung und Pipeline-Verzögerungen. Angenommen, Sie haben eine Planvariante zu 100% in Ihrem Gedächtnis. Nun wird Ihnen eine Änderung kommuniziert. Das führt nur dazu, dass die ursprüngliche Planvariante nur noch zu vielleicht 90% im Gedächtnis ist, während die neue Variante die restlichen 10% ausfüllt. Wird Ihnen die Änderung ein zweites Mal kommuniziert, gilt die alte Variante für Sie noch zu 80% und die neue zu 20%, usw. Natürlich ist das bloss ein Modell. Entweder haben Sie geschnallt, dass der Plan abgeändert wurde oder Sie haben es nicht mitbekommen. Um jedoch die Tatsache zu verstehen, dass eine Änderung nur nach und nach ins Bewusstsein der Leute dringt, können wir uns dem Modell bedienen, dass der eine Gedächtnisinhalte nach und nach durch einen neueren verdrängt wird. Das könnte man dann so darstellen:

 

Was passiert nun, wenn die Änderung nur einmal, wenn auch deutlich, kommuniziert wird? Der aktuelle Gedächtnisinhalt wird sich wie folgt entwickeln:

 

Zwar nehmen wir eine Veränderung wahr, aber nach mehr oder weniger kurzer Zeit haben wir sie wieder vergessen. Das ist doch genau die Situation, die wir von den Körner und den Tauben her kennen. Interessanterweise verhalten sich Prozessverzögerungen erster Ordnung und Wahrnehmungsverzögerungen erster Ordnung genau gleich, obwohl sie eine ganz andere Struktur haben. Wird die Veränderung konstant gemeldet, dann passt sich die Wahrnehmung langsam der kommunizierten Realität an:

Die rote Kurve zeigt den Plan. Er erfährt eine Änderung in der Woche 5. Die blaue Kurve zeigt die aktuelle Wahrnehmung. Sie gleicht sich langsam der gemeldeten Tatsache an.

1Dietrich Dörner. Die Logik des Misslingens. Rowohlt Taschenbuch Verlag. Reinbek bei Hamburg 1992 (2002)

Im Himmel ist alles viel einfacher

Kürzlich nahm ich an einer Strategiediskussion einer Gruppe von Mitgliedern einer humanitären Organisation teil. Es ging dabei um die Frage, welche humanitären Aktionen man als nächstes in Angriff nehmen wolle. Nachdem sich unterschwellig ein paar Konflikte abzeichneten, lief die Diskussion darauf hinaus, dass man nur noch Ideen sammelte, wem man Geld spenden will. Anstatt zu überlegen, was man mit den eigenen Kräften tun könnte, begann man aufzuzählen, welche notleidenden Zielgruppen es gibt, die die Hilfe nötig haben. Eine solche Aufzählung ist leider sehr einfach, denn die Not in der Welt ist bekanntlich gross. Am Schluss überlegte sich die Gruppe, wem sie grosszügigerweise Geld zukommen lassen will, ob der Schule in einer ärmlichen Region Osteuropas oder Brandopfern in einer hiesigen Universitätsklinik. Es ist natürlich bedeutend angenehmer, in Gedanken Geld zu verteilen, als zu überlegen, was man arbeiten sollte. Schliesslich bestimmte die Gruppe ein Mitglied, das sich bis zum nächsten Treffen Gedanken machen soll, mit welcher konkreten Aktion man das Geld verdienen könnte, das man dann der Zielgruppe zukommen lassen will.

Solche Diskussionen erlebe ich in Projekten und im Management fast täglich. Wenn einer darauf hinweist, dass man thematisch abgleite, wird ihm unwirsch erklärt, dass die Diskussion von Grundfragen der wirklich wichtige Schritt sei. Psychologen nennen diesen Verhalten vertikale Flucht. Stefan Strohschneider schreibt darüber, dass man sich von der Ebene profanen Handelns löst und sich in Gedanken damit beschäftigt, wie es wäre, wenn die Probleme schon gelöst seien. Dazu gehört auch die ständige Entwicklung neuer Zielvorstellungen, gekoppelt mit dem Verschleppen von Terminen, bei denen man sich konkret mit dem in Frage stehenden Problemen auseinander setzen müsste. In einer angenehmen Gruppenatmosphäre wird besonders die Vermeidung von Konflikten wichtig1. Die Gruppe verlegt sich auf die angenehme oder beherrschbare Ebene (hinauf, deshalb vertikale Flucht genannt) und erklärt, dort die eigentlichen Grundfragen des Projekts zu behandeln. Vor allem, wenn die Vergangenheit von Misserfolgen geprägt war, kapselt man sich gerne gegenüber unangenehmen oder schwierigen Fragen ab. Harald Schaub erklärt das Phänomen der Einkapselung so: Handeln in komplexen Realitäten ist für viele Entscheider gekennzeichnet durch ständig neue Probleme und Schwierigkeiten, durch Misserfolge, Pannen und Enttäuschungen. Es ist kaum verwunderlich, wenn in solchen Konstellationen die Tendenz zur Einkapselung in gut beherrschte Realitätsausschnitte zu beobachten ist. Der frustrierte [Projektmanager] sucht seine Aufgaben nicht mehr nach deren Wichtigkeit und Dringlichkeit aus, sondern nach der individuellen Bewältigbarkeit, also nach der Erfolgswahrscheinlichkeit. Er macht das, was er kann und vergisst, was er machen sollte2. Beide Fehler – vertikale Flucht als auch Einkapselung – können als Verschiebung des Problems betrachtet werden. Peter Senge hat 1990 zehn Handlungsarchetypen beschrieben3. Eine davon nannte er Shifting the Burden. Das eingangs erwähnte Problem der humanitären Organisation liesse sich mit dem Shifting-the-Burden-Archetypus wie folgt darstellen:

Ursprünglich wurde eine Aktionsidee gesucht, also eine Grobbeschreibung der Aktion, mit der man notleidenden Menschen helfen will. Die grundsätzliche Lösung wäre also, den Prozess zu planen, mit dem man helfen will. Stattdessen beschreibt man lieber, wem man helfen will. Das ist eine symptomatische Lösung. Die Vorstellung, man hätte das Geld, das man spenden will, bereits verdient und könnte es nun dem Nutzniesser übergeben, ist sehr angenehm. Immerhin weiss man nun, wem man helfen will und braucht nur noch die Kleinigkeit einer Aktionsbeschreibung. Diese delegiert man und schiebt damit die Entscheidung über den eigenen Arbeitseinsatz hinaus. Je mehr man den Endzustand beschreibt, desto glücklicher werden die Diskussionsteilnehmer und umso weniger sehen sie die Notwendigkeit, einen Arbeitsprozess beschreiben zu müssen. Zwar hat man am Schluss des Tages das Gefühl, etwas erreicht zu haben. Die ursprünglich gestellte Aufgabe ist anscheindend gelöst. Spätestens aber, wenn der Delegierte seine Vorschläge vorstellt, beginnt die Diskussion auf’s Neue, diesmal aber viel heftiger.

1Stefan Strohschneider. Kompetenzdynamik und Kompetenzregulation beim Planen. In S. Strohschneider/R. van der Weth (Hrsg). Ja mach nur einen Plan – Pannen und Fehlschläge – Ursachen, Beispiele, Lösungen. S. 35-51. Verlag Hans Huber. Bern 2002

2Harald Schaub. Exception Error”: Über Fehler und deren Ursachen beim Handeln in Unbestimmtheit und Komplexität. In: gdi impuls 4. Gottlieb Duttweiler Institut, Rüschlikon 1996.

3Peter M. Senge. Die Fünfte Disziplin – Kunst und Praxis der lernenden Organisation. Klett-Cotta. Stuttgart 1996.

Reisen Sie in jeder Jahreszeit in eine andere Region!

Kürzlich wurde mir eine wunderbare Aufgabe gestellt. Vier Personen wollen vierteljährlich eine Reise in eine von vier Regionen unternehmen. Jedes Jahr soll jede Region genau einmal besucht werden. Keine Region soll zweimal hintereinander und je in derselben Jahreszeit besucht werden. Abwechslungsweise sollen die vier Personen die Reisen organisieren. Keine Person soll zweimal hintereinander eine Reise organisieren müssen. Darüber hinaus soll jede Person eine Reise in eine Region und in einer Jahreszeit nur einmal organisieren müssen.

Es wird schnell klar, dass die Reiserei nach vier Jahren die Bedingungen erschöpft hat. Länger als vier Jahre lassen sich die Bedingungen nicht aufrecht erhalten. Trotzdem ist schon nur die Formulierung der Aufgabe ein Problem für sich. Zwar sollten die meisten Menschen rasch verstehen, was Sache ist, aber eine präzise Formulierung aller Bedingungen ist schwierig. Ich bin mir noch nicht sicher, ob obige Aufgabenstellung die Bedingungen vollständig enthält und die Aufgabenstellung eindeutig beschreibt. Erstaunlich, wenn man bedenkt, dass die Situation nur ein paar hundert Möglichkeiten offen lässt, dass es nur um dreimal vier Elemente geht und diese nur während vier Jahren gespielt werden. Für eine so einfache Situation bietet die Formulierung der Anforderungen bereits ein Problem.

Eine mathematische Aufgabe ist in jedem Fall ein Projekt. Zum Beispiel könnte sie am Anfang einer Dissertation stehen. Die Dissertation und damit die Lösung der Aufgabe ist das Projekt. Manchmal sprengt sie die Terminvorgaben. Es gibt Aufgaben, die erst nach Jahrhunderten gelöst werden. Die einfache Aufgabe, zu entscheiden, ob jede gerade Zahl (grösser als 2) die Summe zweier Primzahlen sei, ist seit 1742 immer noch ungelöst (auf die 1 Mio Dollar ausgesetzt ist). Wenn eine mathematische Aufgabe ein Projekt ist und in unserer (einfachen) Reise-Aufgabe die Formulierung der Anforderungen schon Schwierigkeiten macht, wieviel schwieriger ist es, die Anforderungen in einem wirklich komplexen Projekt zu formulieren?

Die Beschäftigung  mit der Problemstellung erhöht unser Wissen, auf was man achten muss, womit sie zu tun haben könnte, welche Zusammenhänge bestehen, usw. Z.B. wird einmal klar, dass wir es bei der Aufgabe mit einer binären Relation auf der Menge der Permutationen von vier Elementen zu tun haben. Es gibt 24 Permutationen von vier Elementen. Man kann sie als Deckbewegungen eines Teraeders interpretieren. Was hat die Reisetätigkeit zweier Paare mit einem Tetraeder zu tun? Es ist genau wie in einem Migrations- und Intergrationsprojekt: die Beschäftigung mit dem Projektgegenstand erhöht unser Wissen, worauf zu achten ist und welche Fragen wir stellen müssen. Es ist unmöglich, am Anfang eines Projekts die richtigen Fragen zu stellen, denn wir haben noch gar nicht das relevante Wissen dazu. In unserer Reiseaufgabe steht am Anfang natürlich die Frage nach den vier Jahresprogrammen. Wenn man sich etwas mit der Aufgabe beschäftigt kommt der Verdacht hoch, dass die Aufgabe nicht lösbar sei. Dann möchte man wissen, warum sie nicht lösbar ist und welches die Lösung ist, die die Bedingungen am wenigsten verletzt. Auch in Migrations- und Integrationsprojekten könnte sich herausstellen, dass die gewünschte Aufgabe nicht so zu erfüllen ist, wie man sich das ursprünglich vorgestellt hatte und auch dort geht es dann darum, die bestmögliche Lösung zu finden. Eine solche Einsicht verändert die Laufzeit des Projekts, stellt die Budget- und Terminvorgaben in Frage und kann zu Konflikten führen.

In unserer Reise-Aufgabe muss man nun die Fragestellung ändern. Aber wie formuliert man die neue Problemstellung? Man stellt z.B. irgend einmal fest, dass zwei Permutationen a und b dann miteinander in Relation stehen, wenn die zweite Stelle von a gleich der dritten Stelle von b ist, nämlich z.B. dann wenn im Sommer Region 3 besucht wurde. Man möchte jetzt wissen, wie viele Permutationspaare sich in einer gewissen Relationsklasse befinden und wie sich zwei Relationsklassen überschneiden. Aber wie formuliert man das? Was ist genau abzuklären? So können auch während eines Projekts Fragen auftauchen, die die Projektmitarbeiter, sowohl auf Kunden- als auch auf Lieferantenseite, nicht genau formulieren können. Man weiss nur, das es da irgend etwas abzuklären gilt. Aber was? So ist die Gefahr gross, dass man einfach mal los testet und prüft und schraubt, einfach in der Hoffnung, einmal auf eine Erkenntnis zu stossen, die genau das ist, wonach man gesucht hat. Das ist natürlich fatal, denn damit kann man viel Zeit verlieren.
Ich möchte damit sagen, dass unser Wissen mit der Projektarbeit zunimmt, und wir erst ab einer gewissen Menge an Wissen überhaupt sagen können, was wir eigentlich erwarten oder eben nicht erwarten. Zielformulierung, Wissen und Beschäftigung mit dem Gegenstand bedingen einander. Ohne dass wir uns eingehend mit dem Projektgegenstand beschäftigt haben, haben wir zu wenig Wissen, um die richtigen Fragen zu stellen und sagen zu können, was wir wollen.

Glauben Sie, Vergessen sei bloss eine Charakterfrage?

Am Samstag musste ich, zusammen mit vier weiteren Leitern, gegen 40 Jugendliche aus allen Herren Länder in Empfang nehmen und war verantwortlich, dass alle ihren Flug nach hause antreten konnten. Die einen flogen bereits um 10 Uhr vormittags, andere am Nachmittag, wieder andere erst um 21 Uhr und drei sogar erst am Sonntag früh. Es war also eine projektartige Übung, die eine entsprechende Planung benötigte. Vorgesehen war, dass die Jugendlichen direkt nach Ankunft entsprechend ihren Check-in-Anforderungen in drei Gruppen aufgeteilt werden. Nachdem alle komplett eingecheckt waren, wollte man sich gemäss Plan bei der Gepäckaufbewahrung wieder treffen. Als der Bus jedoch eintraf wurden wir informiert, dass für die Jugendlichen noch ein Lunchpaket bereit stehe, das sie nach dem Check-in abholen sollten. Also entschieden wir, dass wir uns statt bei der Gepäckaufbewahrung wieder beim Bus treffen. Das ist eine unvorhergesehene Planänderung. So etwas kann leicht dazu führen, dass man die Situation als komplex einstuft, weil man viele “Baustellen” beachten muss. Aber tatsächlich hat das nichts mit Komplexität zu tun. Die Information, dass der ursprünglich geplante Treffpunkt bei der Gepäckaufbewahrung gestrichen wurde und wir uns alle nach neuem Plan wieder zum Bus zurück begeben, erreichte meine Partnerin nicht, die zum Zeitpunkt der Planänderung mit drei Jugendlichen unterwegs war. Sie wartete wie ursprünglich verabredet bei der Gepäckaufbewahrung. Die unvorhergesehene Planänderung führte zu einer leichten Unruhe, was zur Folge hatte, dass ich mich auf die aktuellen Ereignisse konzentrierte und völlig vergass, meine Partnerin zu informieren, dass sie wieder zum Bus zurück kommen soll.

Was war geschehen? Zunächst einmal unterlag ich klar dem Fehler, das aktuelle Motiv überbewertet zu haben. Man konzentriert sich auf die aktuellen Ereignisse und versucht, die Probleme zu lösen, die man hat und nicht diejenigen, die man nicht hat. Dietrich Dörner geht in der Logik des Misslingens oft und gern auf diesem Fehler ein, den man in komplexen Situationen sehr häufig begeht1. Gründe für die Überbewertung der aktuellen Situation sind unter anderem wohl die uns eigene Langsamkeit des Denkens (nicht nur bei Bernern!), die geringe Zahl gleichzeitig zu verarbeitenden Informationen und die beschränkte Zuflusskapazität vom und zum Gedächtnis. Die Überbewertung des aktuellen Motivs ist ein wissensbasierter Fehler. In der oben beschriebenen Situation war ich aber keineswegs nur auf der wissensbasierten Ebene. Viel lief auch auf der fähigkeitsbasierten Ebene ab. Siehe dazu den Blog Eintrag Wo kann in Projekten und Unternehmen etwas schief gehen? Reason berichtet von Interferenzfehler auf der fähigkeitsbasierten Ebene2. Zwei gleichzeitig aktive Pläne können sich bei der Kontrolle über die Handlungen in die Quere kommen. Wird ein Plan überarbeitet oder verändert, dann übernimmt der neue Plan sofort die Kontrolle über die Effektoren und kippt den alten Plan aus der Handlungssequenz, obwohl dieser in räumlich oder zeitlich abgegrenzten Teilen des Projekts noch aktiv sein kann. Ein anderer Fehler, der in solchen Situationen auftritt, nennt sich Cue-dependent forgetting. Er beruht auf dem Fehlen eines effektiven Abrufreizes und ist damit nahe verwandt mit der Übergewichtung des aktuellen Motivs: es gibt keine Abrufreize für Probleme, die man zwar gespeichert hat, aber die im Hier und Jetzt keine Rolle spielen. Es ist also kein wirkliches Vergessen, sondern lediglich eine Zugriffsstörung3.

Was können wir dagegen tun? Es gibt sicher viele schöne Tracking-Software, die einem an solche verschütteten Informationen mit Bells and Whistles erinnert. Aber wer hat schon Zeit sich hinzusetzen und diese Systeme zu füttern. Die Anzahl der Reporting Systeme, die ein Projektmanager füttern muss, nimmt ja ständig zu, ohne effektiv zur Verbesserung der Kosten- und Termintreue beizutragen.

1Dietrich Dörner. Die Logik des Misslingens – strategisches Denken in komplexen Situationen. Rowohl Taschenbuch. Reinbek bei Hamburg 1992.
2James Reason. Human Error. Cambridge University Press. 1990 and 2007
3Tulving, E. (1974). Cue-dependent forgetting. American Scientist, 62, 74-82
Einen guten Überblick geben Dominika Posor, Sarah Wennemer, Uta Kirschner von der Universität Münster in Gedächtnis ???: förderliche Lernbedingungen und Theorien des Vergessens

Integration ist Lernen

Kürzlich kaufte ich mir ein Garmin etrex GPS zum Inline Skaten. Die Vision war, dass ich eingeben kann, ich möchte von A nach B und das Gerät würde mich über asphaltierte Fahrrad- und Fussgängerwege lenken. Natürlich wusste ich, dass es so etwas (noch) nicht gibt (warum eigentlich? Technisch wäre das ja einfach realisierbar). Ein Unternehmen muss laufend innovative Angebote auf den Markt bringen. Es kann auch dann zu einem Wettbewerbsvorteil kommen, wenn das Angebot noch nicht ganz den Visionen entspricht oder sogar noch wenig ausgereift ist. Das Unternehmen, das mit einer Idee zuerst auf dem Markt ist, hat meistens die Nase vorn. Aus demselben Grund kaufte ich das GPS trotz meines Wissens, dass es meine Anforderungen nicht erfüllt. Ich war aber neugierig, was sich damit machen lässt. Nun bin ich Inline-GPS-Besitzer und als das lebt es sich anders. Natürlich ist es keine tiefgreifende Veränderung meines Lebens. Aber dennoch muss ich das Gerät in mein Leben einbauen. Es ist ein typisches Intergrationsprojekt. Genauso ergeht es einem Unternehmen, das eine neue Technologie integriert, um ein innovatives Angebot machen zu können oder seine Prozesse innovativ zu verändern.
Am Anfang war zwar eine konkrete Vision oder ein konkreter Wunsch, was das System können sollte. Daraus lässt sich ein vollständiger Anforderungskatalog erstellen und eine sehr genaue Spezifikation schreiben. Alles für die Katz’. Nachdem ich das Gerät hatte, begann ich zu lernen, was es überhaupt kann, bzw. was es alles nicht kann.
Beispiel 1: Beim Kauf zeigte mir der Verkäufer das beiliegende Kartenmaterial. Da heisst es “Topografische Karte; Grundmassstäbe 1:50 000 und zum Teil 1:25 000″. Das ist doch ‘was. Sofort stellte ich mir die Topologische Karte der Schweiz vor und machte ziemlich grosse Augen, als ich sah, dass 6 Meter breite und asphaltierte Strassen auf der Garmin-Karte bloss als Strich eingezeichnet ist, als wäre es ein Feldweg. Dass sich die modernen Kartenangebote nicht auf Garmin Geräte übertragen lassen, wusste ich auch nicht, denn ich dachte, dass ein bisher erfolgreiches Unternehmen kaum den Fehler begeht, sich mit einem proprietären Standard zu verschliessen.
Beispiel 2: Wenn Sie es im Modus “Fussgänger – der Strasse folgen – Mautstrassen vermeiden” betreiben, werden Sie laufend auf die Autobahn gewiesen. Sogar dann, wenn Sie zwei Wegepunkte eingegeben haben, die z.B. 20 Meter auseinander liegen. Das Gerät schickt Sie nach Passieren des ersten Wegepunktes über alle erdenklichen Autobahnen und Überlandstrassen zum Wegepunkt 2, nur nicht direkt. Ich lernte, dass ich das Gerät im Modus “Fussgänger – Luftlinie – Mautstrassen vermeiden” betreiben und die Wegepunkte auf meiner Route derart wählen muss, dass jeweils der nächste per Luftlinie erreichbar ist. Wofür die Einstellungen “Fussgänger” und “Mautstrassen vermeiden” gut sind, habe ich noch nicht gelernt.
In einem Integrationsprojekt geht es also darum, das neue System immer besser kennen zu lernen und zu lernen, es möglichst gewinnbringend einzusetzen. Ein Intergrationsprojekt ist somit ein Lernprojekt. Ein Modell eines Intergationsprojekts ist weitgehend ein Modell des Lernens.

Technorati Profile

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?
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.
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

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. Sie erinnern sich an den Beitrag Staus im Projektmanagement. Die lokalen Projektführer sind zwischen den zentralen Entwicklungsabteilungen und dem Kunden “eingeklemmt”. Sie haben fast keine Einflussmöglichkeiten. Wenn ihr Projekt nicht gross oder wichtig genug, dann erhalten sie kaum Support aus der Entwicklung.
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.
Sie erinnern sich an das Grundmodell von Migrations- und Integrationsprojekten? Siehe Komplexität im Projektmanagement? Dort hatten wir den Feedbackloop

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:

Das Diagramm lässt sich durch Anklicken vergrössern. 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