Cone of Uncertainty: Warum frühe Schätzungen falsch liegen

Von Tara Minh · Aktualisiert am 10. Oktober 2026

Der Cone of Uncertainty ist ein Modell, das zeigt: Projektschätzungen sind am Anfang am unzuverlässigsten und werden erst dann verlässlicher, wenn Unbekannte aufgelöst werden. In der Version von Steve McConnell liegen frühe Softwareschätzungen irgendwo zwischen dem 0,25-Fachen und dem 4-Fachen des Endergebnisses und nähern sich dem 1,0-Fachen an, sobald Entscheidungen fallen.

Wichtige Fakten

• Faktor 4 in beide Richtungen: Schätzungen in der Phase Initial Concept können um den Faktor 4 nach oben oder um den Faktor 4 nach unten (0,25x) danebenliegen, also eine Spanne von 16x zwischen niedrigstem und höchstem Wert, laut Construx-Whitepaper zum Cone of Uncertainty.
• Bestfall, kein Versprechen: Der Cone zeigt die beste Genauigkeit, die erfahrene Schätzende erreichen können. Schlechter zu sein ist leicht, genauer zu sein ist nur mit mehr Glück möglich (gleiches Construx-Paper).
• Subjektiver Ursprung: Barry Boehm zeichnete die erste Version 1981 in seinem Buch Software Engineering Economics. Die Bereiche wurden per Urteil als 80-%-Konfidenzgrenzen festgelegt und nicht aus Projektdaten gemessen (Bossavit, The Leprechauns of Software Engineering).
• Verengung ist Arbeit: Der Großteil der Verengung geschieht in etwa den ersten 20 bis 30 % der Kalenderzeit, und zwar nur, weil das Team Entscheidungen trifft, die Variabilität beseitigen (Construx).

Was ist der Cone of Uncertainty?

Stellen Sie sich einen Trichter vor, der auf der Seite liegt. Links, zu Projektbeginn, ist er weit. Rechts, kurz vor der Lieferung, läuft er spitz zu. Die vertikale Achse zeigt, wie weit eine Schätzung von Aufwand, Kosten, Termin oder Umfang von dem entfernt liegen kann, was Sie am Ende liefern. Die horizontale Achse ist die Zeit, markiert durch Meilensteine: Initial Concept, freigegebene Produktdefinition, vollständige Anforderungen, abgeschlossenes Design und Fertigstellung.

Die Idee ist einfach. Früh im Projekt wissen Sie nicht genau, was Sie bauen, wer es baut, welche Risiken zuschlagen oder welche Anforderungen sich ändern. Jede dieser Unbekannten bringt Streuung in die Schätzung. Wird eine nach der anderen geklärt, schrumpft der plausible Ergebnisbereich.

Das ist der Teil, den alle zitieren. Der Teil, den man gern überspringt, steht gleich daneben bei McConnell: Die Unsicherheit schrumpft nicht, weil Zeit vergeht. Sie schrumpft, weil jemand eine Entscheidung getroffen hat. Das Construx-Whitepaper sagt es deutlich: Die Variabilität der Schätzung lässt sich nur verringern, indem man die Variabilität im Projekt selbst verringert. Wer ein Team um "noch eine Woche zur Verfeinerung der Schätzung" bittet, erreicht nichts, wenn in dieser Woche nichts im Projekt definiert wurde.

Woher der Cone stammt

Barry Boehm skizzierte die früheste Version in Software Engineering Economics (1981) und nannte sie die Funnel Curve. In der frühesten Phase konnten Schätzungen in beide Richtungen um den Faktor 4 danebenliegen: McConnells Construx-Whitepaper beziffert den Bereich für Initial Concept mit 4x nach oben bis 0,25x nach unten, eine Spanne von 16x.

