Schlagwort-Archive: Rework Cycle

Die effektivste Massnahme, um Projektverzögerungen zu minimieren

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

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

ProjektLaufzeit_Rework_LancyDer 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

Die 6 wichtigsten systemischen Aspekte des Projektmanagements

Diese sechs systemischen Aspekte sollte jede Person kennen, die sich mit (Projekt-)Management befasst:

Ad-hocismus1: Wenn Menschen etwas machen müssen, dann machen sie sich sofort dahinter, ohne zuerst lange zu überlegen, zu planen und abzuschätzen. Beispiel: Zusammenbauen eines IKEA-Möbels. Was immer man tut, es scheint einem zu gering, um z.B. über Risiken nachzudenken. Das ist nur etwas für grosse Dinge und benötigt anscheindend viel Zeit und Aufwand. Wenn Planung und andere administrative Dinge nicht explizit vorgeschrieben sind, dann geht man lieber gleich an’s Eingemachte und versucht, es schnell hinter sich zu bringen.

Je mehr Arbeiten zu erledigen sind, desto mehr Arbeit gibt es zu tun. Je mehr wir daran arbeiten, desto mehr Arbeit sollten erledigt sein, aber desto mehr wissen wir über den Gegenstand, stellen Fragen, müssen testen und abklären und haben immer mehr zu tun
Je mehr Arbeiten zu erledigen sind, desto mehr Arbeit gibt es zu tun. Je mehr wir daran arbeiten, desto mehr Arbeit sollten erledigt sein, aber desto mehr wissen wir über den Gegenstand, stellen Fragen, müssen testen und abklären und haben immer mehr zu tun

Wissenszunahme2: Während man am Projektgegenstand arbeitet, lernt man diesen immer besser kennen und versteht immer mehr, worauf man achten muss. Anfängliche Planungen und Überlegungen sind schnell überholt oder erweisen sich gar als falsch. Nicht selten startet ein Projekt als reines Technikunterfangen und endet in einem Prozess Redesign, der Machtstrukturen zur Disposition stellt.

Übermässiges Vertrauen3: Wir haben immer zuviel Vertrauen in unsere Fähigkeiten, bzw. unterschätzen den Komplexitätsgrad unserer Vorhaben laufend. Infolge der Wissenszunahme erweisen sich alle Projekte – vom Zusammenbau eines IKEA-Möbels bis zum Mondflug – als kniffliger, als erwartet. Wie oft haben wir schon gedacht, dass ein Vorhaben schnell erledigt werden kann und mussten dann feststellen, dass wir uns massiv getäuscht haben?

Unvorhergesehenes4: Unvorhergesehenes ist der Feind einer jeden Planung. Ich spreche nicht von Risiken. Diese sind zumindest „vorherdenkbar“, wenn man auch nicht weiss, ob und wann sie eintreten. Unvorhergesehen sind Ereignisse, an die man nie im Leben gedacht hätte. Daher auch keinen Plan B in der Schublade hat, wenn sie eintreffen. Unvorhergesehenes verlängert die Laufzeit der Projekte und verringert jede Marge.

Kompetenzmotivation5: Je mehr Unvorhergesehenes auftaucht und je weniger unsere Pläne und unsere Vorstellungen der Realität entsprechen, desto schlechter steht es mit unserer Kompetenzhygiene. Wir zweifeln (zu recht) an uns und unseren Fähigkeiten und haben nur noch ein Ziel: Unser Selbstvertrauen und Kompetenzgefühl wieder herzustellen. Dazu kennen wir verschiedene (zweifelhafte) Strategien. Das Präkäre ist aber, dass wir uns dann überhaupt nicht mehr um die Sache kümmern, sondern nur noch unser angeschlagenes Selbstwertgefühl pflegen.

Rework Cycle6: Menschen sind keine Maschinen, und sogar Maschinen können Fehler machen. Unsere Arbeit erreicht nie 100% Qualität. Jedem von uns unterlaufen Patzer und Schnitzer, auch wenn wir uns noch so Mühe geben. Je turbulenter die Situation, je grösser der Zeitdruck und je schlechter unsere Motivation, desto mehr Fehler passieren. Das führt zunächst zu unentdeckten Fehlern in Arbeiten, die wir längst als erledigt betrachten. Werden die Fehler entdeckt, müssen wir sie ausbessern, was wiederum Zeit (und Nerven) kostet. Sogar beim Ausbessern können wieder Fehler passieren, usw. Und so durchlaufen wir dann mehrere „Ehrenrunden“, bis wir schliesslich zwei- oder dreimal so viele Aufwendungen hatten, wie anfänglich angenommen.

