Am PM Camp in München, Ende Juli 2014, habe ich den Rework Cycle vorgestellt. Im Prinzip ist es ein Hauptschlüssel für erfolgreiches Projektmanagement. Das Rework Cycle Modell geht davon aus, dass vermeintlich erledigte Arbeiten nachgebessert oder wiederholt werden müssen, z.B. wegen Fehlern oder weil Policies geändert haben.

Der Rework Cycle

Der Bauingenieur David Ford berichtet von zwei Atomkraftwerkbauten (1). Während der Bauzeit flossen aus Erfahrungen beim Betrieb anderer AKW neue Bauvorschriften ein. Ich konnte das in meinen IT-Migrationsprojekten bestätigen. Die Systeme, die wir installierten, waren kurz vorher woanders in Betrieb genommen worden. Uns erreichten Meldungen über Laufzeitfehler, die unter Last auftraten. Das führte dazu, dass wir gewisse Tests wiederholen mussten, neue Lastverteilungsmassnahmen einbauen oder die geplanten Konfigurationen ändern mussten. Solche unvorhergesehenen Massnahmen sind die Ursache des Rework Cycle.

Die in realen Projekten gewonnen Daten stimmen so gut mit der Simulation des Modells überein, dass es heute ausser Zweifel steht, dass der Rework Cycle in jedem Projekt auftritt und es aufbläst. Wer den Rework Cycle ausser Acht lässt, wird sich regelmässig über Projekte wundern, die ihr terminliches Ziel nicht erreicht haben und die Ursache in Bereichen suchen, die gar nichts mit dem Problem zu tun haben, z.B. Kommunikation oder Management Awareness.

Wie umgeht man den Rework Cycle?

Gar nicht! Er ist Gesetz. Man kann aber die terminverzögernden Auswirkungen dämpfen, wenn man das Modell kennt. Dieses geht davon aus, dass die durchgeführten Arbeiten nicht gleich auf den Haufen „Erledigt“ kommen, sondern zuerst auf einen Haufen „zu begutachten“. Erst diejenigen Arbeiten, die sich bei der Kontrolle als gut erweisen, kommen auf den Haufen „Erledigt“. Die anderen müssen nachgebessert oder wiederholt werden. Sie kommen daher vorläufig auf den Haufen „Rework“.

<a href=”

“>

Man sieht nun deutlich: Das Projekt wird nur dadurch fertig, indem man sich des Haufens „zu begutachten“ annimmt. Natürlich müssen die Originalarbeiten auch gemacht werden, aber „durchgewunken“ werden sie erst durch die Kontrolle. Das bedeutet, dass häufige Kontrollen das Projekt mehr voranbringen, als z.B. nur eine einzige Endkontrolle. Peter Lancy von der PA Consulting Group will das sogar genau wissen (2). Er hat gezeigt, wie sich die Laufzeit eines Projekts erhöht, wenn nur eine „grosse“ Schlusskontrolle, statt vier über das Projekt verteilte Kontrollen, gemacht wird. Aus seiner Grafik entnimmt man z.B., dass ein Projekt, in welchem die „Qualität“ (= Anteil an Arbeiten, die bei der Kontrolle auf den Haufen „Erledigt“ kommen) 0.85 beträgt dreimal länger geht als geplant, wenn nur eine Kontrolle gemacht wird und unwesentlich länger als geplant, wenn vier Kontrollen gemacht werden.

<a href=”

“>

Der Anteil derjenigen Arbeiten, die bei der Kontrolle auf den Haufen “Erledigt” kommen, werden in Lancys Grafik “Qualität” genannt. In der Tat hängt es von diesem Anteil ab, ob das Projekt je fertig gestellt werden kann oder nicht. Es gibt einen “Kipp-Anteil” (sog. tipping point), bei welchem das Projekt sozusagen an Ort tritt. Ist der Anteil höher als dieser Kippanteil, kommt das Projekt voran, andernfalls fällt es immer mehr zurück.

Damit heisst der Haupterfolgsfaktor: In einem Projekt so oft Reviews und Kontrollen machen, wie es nur geht! Das klingt einfach und selbstverständlich. Aber unterlassene Kontrollen sind der Hauptgrund für Verzögerungen in Projekten!

(1) Taylor, T./Ford, D. Tipping point failure and robustness in single development projects. Syst. Dyn. Rev. 22, 51–71, (2006)

(2) Lancy, P. Development Inefficienties - Managing the “Rework Cycle” in Complex Projects. Australian Construction Law Newsletter ACLN, Issue #55, 1997