Crashing / Verdichtung

Als ich diesen Begriff das erste Mal gesehen hatte, war ich mir nicht sicher, ob sich da der Fehlerteufel eingeschlichen hatte: Warum soll “Crashing” im Projektmanagement dabei helfen, die Projektdauer zu verkürzen? Die erste Assoziation, die mich befiel, war eher “das Projekt an die Wand fahren”, womit ein Projekt natürlich auch unsanft beendet werden kann. Doch das ist nicht damit gemeint.

Die deutsche Ausgabe des Project Management Body of Knowledge übersetzt den Begriff als “Verdichtung”, und gemeint ist damit eine Methode zur Verkürzung der Projektgesamtdauer. Dies wird in der Regel dadurch erzielt, dass die einzelnen Vorgänge weniger Zeit in Anspruch nehmen sollen, zum Beispiel dadurch, dass mehr Ressourcen auf sie gesetzt werden. Während der Umfang des Projektes, der Scope, gleich bleibt, führt Crashing somit zu höheren Kosten. Es sei denn, es kann von den Ressourcen, die an nicht-kritischen Vorgängen arbeiten, etwas abgezogen werden, damit diese an kritischen Vorgängen arbeiten.

In der Realität kann diese Option rein theoretischer Natur sein. Nicht umsonst sagt man, dass man mit 9 Frauen auch kein Baby in einem Monat kriegen kann. Auch sitzen eventuell Ressourcen mit komplett anderen Qualifikationen an den anderen Vorgängen, die somit gar nicht an den kritischen Vorgängen arbeiten können. Crashing kann aber auch bedeuten, dass man sein Team Mehrarbeit leisten lässt; insbesondere in der Softwarewelt sind Wochenendschichten keine Ausnahme, vor allem wenn es kostenlos Pizza gibt.

Zum Crashing kann auch das Fast Tracking eingesetzt werden, das ich demnächst erklären werde.