1siehe z.B. D. Dörner. Die Logik des Misslingens – Strategisches Denken in komplexen Situationen. Rowohlt. Reinbek b. Hamburg, 1992. Seiten 42, 94, 294.
2
P. Addor. Projektdynamik – Komplexität im Alltag. Liebig Verlag. Frauenfeld 2010. Seiten 57, 61
3
siehe z.B. H. Beck. Die Logik des Irrtums – Wie uns das Gehirn täglich ein Schnippchen schlägt. Verlag NZZ, Zürich 2008, Seite 63
4
siehe z.B. De Meyer, Loch, Pich. Managing Project Uncertainty – From Variation to Chaos. MIT SLOAN MANAGEMENT REVIEW, 2002
5
S. Strohschneider. Ja, mch‘ nur einen Plan. Inst. f. theoretische Psychologie der Univ. Bamberg, 2001
6
siehe z.B. P. Lancy. Development Inefficiencies – Managing the Rework Cycles in Complex Projects. ACLN #55, 1997

Der Projektmanager als Vordenker

Der Einfluss des Projektmanagers auf

  • Kosten
  • Termine
  • Qualität
  • Produktivität
  • Entdeckungsrate von Qualitätsmängel

ist beträchtlich, aber seine Steuerungsmöglichkeit dieser Parameter ist gering. Es ist ausserodentlich wichtig, dass ein Projektmanager das intuituv weiss. Viele meiner Studenten sind frustriert, wenn ich Ihnen das erkläre, ohne ultimative Handlungsanweisungen anzubieten. Das Einzige und wohl Beste, was ein Projektmanager tun kann ist, seine Pläne, Vorstellungen und Absichten immer und immer wieder mit Nachdruck zu allen Stakeholders und mit ihrer Hilfe zu kommunizieren1. „Stakeholders“ bezeichnet nicht nur die Leute im Projektteam, sondern vor allem auch Personen in anderen Unternehmen (Kunden-, Lieferantenunternehmen) sowie dem Projekt zugewandte Personen wie Account Managers, Quality Managers, Controllers, Line Managers, etc. Der Projektmanager ist Vordenker und setzt die Stakeholders auch ein, um seine Visionen und Vorstellungen weiter zu tragen.

Der Projektmanager muss aber sicherstellen, dass er nichts Unrealistisches oder Widersprüchliches kommuniziert. Man kann nicht höchste Qualität in minimaler Zeit ausliefern. Die Sicherstellung von Qualität braucht Zeit. Wenn das Projekt beschleunigt wird, treten Qualitätsmängel auf, die erst nach und nach entdeckt werden und vielleicht erst gegen Ende des Projekts zuschlagen.

Abbildung 1
Abbildung 1

Die Entdeckungsrate der Qualitätsmängel hat einen ausserordentlichen Einfluss auf die Laufzeit des Projekts, wie Abbildungs 1 zeigt. Ein Projekt, für dessen Laufzeit ein Jahr geplant war und in dem die durchschnittliche Qualität bei 80% liegt, dauert effektiv zwei Jahre, wenn die Qualitätsmängel erst nach acht Monate entdeckt werden. Werden sie hingegen bereits nach drei Monaten entdeckt, ändert sich die Laufzeit des Projekts nicht wesentlich.

In Integrations- und Migrationsprojekten werden Qualitätsmängel schneller entdeckt, als in Entwicklungsprojekten. Nehmen wir an, die Entdeckungsrate beträgt 0.25 (3 Monate bei einem 1-Jahres-Projekt) und das Projekt habe 1,5 Mal so lange gedauert, wie geplant. Dann lag die durchschnittliche Qualität bei ca. 60%!

1Lancy, Peter. Development Inefficiencies – Managing The „Rework Cycle“ in Complex Projects. ACLN 55/1997

Das Alte war gut. Die Entwickler des Neuen haben keine Ahnung!

In seinem Buch Die Kritische Kette sinniert Eliyahu Goldratt auf der Basis der Theory of Constraints über die Wahrscheinlichkeit nach, mit der ein Task, eine Phase oder ein ganzes Projekt nach einer bestimmten Zeit terminiert wird1. Er macht dabei den Vergleich zu dem Nachhauseweg nach der Arbeit. Unter 20 Minuten können Sie nicht zu hause sein. Meist sind es 30 Minuten. Wenn viel Verkehr ist, dann benötigen Sie sogar 40 Minuten. Und wenn Sie noch einen Kollegen treffen und mit ihm ein Bier trinken, sind Sie nicht vor 120 Minuten zu hause. Goldratt fragt dann, mit welcher Terminierungswahrscheinlichkeit wir planen sollen. Meines Erachtens ist das in Migrations- und Integrationsprojekten (MIP) die falsche Frage. Ganz abgesehen davon, dass Sie die Terminierungswahrscheinlichkeiten für einzelne Tasks und Phasen in MIP gar nicht kennen, werden typische MIP-Tasks nie fertig. Das kommt daher, dass z.B. bei einer Migration ein bestehendes System abgelöst werden soll und das neue System den Kunden vorerst niemals zufrieden stellen kann, weil es doch etwas anderes ist, als das ihm vertraute alte System. Stets vergleicht er das neue System mit dem abzulösenden, dem er tief in seinem Herzen eine Träne nachweint. Zudem kennt er das neue System noch nicht so gut und muss die Bedienung vieler Funktionen zuerst kennen lernen. Wer von uns kennt das nicht? Bis man mit einem Gerät wirklich vertraut ist und seine Stärken und Macken kennt, muss man es viele Male bedient haben, um nicht zu sagen, man müsse es in sein Leben integriert haben. Unsere Fernseher, Waschmaschinen, Autos, PCs oder Musikanlagen sind doch ein Teil unseres Lebens geworden. Wenn wir ein solches Teil jemals ersetzen müssen, finden wir eine Menge von Mängel am neuen Teil. Aber nach paar Wochen ist auch das neue Gerät ein Teil unseres Lebens geworden, und wir wissen schon gar nicht mehr, wie das alte bedient werden musste. Das Projekt „neues Gerät anschaffen und in Betrieb nehmen“ ist beendet, wenn das neue Gerät angeschlossen und betriebsbereit ist. Genau in dieser Phase haben wir allerlei zu bemängeln und herum zu nörgeln. Ich nenne das das Umgewöhnungssyndrom. Leider können wir als kleine Endkunden dem Lieferanten das Gerät nicht um die Ohren schlagen. Wenn aber z.B. eine Bank von einem Systemhaus eine neue Bankenlösung kauft und für die Migration Dutzende, wenn nicht Hunderte von Millionen bezahlt, dann kann sie den Lieferanten solange festnageln, bis sie sich endlich an das neue System gewöhnt hat. Das verzögert das Projekt ungemein.