Steve McConnell gab ihm später den Namen "Cone of Uncertainty" und baute ihn in seine Schätzbücher ein, darunter Software Estimation: Demystifying the Black Art (Microsoft Press, 2006). Construx, das von ihm gegründete Unternehmen, veröffentlicht das Modell bis heute als Whitepaper.

Hier der ehrliche Vorbehalt. Laurent Bossavits Analyse der Geschichte des Cone ergab, dass Boehms Bereiche auf Urteilen beruhten und nicht auf einem gemessenen Datensatz. Bossavit verweist außerdem auf Todd Littles Daten von 2006 aus echten Projektstatusberichten, veröffentlicht in IEEE Software, die nicht zum symmetrischen Trichter passten. Reale Projekte verspäten sich weit häufiger, als sie früher fertig werden, und viele bleiben lange bei "90 % fertig" stehen.

McConnells Antwort im Construx-Paper lautet, der Cone sei ein Bestfall und schlecht geführte Projekte erzeugten eine "Wolke" der Unsicherheit, die sich nie verengt. Behandeln Sie den Cone also als nützliches Lehrmodell und als Planungsdisziplin, nicht als statistisches Gesetz. Seine praktische Lehre gilt in beiden Fällen: Frühe Zahlen verdienen breite Bereiche.

Cone of Uncertainty im Vergleich zu anderen Schätzkonzepten

Der Cone ist keine Schätztechnik. Er ist eine Linse, um zu beurteilen, wie sehr Sie dem Ergebnis einer Technik zu einem bestimmten Zeitpunkt trauen können. Deshalb ergänzt er die folgenden Methoden, statt sie zu ersetzen.

Eine nützliche Faustregel: Wählen Sie die Methode, deren Genauigkeit zur Breite des Cone passt. Eine Bottom-up-Schätzung auf die Stunde genau ist beim Initial Concept Scheingenauigkeit. Eine grobe Analogieschätzung ist Verschwendung, sobald das Design steht und der Umfang festgelegt ist.

Warum frühe Schätzungen falsch liegen

Es ist verlockend, den Schätzenden die Schuld zu geben. Meist liegt das Problem nicht bei ihnen. Vier Faktoren weiten den Cone zu Beginn.

Die Anforderungen sind vage. "Ein Kundenportal bauen" kann eine Login-Seite und eine Rechnungsliste bedeuten oder eine vollständige Self-Service-Plattform mit Zahlungen. Beides sind ehrliche Lesarten. Der Aufwandsunterschied zwischen ihnen ist enorm.

Der Umfang ist ein bewegliches Ziel. Stakeholder fügen Funktionen hinzu und streichen sie, sobald sie etwas Reales sehen. Das ist Umfangsausweitung in ihrer frühen Form, noch bevor es überhaupt eine Baseline gibt, von der aus sie ausweiten könnte.

Abhängigkeiten sind unbekannt. Sie wissen noch nicht, dass das Payment-Team eine Warteschlange von sechs Wochen hat oder dass das Altsystem neu geschrieben werden muss, bevor Sie es anbinden können.

Das Team ist noch nicht eingespielt. Fähigkeiten, Verfügbarkeit und Velocity sind Vermutungen, bis die Beteiligten tatsächlich zusammen am echten Vorhaben gearbeitet haben.

Hinzu kommt die menschliche Ebene. Optimismus ist der Normalfall, und eine Zahl, die in einem Meeting laut ausgesprochen wird, wird schnell zum Versprechen. Hört ein Sponsor beim Initial Concept "etwa vier Monate", landet diese Zahl in einem Plan, in einem Budget und manchmal in einem Kundenvertrag. Niemand erinnert sich daran, dass sie mit einem Bereich von "eins bis sechzehn" verbunden war.

Construx benennt genau das als die eigentliche Gefahr. Organisationen, die sich festlegen, solange der Cone noch weit ist, untergraben nach dessen Worten die Planbarkeit und erhöhen das Risiko. Wer sich beim Initial Concept oder bei der Produktdefinition festlegt, lebt mit einem Schätzfehler von 2x bis 4x.

