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.