Sehr schön studieren kann man den eben beschriebenen Effekt bei Acceptance Tests, die ein wichtiger Teil von jedem MIP sind. Dazu wird ein Testdrehbuch benötig, das die durchzuführenden Tests enthält zusammen mit Angaben über Durchführungsdauer, Start- und Endzeitpunkt, Testverantwortliche, zu erwartende Resultate, etc. Sollen z.B. 100 Tests durchgeführt werden die je 15 Minuten dauern, dann wird die Projektplanung 25 Stunden vorsehen. Erfahrungsgemäss sieht die Planung und die dazugehörende Fortschrittskurve so aus:

 

Eine solche Planung passt eher in ein Straflager. Auch noch so arbeitsame Mitarbeiter gehen mal einen Kaffee holen oder müssen die Toilette besuchen. Ab und zu muss das Testdrehbuch diskutiert oder ein Bedienungsmanual konsultiert werden. Zudem kommen Telefone und die Mails müssen gecheckt werden. Die effektive Produktivität einer Ressource beträgt normalerweise zwischen 70 und 80 Prozent.
In den letzten paar Jahren habe ich die effektiven Testfortschritte aus mehreren Projekten ausgewertet und stets folgendes gefunden:

 

Am Anfang wird ein Initialaufwand dazu führen, dass die Ausführung der Tests der Planung etwas hinten her hinkt, weil der Projektleiter die Rüstzeiten vergessen hat. Diese sind aber schnell eingeholt, und weil alles so gut geht überholen die aktuellen Tests die Planung sogar. Das kommt daher, dass man zuerst die einfachen und unproblematischen Tests durchführt. Der Projektleiter muss bei jeder Steeringboard-Sitzung den Projektfortschritt vorweisen. Er wird quasi am Fortschritt gemessen. Daher wird er solange unproblematische Tasks oder Pfade bearbeiten, wie er kann. Goldratt schreibt: Weil ein Fortschritt auf einem Pfad eine Verzögerung auf einem anderen Pfad kompensiert. Also scheint ein rascher Fortschritt auf einem beliebigen [auch nicht-kritischen] Pfad angebracht2. Das schafft Vertrauen. Doch dann beginnt es zu harzen. Einige Tests müssen wiederholt werden. Schwererwiegende Probleme müssen sogar mit der Entwicklung besprochen werden. Es gibt Fälle, in denen das Verhalten des Systems zunächst unerklärlich ist und analysiert werden muss. Das kostet viel Zeit, die nie mehr eingeholt werden kann. Und schliesslich wird der Kunde genau in diesem Zeitpunkt, in welchem die Fortschrittskurve abflacht, vom Umgewöhnungssyndrom erfasst. Das neue System passt ihm (noch) nicht so recht, weil er es noch nicht kennt. Er möchte, dass es wie das alte funktioniert und wird viele Einwände, Wünsche oder zumindest Fragen haben. Er wird verlangen, dass Testfälle ein wenig verändert und wiederholt werden. Das Problem ist also weniger die Terminierungswahrscheinlichkeit, die die Theory of Constraints untersucht, noch der Rework Cycle, wie er von System Dynamics vorausgesagt wird. Das Problem in Migrations- und Integrationsprojekten ist das Umgewöhnungssyndrom. Daher werden die Acceptance Tests nie fertig. Man muss sie irgend einmal einfach „gewaltsam“ als abgeschlossen erklären. Ganz ähnlich verhält es sich mit ganzen Migrations- und Integrationsprojekten. Auch diese werden nie so richtig fertig.

1Eliyahu Goldratt. Die Kritische Kette – Das neue Konzept im Projektmanagement. Campus Verlag. Frankfurt a.M. 2002.
2 ebenda, S. 80.

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