So nutzen Sie den Cone of Uncertainty (Schritt für Schritt)

Sie können den Cone nicht verschwinden lassen, aber Sie können ihn gezielt nutzen. Hier eine praxistaugliche Abfolge.

Schritt 1: Die Phase ehrlich benennen

Legen Sie fest, wo das Projekt heute steht: erste Idee, freigegebener Umfang, vollständige Anforderungen, abgeschlossenes Design oder Umsetzung. Seien Sie kritisch. Ein Projekt mit freigegebenem Budget und einem halb fertigen Anforderungsdokument steht noch am breiten Ende.

Schritt 2: Einen Bereich nennen, keinen Punktwert

Wandeln Sie Ihre beste Schätzung in einen unteren und einen oberen Wert um. Beim Initial Concept erlaubt das Construx-Modell 0,25x bis 4x, aus einer Bauchschätzung von 100 Tagen werden also 25 bis 400 Tage. Das wirkt auf einer Folie absurd, und genau das ist der Punkt. Wenn die Spanne die Beteiligten beunruhigt, stimmen sie der Arbeit zu, die sie verengt.

Für Bereiche auf Aufgabenebene liefert die Drei-Punkt-Schätzung einen belastbaren Weg zu unterem, wahrscheinlichem und oberem Wert.

Schritt 3: Die Unbekannten auflisten, die die Breite erzeugen

Schreiben Sie jede offene Frage auf, die die Schätzung verschiebt: ungeklärte Anforderungen, unbekannte Integrationen, unbestätigte Besetzung, unerprobte Technologie. Ordnen Sie sie danach, wie viel Spannweite jede einzelne hinzufügt. Diese Liste ist zugleich der Anfang Ihres Risikoregisters.

Schritt 4: Die Arbeit einplanen, die Unbekannte beseitigt

Behandeln Sie Discovery als Liefergegenstände. Definieren Sie die Produktvision, einschließlich dessen, was nicht zum Umfang gehört. Schließen Sie die Anforderungen ab. Prototypisieren Sie die riskanteste Schnittstelle. Führen Sie einen technischen Spike für die Integration durch, die noch niemand ausprobiert hat. Jede dieser Maßnahmen beseitigt Variabilität, und jede sollte einen Verantwortlichen und einen Termin haben.

Schritt 5: Die verbindliche Zusage hinauszögern

McConnells Empfehlung lautet, dass im frühen, breiten Teil des Cone keine belastbaren Zusagen möglich sind und dass wirksame Organisationen warten, bis sie ihn zur Verengung gezwungen haben. Sein Paper beschreibt Zusagen etwa 30 % im Projektverlauf als möglich und angemessen. Braucht das Unternehmen früher eine Zahl, nennen Sie den Bereich und kennzeichnen Sie ihn als Bereich.

Schritt 6: An jedem Meilenstein neu schätzen

Schätzen Sie neu, sobald eine wesentliche Unbekannte geklärt ist, nicht nach Kalender. Vergleichen Sie jeden neuen Bereich mit dem vorherigen. Verengt er sich nicht, haben Sie eine Wolke, und das Projekt braucht ein Gespräch über Umfang, Besetzung oder Vorgehen.

Schritt 7: Baseline setzen, sobald der Bereich eng ist

Ist der Bereich schmal genug, dass der Sponsor ihn finanzieren und das Team sich darauf verpflichten kann, halten Sie ihn als Projekt-Baseline fest. Verfolgen Sie von da an die Abweichung gegenüber dieser Zahl.

Kopierfertige Vorlage: Tracker für Schätzbereiche

Kopieren Sie diese Tabelle in Ihren Projektplan und aktualisieren Sie sie an jedem Meilenstein. Die Spalte "Breite" ist einfach oberer Wert geteilt durch unteren Wert und zeigt auf einen Blick, ob sich der Cone verengt.

So füllen Sie sie aus:

