Eine Projektverzögerung ist kein Ereignis, sondern eine korrigierte Prognose. Der Termin ändert sich in dem Moment, in dem jemand neues Wissen einträgt, und deshalb wirkt jede Verspätung plötzlich. Entscheidend ist die Rückfrage, die selten gestellt wird: War die Information wirklich neu, oder war sie im Team längst bekannt und hat es nur nicht bis zum Fachbereich geschafft?
- Ein Termin ist eine Prognose. Sie springt, weil Wissen in Brocken ankommt — nicht, weil jemand geschlafen hat.
- Buehler, Griffin und Ross: 37 Studierende sagten 33,9 Tage voraus und brauchten 55,5. Auch ihre bewusst pessimistische Schätzung von 48,6 Tagen wurde im Mittel gerissen.
- Todd Little in IEEE Software: Die Unsicherheitsspanne bleibt über den Projektverlauf nahezu konstant — der Trichter verengt sich in realen Daten nicht.
- Snow, Keil und Wallace: 60 Prozent der Statusberichte sind bewusst verzerrt, optimistisch doppelt so oft wie pessimistisch — unabhängig vom Projektrisiko.
- Die Frage nach jeder Terminkorrektur lautet deshalb nicht „Warum so spät?“, sondern „Wusste jemand im Team es früher?“
Auf der Folie im Lenkungsausschuss steht eine Frage, die Sie vermutlich kennen: Wie kam es zu dieser viermonatigen Verzögerung, und warum wurde sie nicht früher erkannt? Der Projektleiter erklärt dann etwas von unvorhergesehener Komplexität. Alle nicken. Und niemand fragt, wer es eigentlich schon im März wusste.
Warum wirken Verzögerungen immer plötzlich?
Ein Termin ist eine Behauptung über die Zukunft auf Basis des Wissens von gestern. Kommt neues Wissen dazu, springt die Prognose. Sie wandert nicht langsam, weil Erkenntnis nicht langsam kommt, sondern in Brocken. Die vier Monate waren im Februar bereits im Projekt enthalten, sie standen nur nicht im Plan.
Dass wir uns dabei systematisch verschätzen, ist gut belegt. Roger Buehler, Dale Griffin und Michael Ross ließen 37 Studierende den Fertigstellungstermin ihrer Abschlussarbeit schätzen. Im Schnitt sagten sie 33,9 Tage voraus und brauchten 55,5. Der spannende Teil kommt danach: Dieselben Personen wurden gebeten, einen bewusst pessimistischen Fall zu schätzen. Sie nannten 48,6 Tage. Auch dieser Wert wurde im Mittel gerissen.
In der Praxis heißt das: Wir sind nicht deshalb schlecht im Schätzen, weil wir schlampig arbeiten. Wir sind es auch dann, wenn wir uns ausdrücklich Mühe geben, pessimistisch zu sein.
Das ist kein Einzelbefund aus einem Hörsaal-Experiment. Ein Überblick über zwei Jahrzehnte Forschung zur Planungs-Verzerrung bestätigt das Muster über Dutzende Studien und Domänen hinweg. Und es bleibt nicht bei Abschlussarbeiten: Bent Flyvbjerg, Mette Skamris Holm und Søren Buhl werteten 258 Verkehrsinfrastrukturprojekte im Wert von 90 Milliarden US-Dollar aus und fanden dieselbe Schieflage. Die Kosten wurden in 86 Prozent der Projekte unterschätzt, im Schnitt um 28 Prozent — Überschätzungen kamen so selten vor, dass reiner Zufall als Erklärung ausscheidet.
| Quelle | n | Methode | Kernbefund |
|---|---|---|---|
| Buehler, Griffin & Ross 1994 | 37 Studierende | Feldexperiment | Schätzung 33,9 Tage, tatsächlich 55,5 — auch der bewusst pessimistische Fall unterschätzt |
| Buehler, Griffin & Peetz 2010 | Forschungsüberblick | Literatur-Review | Planungs-Verzerrung über Dutzende Studien und Domänen repliziert |
| Flyvbjerg, Skamris Holm & Buhl 2002 | 258 Projekte, 90 Mrd. USD | Statistische Großstichprobe | 86 % der Projekte unterschätzt, im Schnitt um 28 % |
Wird die Schätzung im Projektverlauf besser?
Die verbreitete Annahme lautet ja. Der sogenannte Cone of Uncertainty beschreibt einen Trichter, der sich mit wachsendem Wissen verengt. Das klingt plausibel und wird in jeder zweiten Projektschulung gezeigt.
Todd Little hat das an realen Daten geprüft und in IEEE Software veröffentlicht. Er wertete die Projektdatenbank eines Softwareherstellers aus und fand: Die Schätzgenauigkeit folgte einer logarithmischen Normalverteilung, und die Unsicherheitsspanne blieb über den Projektverlauf hinweg nahezu gleich. Das Verhältnis zwischen optimistischem und pessimistischem Rand lag durchgehend bei etwa drei bis vier.
Der Trichter verengt sich also nicht so, wie das Bild suggeriert. Wenn das stimmt, ist ein einzelnes Datum in Monat neun genauso wenig belastbar wie in Monat eins. Es fühlt sich nur belastbarer an. Und genau dieses Gefühl ist der Grund, warum die Korrektur später wie ein Bruch wirkt statt wie eine normale Aktualisierung.
Wie oft sind Statusberichte geschönt?
Hier wird es unangenehm, denn nicht jede Verspätung ist ein Wissenssprung. Andrew Snow, Mark Keil und Linda Wallace haben Projektleiter direkt danach gefragt, wie sie ihre Statusberichte verfassen. Das Ergebnis: In 60 Prozent der Fälle wurde der Bericht bewusst verzerrt, und optimistische Verzerrung trat doppelt so häufig auf wie pessimistische. Rechnerisch schätzten die Autoren, dass nur etwa 10 bis 15 Prozent der verzerrten Berichte am Ende zufällig richtig lagen.
Zwischen hohem und niedrigem Projektrisiko fanden sie dabei keinen nennenswerten Unterschied. Es wird also nicht dort mehr geschönt, wo mehr auf dem Spiel steht. Es wird überall geschönt.
Mark Keil und Kollegen haben diese Forschung später im MIT Sloan Management Review zusammengefasst, gestützt auf 14 Einzelstudien. Ihre Kernaussage: Komplexe Projekte scheitern nicht über Nacht, sondern Tag für Tag, und fast immer nach zahlreichen Warnsignalen.
An wie vielen Stellen erfährt Ihr Fachbereich Probleme erst, wenn sie unumkehrbar sind?
Der WERT³ Quick-Check zeigt Ihnen in 10 Minuten, wo Ihre größten Hebel liegen. Kostenlos, ohne Verkaufsgespräch.
→ WERT³ Quick-Check starten
Wie unterscheiden Sie echte Erkenntnis von verspäteter Meldung?
Es gibt zwei völlig verschiedene Arten von Verzögerung, und die Ausgangsfrage vermischt beide.
Die erste ist echte Erkenntnis. Jemand findet heraus, dass das Altsystem Storno-Fälle in drei Varianten kennt, von denen zwei undokumentiert sind. Diese Verzögerung kommt tatsächlich sprunghaft, und sie ist kein Führungsversagen, sondern der Normalbetrieb von Lernen.
Die zweite ist angesammelte Verzögerung. Die Menge angefangener Arbeit wächst, Klärungen dauern statt zwei Tagen neun, die Nacharbeitsquote steigt, Leute sind auf drei Vorhaben verteilt. Nichts davon ist überraschend, und alles davon lässt sich messen, während es entsteht.
Die Unterscheidung gelingt mit einer einzigen Frage, und sie ist deutlich unangenehmer als die auf der Folie: Wusste jemand im Team es früher? Bei Ja liegt kein Planungsproblem vor, sondern ein Problem des Berichtswegs. In meiner Beratungspraxis beobachte ich, dass die Antwort erstaunlich oft Ja lautet und die Frage trotzdem nie gestellt wird.
Was hat das mit der Zusammenarbeit von IT und Fachbereich zu tun?
Sehr viel, denn Informationen über Probleme laufen genau dieselbe Strecke wie Anforderungen, nur in die Gegenrichtung. Der Fachbereich wirft Anforderungen über den Zaun, die IT übersetzt sie und gibt sie weiter, und wenn es klemmt, muss die schlechte Nachricht dieselben Stationen rückwärts durchlaufen. Jede Station ist eine Gelegenheit, die Farbe von Rot auf Gelb zu drehen.
Dazu kommt, dass in den meisten Steuerungsgremien niemand sitzt, der die Arbeit tatsächlich macht. Der Entwickler, der die Storno-Logik kennt, wird nicht gefragt. Er hat es im März gesagt, in einem Team-Rückblick, in dem außer dem Team niemand war. Dieselbe Runde beschließt bei einer Verspätung dann gern zusätzliches Personal, was die Datenlage nicht trägt.
Wer diese Strecke nicht verkürzt, bekommt zwangsläufig sprunghafte Nachrichten. Das ist kein Charakterfehler der Beteiligten, sondern eine Eigenschaft der Übergabekette.
Was tun statt der Schuldfrage?
Drei Dinge verändern in meiner Erfahrung tatsächlich etwas, und keines davon ist ein neues Werkzeug.
Führen Sie Termine dauerhaft als Korridor mit einer Angabe zur Sicherheit. Wer von Anfang an von Oktober bis Februar spricht, muss im Juni nichts erklären, sondern nur einengen. Ersetzen Sie außerdem Ampelfarben durch Flusskennzahlen, also durch die Menge angefangener Arbeit, die Wartezeit auf Klärungen und die Durchlaufzeit von Idee bis Produktion. Farben sind Meinungen, diese Zahlen sind Messwerte. Und führen Sie ein kurzes Protokoll über jede Prognoseänderung, mit der Angabe, was wann bekannt wurde.
Zusammengefasst bedeutet das: Nach zwei Quartalen sehen Sie ein Muster. Häufen sich echte Erkenntnisse, haben Sie zu früh zu genau geplant. Häufen sich verspätete Meldungen, haben Sie ein Vertrauensproblem. Beides ist reparierbar, aber mit völlig unterschiedlichen Mitteln.
Wenn Sie wissen wollen, warum schlechte Nachrichten bei Ihnen so lange brauchen
„Emails über den Zaun werfen ist keine Kommunikation“ zeigt anhand von fünf Kräften, warum Projekte scheitern, obwohl alle ihren Job machen. Das Buch zur WERT³-Methodik. 318 Seiten, April 2026 erschienen.
→ Buch ansehen
Häufige Fragen
Kommt eine Projektverzögerung wirklich plötzlich?
Die Korrektur der Prognose kommt sprunghaft, weil Wissen sprunghaft ankommt. Die Verzögerung selbst war meist längst im Projekt angelegt. Ob sie vorher sichtbar war, hängt davon ab, ob es sich um neue Erkenntnis oder um verspätet gemeldete Information handelt.
Werden Schätzungen im Projektverlauf genauer?
Nicht zwangsläufig. Eine Auswertung realer Projektdaten in IEEE Software zeigt, dass die Unsicherheitsspanne über den Projektverlauf hinweg nahezu konstant blieb. Der verbreitete Trichter, der sich mit der Zeit verengt, ließ sich in diesen Daten nicht bestätigen.
Wie verbreitet sind geschönte Statusberichte?
In einer Befragung von Projektleitern waren 60 Prozent der Statusberichte bewusst verzerrt, doppelt so oft optimistisch wie pessimistisch. Ein Unterschied zwischen risikoreichen und risikoarmen Projekten zeigte sich dabei nicht.
Woran erkenne ich, ob mein Projekt ein Berichtsproblem hat?
Fragen Sie nach jeder Terminkorrektur, wer im Team es früher wusste, und messen Sie, wie lange eine Rückfrage bis zur Antwort braucht. Sind beide Werte hoch, liegt der Engpass in der Zusammenarbeit. Der WERT³ Quick-Check macht das in 10 Minuten sichtbar.
Quellen
| Quelle | n | Datum | URL |
|---|---|---|---|
| Buehler, Griffin & Ross, Journal of Personality and Social Psychology | 37 Studierende | 1994 | web.mit.edu/curhan/www/docs/Articles/biases/67_J_Personality_and_Social_Psychology_366,_1994.pdf |
| Little, IEEE Software | Projektdatenbank eines Softwareherstellers | 2006 | ieeexplore.ieee.org/document/1628940 |
| Snow, Keil & Wallace, Information & Management | Befragung von Projektleitern | 2007 | sciencedirect.com/science/article/abs/pii/S0378720606001145 |
| Keil, Smith, Iacovou & Thompson, MIT Sloan Management Review | Überblick über 14 Einzelstudien | 2014 | sloanreview.mit.edu/article/the-pitfalls-of-project-status-reporting/ |
| Buehler, Griffin & Peetz, Advances in Experimental Social Psychology | Forschungsüberblick über zwei Jahrzehnte | 2010 | sciencedirect.com/science/article/abs/pii/S0065260110430014 |
| Flyvbjerg, Skamris Holm & Buhl, Journal of the American Planning Association | 258 Projekte, 90 Mrd. USD | 2002 | arxiv.org/abs/1303.6604 |