Der „Rework Cycle“ ist eines der am besten untersuchten Phänomene des Projektmanagements. Ich habe schon mehrmals über den Rework Cycle geschrieben, z.B. hier
Die effektivste Massnahme, um Projektverzögerungen zu minimieren
und hier
Projekten in den Rachen geschaut .
Beim Rework Cycle handelt es sich um die Tatsache, dass erledigte Arbeit nicht immer endgültig ist. Es kann sich nachträglich herausstellen, dass sie Fehler enthält, und dass sie deshalb nachgearbeitet werden muss. Zusätzlich können die Rahmenbedingungen des Projekts ändern, so dass gewisse Resultate überarbeitet werden müssen.
Das führt in jedem Fall zu ungeplanten zusätzlichen Aufwänden.
Das Grundmodell
Diesmal will ich auf eine Konsequenz des Rework Cycle eingehen, die im Englischen „Tipping Point“ genannt wird, auf Deutsch vielleicht mit „Kipppunkt“ übersetzt. Es gibt Projekte, die nie fertig werden, während andere zwar einmal abgeschlossen werden können, aber nur mit grosser Verzögerung. Das kann daher kommen, dass das Projekt mehrmals seinen Kipppunkt überschreitet.
Die herkömmliche Rework-Cycle-Struktur eines Projekts sieht so aus.
Erledigte Arbeiten können sich als fehlerhaft oder überholt herausstellen, was zur Folge hat, dass sie korrigiert oder nachgebessert werden müssen. Manchmal wird das zufällig entdeckt, manchmal gibt es tatsächlich Quality Assurements. Vor allem in IT Migrations- und Integrationsprojekten, die hauptsächlich aus Tests bestehen, zeigt ein nicht bestandener Test fehlerhafte Arbeiten an. Die Software muss nachgebessert und der Test wiederholt werden.
Zusätzlich generierte Arbeiten
Bestandene Tests weisen darauf hin, dass die Arbeiten endgültig erledigt sind. Sie fliessen dann quasi in den Bestand der „released work“. Es ist also der Qualitätssicherungsprozess, der die erledigten Arbeiten freigibt und somit das Projekt vorantreibt.
Auf der anderen Seite verzögert jede Nachbesserung das Projekt. Dazu kommt, dass jedes Mal, wenn eine fehlerhafte Arbeit entdeckt wird, neue zusätzliche Arbeit generiert wird. Im Fall der IT Migrations- und Integrationsprojekte nennen sich die zusätzlichen Arbeiten Regressionstests. Ist einmal ein Softwarefehler erkannt, so muss er nachgebessert werden. Danach genügt es nicht, denselben Test noch einmal zu fahren, denn durch die Nachbesserung wurden ja vielleicht in ganz anderen Modulen neue Fehler eingebaut. Daher müssen weitergehende Tests entwickelt und durchgeführt werden. Das sind grundsätzliche neue, ungeplante Arbeiten. Im der Abbildung heisst die Ursache solcher neuen Arbeiten „Ripple Effect“.
Während also der Loop B1 das Projekt vorantreibt, bremst der Loop R1 das Projekt aus. Je nachdem, welcher der beiden Loops überwiegt, ist das Projekt unterhalb der Kipppunktlinie oder oberhalb. Unterhalb bedeutet, dass es dem Ende zustrebt. Oberhalb entweicht es in den Zustand des nie Fertigwerdens.
Die Kipplinie
Die Linie ist in einem Koordinatensystem, welches auf der waagrechten Achse den Fertigstellungsgrad zur Zeit t-1 abträgt und auf der senkrechten Achse den Fertigstellungsgrad zur Zeit t, also zum jetzigen Zeitpunkt. Der Fertigstellungsgrad berechnet sich aus dem Quotient der noch zu erledigenden Arbeitet und der zu Beginn vorgesehenen Arbeiten. Zu Beginn, wenn noch nichts abgearbeitet ist, beträgt also der Fertigstellungsgrad 1.
Die Zeit könnte z.B. in Tagen gemessen sein, so dass also t-1 gestern war und t heute. Ist der Fertigstellungsgrad heute etwas kleiner als gestern, befindet sich das Projekt unterhalb der Kipppunktlinie, die hier als Diagonale eingezeichnet ist und das Projekt ist auf gutem Weg. Umgekehrt droht das Projekt aus dem Ruder zu laufen, wenn der Fertigstellungsgrad heute grösser ist als gestern.
Häufig kommt es vor, dass das Projekt die Kipppunktlinie mehrmals kreuzt, um dann schliesslich oberhalb der Linie zu bleiben. Zunächst kommt es zu Oszillationen, indem mehrere unvorhergesehene Ereignisse das Projekt immer wieder zurück werfen, die Rückstände aber jedes Mal aufgeholt werden können. Schliesslich wird aber doch immer mehr Arbeit generiert, als abgearbeitet werden kann und das Projekt muss abgebrochen werden.
Dass das tatsächlich beobachtet werden kann, zeigt das Beispiel der US-Kraftwerke „Watts Bar“. Das Projekt hat die 80%-Linie knapp überschritten. Danach fiel es wieder zurück und musste nach ca. 8 Jahren abgebrochen werden. Vermutlich sähe das entsprechende Diagramm des Berliner Flughafens ganz ähnlich aus.
(Alle Illustrationen stammen aus der Präsentation von David N. Ford. Tipping Point Dynamics in Large Development Projects )