Im vorhergehenden Teil dieser Serie stellte ich die zentralen Mechanismen des Critical Chain Project Management in Multiprojektumgebungen vor. Die Staffelung der Projekte anhand der Virtual-Drum-Ressource, das Staffelläufer-Prinzip und die eindeutige Priorisierung anhand des Pufferverbrauchs gewährleisten, dass das gesamte Projektportfolio mit maximaler Geschwindigkeit bearbeitet wird.

Im Folgenden beschreibe ich, wie man diese Mechanismen operativ bei der Projektplanung in einer Multiprojektumgebung umsetzt. Dabei sind folgende Fragen zu beantworten:

1. Wie detailliert soll ein Projektplan sein, damit sowohl das einzelne Projekt als auch die Multiprojektumgebung möglichst gut gesteuert werden können?
2. Wie kann in einem Projekt ausreichend Sicherheit eingeplant werden, um gegen die Variabilität des Projektverlaufs und das Auftreten von Murphy's Law gewappnet zu sein?
3. Wie können die Projekte so gestaffelt werden, dass nicht mehr Projekte gleichzeitig "in progress" sind als die Organisation ohne Geschwindigkeitsverlust für das einzelne Projekt verkraften kann?

Die Antworten auf diese Fragen, gehen vom Grundprinzip aus: Jede Planung ist nutzlos, wenn sie nicht die Umsetzung erheblich unterstützt.

Planung der einzelnen Projekte

Detaillierungsgrad der Projektpläne – Detail versus Übersichtlichkeit

Allgemein akzeptiert ist die Erkenntnis, dass Projekte ohne Planung nicht oder kaum zu managen sind. Gibt es keinen Projektplan, weiß niemand, wann welche Ressource erforderlich ist und was erledigt sein muss, bevor etwas anderes getan werden kann. Deshalb erstellen Projektmanager vor Beginn eines Projekts einen Plan, der folgende Fragen beantwortet:

• Was ist zu tun? Welche Vorgänge sind erforderlich?
• Welche Abhängigkeiten bestehen zwischen den Vorgängen?
• Welche Ressource muss welchen Vorgang bearbeiten?
• Wie lange dauern die Vorgänge und wie lange dauert das Projekt?

Aber wie detailliert soll die Planung sein? Wer Projekte plant, befindet sich in einem Dilemma: Es gibt gute Gründe für mehr und ebenso gute Gründe für weniger Details im Projektplan.

Verfechter sehr detaillierter Pläne führen an:

• Nur mit vielen Vorgängen lassen sich alle Zusammenhänge korrekt abbilden.
• Der Projektleiter kann den Projektablauf nur dann in den Griff bekommen, wenn er alle Aufgaben detailliert voraus plant.
• Je genauer man plant, umso besser wird man die Umsetzung managen können.

Andererseits wird über zu detaillierte Planung oft geklagt:

• Die Übersichtlichkeit fehlt, der Blick für das Ganze geht verloren. (Man sieht "den Wald vor lauter Bäumen nicht".)
• Der tatsächliche Projektablauf erfolgt im Detail ganz anders als man es sich überlegt hat.
• Man investiert zu viel Überwachungs- und Steuerungsaufwand in unwesentliche Details, die den gesamten Projektablauf gar nicht beeinflussen.

Meine Kollegen und ich haben mit vielen Projektmanagern gesprochen, die sehr große Projekte erfolgreich gemanagt haben. Deren Erfahrungen zeigen, dass sehr detaillierte Projektpläne (mit mehr als 250 bis 300 Vorgängen) nicht dafür geeignet sind, den Projektablauf tatsächlich zu steuern. Dies sei – so wird oft erwähnt – einer der wesentlichen Gründe dafür, dass sehr umfangreiche Projektpläne bereits kurz nach ihrer Erstellung unbrauchbar würden und sie lange vor Ende des Projekts niemand mehr beachte.

Die Frage lautet also: Wie findet man eine sinnvolle Balance zwischen zu grober Planung und zu starker Detaillierung? Unsere Gespräche mit erfolgreichen Projektmanagern, z.B. Gewinner der nationalen und internationalen Project Excellence Awards, zeigen, dass selbst Megaprojekte mit relativ kleinen, überschaubaren Projektplänen gemanagt werden. So enthalten z.B. die Projektpläne zum Bau einer Ölplattform in der Nordsee (4 Mrd. US$) oder zur Überholung des weltweit größten Transportflugzeugs (der C5 Galaxy) jeweils weniger als 300 Vorgänge.

In unserer Arbeit verwenden wir die folgenden Empfehlungen, um zu vermeiden, dass Projektpläne zu stark detailliert werden.

Vorgänge können mehrere Aufgaben/Aktivitäten verschiedener Ressourcen enthalten