1. Unterer und oberer Wert stammen aus Drei-Punkt-Schätzungen, die über die Arbeit summiert werden, oder aus den Cone-Multiplikatoren, angewendet auf eine einzelne beste Schätzung.
2. Geklärte Unbekannte ist eine einfache Liste der Entscheidungen seit der letzten Zeile. Ist diese Zelle leer und hat sich die Breite nicht verändert, ist das zu erwarten.
3. Zusage erlaubt? ist eine Richtlinien-Spalte. Vereinbaren Sie sie vorab mit Ihrem Sponsor, damit später niemand darüber streitet.

Fällt die Spalte "Breite" an zwei Meilensteinen in Folge nicht, eskalieren Sie. Etwas im Projekt konvergiert nicht.

Beispiele nach Geschäftsbereich

Der Cone ist nicht auf Software beschränkt. Jede Arbeit mit undefiniertem Umfang und unbekannten Schritten verhält sich so. Die Zahlen unten sind illustrative Rechenbeispiele, bei denen die Multiplikatoren der frühen Phase (0,25x bis 4x) auf eine grobe Erstschätzung angewendet werden, keine Benchmarks.

Nehmen Sie den Marketing-Launch. "Acht Wochen" klingt vernünftig, bis Sie fragen, was dazugehört. Wenn das Brief nicht freigegeben ist, unklar bleibt, wer die Texte genehmigt, und offen ist, ob die Rechtsabteilung Aussagen prüfen muss, dann sind "acht Wochen" eine Hoffnung. Stehen Brief, Sitemap und Freigabekette fest, lässt sich dasselbe Projekt ehrlich mit sechs bis zehn Wochen beziffern.

Dieselbe Logik gilt für einen Operations-Rollout. Vor dem Prozessmapping hat eine Zahl von 200.000 \(nicht mehr Grundlage als eine von 600.000\). Nach Mapping und Anbieter-Shortlist könnte sich der Bereich auf etwas verengen, das ein Finance Director unterschreiben kann.

Der Cone und Agile Teams

Ein häufiger Einwand: "Wir arbeiten Agile, also gilt der Cone nicht." Er gilt anders, nicht gar nicht.

Das Construx-Paper selbst sagt, dass Sie bei iterativen Projekten in jeder Iteration einen Mini-Cone durchlaufen. Vor der Anforderungsarbeit für eine Iteration befinden Sie sich im Abschnitt "freigegebene Produktdefinition" des Cone. Mit kurzen Iterationen kann ein Team Anforderungen und UI-Design in Tagen durchlaufen und die Variabilität für diesen Ausschnitt der Arbeit von 4x auf 1,6x senken. Bei festem Zeitplan zeigt sich diese Variabilität als Unsicherheit darüber, welche Funktionen hineinpassen, nicht über das Enddatum.

Was man aufgibt, so das Paper, ist die langfristige Vorhersagbarkeit von Kosten, Zeitplan und Funktionsumfang über mehrere Iterationen hinweg. Viele Teams wählen einen Mittelweg: Die meisten Anforderungen vorab definieren und dann in kurzen Iterationen bauen. Laut Paper senkt das die Variabilität aus dem Cone auf etwa plus/minus 25 %.

In der Praxis heißt das: Agile Teams brauchen weiterhin Bereiche für Roadmaps und Release-Termine, und relative Größenschätzungen wie Story Points funktionieren am besten für Arbeit der nahen Zukunft. Weit entfernte Punkte verdienen grobe Größenangaben und ein ehrliches "Wir wissen später mehr".

Dos und Don'ts beim Cone of Uncertainty

Dos

