Zum Auftakt der PMCamp-Saison beschäftige ich mich wieder vermehrt mit Fragen zum Projektmanagement. Dabei ist mir eingefallen, wie wichtig es ist, Projekt und Betrieb zu trennen.
Der Rework Cycle
Ich habe hier auch schon darauf hingewiesen, dass Projekte oft gar kein Ende haben. Es gibt hier noch etwas zu flicken und dort etwas aufzuräumen, und so zieht sich der Abschluss des Projekts oft über Wochen und Monate hin. Das hat mit dem Rework Cycle zu tun, dem bestuntersuchten Phänomen des Projektmanagements. Im Nachhinein entpuppen sich bereits erledigte Arbeiten manchmal als mangel- oder gar fehlerhaft und müssen nachgebessert werden. Das kann zu beträchtlichen Verzögerungen führen. Ich habe hier den Rework Cycle schon mehrmals vorgestellt(1).
Verspätet auftauchende Mängel führen zu einem „langen Schwanz“ von Nacharbeiten. Auf der einen Seite ist der Druck des Controllings, das Projekt abzuschliessen, auf der anderen Seite weigert sich der Betrieb, die Mängel zu erben. Das führt dann zu einer manchmal monatelangen Überlagerung von Projekt und Betrieb.
Parallel- oder Schattenorganisationen
Vor allem in Weltkonzernen kann das oft beobachtet werden, wenn z. B. verschiedene Regionen ein System gestaffelt einführen. Während das Integrationsprojekt in Region A bereits abgeschlossen sein sollte, startet es in Region B gerade. Daher ist es nicht so wichtig, dass das Projekt in der Region A auch wirklich abgeschlossen wird. Schlimmstenfalls können Nacharbeiten zum Projekt in der Region B gerechnet werden, das fällt ja gar nicht auf. Während in Region A das System formal bereits dem Betrieb übergeben wurde, ist es in Region B noch in Einführung begriffen. Testuser in Region B wenden sich dann plötzlich an den Support in Region A, etc.
Solcherlei Vermischungen können oft zu einem jahrelangen Überlagerungszustand von Projekt und Betrieb führen. Ich habe schon Unternehmen gesehen, in denen das „Projekt“ zu einer ständigen Organisationseinheit wurde, die parallel zum Betrieb („Maintenance& Support“) existierte. Organigramme führten das Projekt tatsächlich als Kästchen und subordinierten es einem Linienmanager, obwohl ein Projekt definitionsgemäss zeitlich begrenzt sein sollte.
Das Projekt degenerierte so zu einer Parallelsupportorganisation. Es ist ein Führungsentscheid, dass ab einem gewissen Zeitpunkt das Projekt beendet ist und keine weiteren Nachbesserungen mehr erwartet und gestattet sind.
(1) Addor, P. Projekten in den Rachen geschaut. August 2008
und Addor, P. Die effektivste Massnahme, um Projektverzögerungen zu minimieren. August 2014