*Kategorie: Problem & Praxis · Kernproblem 4: Planung & Termine · Lesezeit: ca. 8 Minuten*
Nur 31 % aller Projekte werden pünktlich, im Budget und mit vollem Umfang abgeschlossen (Standish Group, CHAOS 2020). Das bedeutet umgekehrt: Sieben von zehn Zeitplänen sind zum Zeitpunkt ihrer Erstellung bereits falsch – die Beteiligten wissen es nur noch nicht. Bei technisch komplexen Projekten mit langen Lieferketten und vielen Disziplinen ist die Quote noch schlechter.
Das Problem ist nicht, dass Projektleiter schlecht planen. Das Problem ist, dass ein Zeitplan eine Prognose über ein System ist, das sich während der Prognose verändert.
Für wen wird das zum Problem – und wann?
Der Zeitplan ist die Grundlage für alles, was im Projekt Geld kostet: Bestellungen, Personalzuteilung, Hallenbelegung, Kundenzusagen. Wenn er nicht stimmt, stimmt nichts davon.
Die typische Situation im Anlagenbau: Der Plan wird zu Auftragsbeginn erstellt, mit dem Wissen, das zu diesem Zeitpunkt vorhanden ist. Nach vier Wochen ist die Konstruktion so weit, dass die ersten Annahmen überprüft werden können. Nach acht Wochen ist klar, dass Modul 2 komplexer ist als gedacht. Nach zwölf Wochen hat der Kunde zwei Anforderungen geändert. Der Plan aus Woche 0 existiert noch – als Datei. Als Prognose ist er wertlos.
Betroffen sind:
- Projektleiter, die dem Kunden Termine zugesagt haben, die auf dem Plan aus Woche 0 beruhen.
- PMO-Leiter, die das Portfolio auf Basis von Einzelplänen steuern, die alle unterschiedlich alt sind.
- Geschäftsführung, die Umsatz und Cashflow auf Basis von Terminen prognostiziert, die niemand mehr für realistisch hält.
Was zeigen die Zahlen zur Planungsgenauigkeit?
| Quelle | Befund |
|---|---|
| Standish Group, CHAOS 2020 | 31 % erfolgreich, 50 % zu spät/zu teuer/unvollständig, 19 % gescheitert |
| McKinsey / Oxford, 2012 | Große Technologieprojekte: 7 % Terminüberschreitung im Schnitt, 45 % Budgetüberschreitung – Verzug wird mit Geld erkauft |
| Flyvbjerg, *Megaprojects and Risk* / Oxford Global Projects | 9 von 10 Großprojekten überschreiten Kosten und Zeit; Muster ist über 70 Jahre stabil |
| Kahneman & Tversky, Planning Fallacy (1979) | Menschen unterschätzen systematisch Dauer und Kosten eigener Vorhaben, selbst mit Kenntnis früherer Überschreitungen |
Der letzte Punkt ist der wichtigste. Die Planning Fallacy ist keine Frage der Erfahrung. Erfahrene Planer unterschätzen genauso wie unerfahrene – weil sie ihr eigenes Projekt als Sonderfall betrachten, auf den die Statistik nicht zutrifft.
Warum stimmen Pläne strukturell nicht?
Vier Ursachen, die sich in technischen Projekten überlagern:
1. Der Plan wird zum Zeitpunkt des geringsten Wissens erstellt
Zu Projektbeginn ist am wenigsten über das Projekt bekannt: Die Konstruktion existiert nicht, Lieferanten haben noch nicht bestätigt, der Kunde hat seine Anforderungen noch nicht vollständig verstanden. Trotzdem wird zu diesem Zeitpunkt der verbindlichste Plan erstellt – weil der Vertrag es verlangt.
Jede Woche danach steigt das Wissen. Der Plan bleibt auf dem Stand von Woche 0, sofern jemand ihn nicht aktiv nachführt.
2. Dauern werden geschätzt, nicht abgeleitet
„Konstruktion Modul 3: 15 Tage." Woher kommt die Zahl? Meist aus Erfahrung, Analogie zum letzten Projekt oder Verhandlung mit dem Abteilungsleiter. Selten aus einer Ableitung: Modul 3 hat 40 Bauteile, davon 12 Neukonstruktionen à 1,5 Tage, 28 Anpassungen à 0,3 Tage, plus 20 % Abstimmung.
Geschätzte Dauern haben keine Struktur, die sich bei Änderungen anpassen ließe. Wenn Modul 3 plötzlich 55 statt 40 Bauteile hat, muss jemand die 15 Tage neu schätzen. Abgeleitete Dauern rechnen sich selbst neu.
3. Abhängigkeiten sind unvollständig
Ein Plan mit 300 Vorgängen hat im Idealfall auch 300 bis 500 Abhängigkeiten. In der Praxis sind es oft 100 bis 150 – die offensichtlichen. Die nicht offensichtlichen (Schnittstellen zwischen Disziplinen, Freigabeketten, Ressourcenkonflikte mit anderen Projekten) fehlen.
Fehlende Abhängigkeiten bedeuten: Eine Verschiebung wird nicht weitergegeben. Der Plan zeigt einen Endtermin, der rechnerisch erreichbar ist und praktisch längst verloren.
4. Der Plan wird nicht mit der Realität abgeglichen
Das ist die eigentliche Ursache. Ein Plan, der wöchentlich mit dem tatsächlichen Stand abgeglichen wird, kann falsch starten und trotzdem nützlich bleiben. Ein Plan, der nur bei Meilensteinen aktualisiert wird, ist zwischen den Meilensteinen blind.
Der Abgleich scheitert meist an Aufwand: Er erfordert, Informationen aus Engineering, Einkauf, Fertigung und vom Kunden zusammenzutragen und auf 300 Vorgänge zu übertragen. Wer das manuell tut, tut es einmal im Monat. Bis dahin ist der Plan vier Wochen alt.
Wie plant man so, dass der Plan nützlich bleibt?
Das Ziel ist nicht ein Plan, der stimmt. Das Ziel ist ein Plan, der schnell erkennt, wo er nicht mehr stimmt. Vier Prinzipien:
- Rolling-Wave-Planung. Die nächsten acht Wochen werden detailliert geplant, der Rest grob. Detailplanung erfolgt, wenn das Wissen dafür vorhanden ist – nicht in Woche 0 für Monat 14.
- Dauern aus Struktur ableiten. Wo möglich, werden Dauern aus Mengen (Bauteile, Zeichnungen, Prüfpunkte) und Kennzahlen berechnet, nicht geschätzt. Ändert sich die Menge, ändert sich die Dauer.
- Referenzklassen nutzen. Flyvbjergs Antwort auf die Planning Fallacy: Statt das eigene Projekt zu schätzen, wird die Verteilung vergleichbarer abgeschlossener Projekte betrachtet. Wenn die letzten zehn Anlagen dieser Klasse im Median 18 % länger dauerten als geplant, ist das der Aufschlag – unabhängig davon, wie gut sich das aktuelle Projekt anfühlt.
- Kontinuierlicher Abgleich statt Meilenstein-Update. Der Plan sollte den tatsächlichen Stand aus Engineering und Fertigung automatisch übernehmen. Dann ist die Frage „Wo stehen wir?" eine Abfrage, nicht ein Meeting.
Praxisbeispiel: Sondermaschine mit drei Planversionen
Ein Sondermaschinenbauer erhält den Auftrag für eine Montagelinie: 1,6 Mio. €, 12 Monate, Vertragsstrafe ab Woche 54.
Plan Version 1 (Woche 0): 280 Vorgänge, Endtermin Woche 50. Puffer: 4 Wochen. Dauern geschätzt auf Basis eines ähnlichen Projekts von vor zwei Jahren.
Plan Version 2 (Woche 10): Die Konstruktion hat ergeben, dass die Zuführung eine Neuentwicklung erfordert. Der Projektleiter verschiebt vier Vorgänge um sechs Wochen. Endtermin: Woche 52. Puffer: 2 Wochen. Nicht verschoben: 11 Vorgänge in Elektrik und Software, die von der Zuführung abhängen, aber im Plan nicht verknüpft waren.
Plan Version 3 (Woche 28): Der Elektrokonstrukteur meldet, dass er auf die Zuführungsdaten wartet. Jetzt werden die 11 Vorgänge verschoben. Endtermin: Woche 57. Vertragsstrafe: 3 Wochen × 0,5 % = 24.000 €.
Hätte Plan Version 1 die Abhängigkeit zwischen Zuführung und Elektrik enthalten, wäre der Endtermin Woche 57 bereits in Woche 10 sichtbar gewesen. Mit 44 Wochen Vorlauf hätte das Unternehmen die Elektrokonstruktion vorziehen, extern vergeben oder den Kunden früh informieren können. Mit 26 Wochen Vorlauf blieb nur die Vertragsstrafe.
Fazit
Projektzeitpläne stimmen nicht, weil sie zum Zeitpunkt des geringsten Wissens erstellt und danach zu selten mit der Realität abgeglichen werden. Der Unterschied zwischen einem nützlichen und einem wertlosen Plan liegt nicht in der Genauigkeit der ersten Version, sondern in der Geschwindigkeit, mit der Abweichungen sichtbar werden. Wer den Abgleich automatisiert, hat keinen besseren Plan – aber eine bessere Prognose.
---
*Mehr zu modernem Projektmanagement in technisch komplexen Projekten: Aligia*