• Nennen Sie früh Bereiche. Sagen Sie beim Konzept "vier bis sechzehn Monate", nicht "acht Monate". Ein Bereich schützt Sie und klärt den Sponsor auf.
• Binden Sie die Verengung an benannte Entscheidungen. Jede Zeile Ihres Trackers sollte zeigen, was seit der letzten Schätzung geklärt wurde.
• Schätzen Sie an Meilensteinen neu. Eine neue Schätzung nach Abschluss der Anforderungen ist mehr wert als eine monatliche Auffrischung ohne Neues.
• Nutzen Sie Bereiche, um Discovery zu priorisieren. Die Unbekannte, die die meiste Breite beiträgt, wird zuerst bearbeitet.
• Trennen Sie Schätzungen von Zusagen. Eine Schätzung ist, was Sie erwarten. Eine Zusage ist ein Versprechen. Beides sollte nicht im selben Satz vermischt werden.
• Kombinieren Sie den Cone mit einer quantitativen Methode wie der Monte-Carlo-Simulation, sobald Sie genug Details zum Modellieren haben.

Don'ts

• Behandeln Sie den Cone nicht als Automatismus. Verstreichende Zeit verengt ihn nicht. Entscheidungen tun es, und das Construx-Paper sagt, der Cone könne zur Wolke werden, wenn ein Projekt nicht gut gesteuert wird.
• Versprechen Sie keine Genauigkeit, die das Modell nicht liefern kann. Selbst erfahrene Schätzende schlagen den Cone nicht. Sie können ihn nur stärker verfehlen.
• Pressen Sie den Bereich nicht zusammen, um einem Sponsor zu gefallen. Eine engere Zahl ohne neue Information dahinter ist nur ein größeres Risiko.
• Ignorieren Sie die Schiefe nicht. Reale Projekte verzögern sich häufiger, als sie früher fertig werden, gehen Sie also nicht davon aus, dass unteres und oberes Ende gleich wahrscheinlich sind. Gewichten Sie Ihren Bereich zur pessimistischen Seite.
• Lassen Sie keinen Punktwert den Raum verlassen. Sobald "etwa vier Monate" ohne Bereich in einer E-Mail steht, ist es ein Versprechen.
• Setzen Sie keine präzise Methode in einer vagen Phase ein. Bottom-up-Schätzungen auf Stundenbasis für ein einseitiges Konzept sind Theater.

Häufige Fehler im Umgang mit dem Cone

Manche Teams hören "Schätzungen sind früh unzuverlässig" und folgern, Planung sei sinnlos. Das ist sie nicht. Der Cone sagt: Planen Sie im Verhältnis zu dem, was Sie wissen, und investieren Sie den frühen Aufwand in die Klärung der größten Unbekannten, statt eine Zahl zu polieren.

Andere nehmen die symmetrische Form zu wörtlich. Bossavits Kritik ist eine gute Erinnerung daran, dass ein sauberes Diagramm kein Beleg für eine saubere Verteilung ist. Nutzen Sie die Multiplikatoren als Ausgangspunkt für ein Gespräch und passen Sie sie dann an Ihre eigene Historie an. Wenn frühere Projekte Ihrer Organisation im Schnitt 40 % über Plan lagen, rechnen Sie das ein.

Ein dritter Fehler ist, den Cone als Ausrede für eine fehlende Baseline zu benutzen. Sind Umfang und Design stabil, hat der Cone seine Arbeit getan. Ab da ist die Abweichung von der Baseline eine Führungsfrage, keine Unsicherheitsfrage. Dann sind Abwägungen zwischen Umfang, Zeitplan und Kosten das richtige Gespräch.

Wichtigste Erkenntnisse

Der Cone of Uncertainty liefert eine belastbare Antwort auf eine Frage, die jeder Sponsor stellt: "Wie lange dauert das?" Die ehrliche frühe Antwort ist ein Bereich, und die Breite dieses Bereichs ist eine Information. Verengen Sie ihn durch Entscheidungen, nicht durch Warten. Halten Sie verbindliche Zusagen zurück, bis sich der Cone verengt hat. Und überprüfen Sie Ihre Zahlen jedes Mal, wenn eine echte Unbekannte geklärt wurde.