45 Prozent Überschreitung beim Budget und im Schnitt 7 Prozent Verzögerung beim Zeitplan kennzeichnen viele grosse IT-Projekte. Golo Roden, Gründer und CTO der the native web GmbH, fasst dies in einem Heise-Longread zusammen: Firmen verlangen belastbare Antworten auf Kosten und Dauer, die die Branche seit Jahrzehnten nicht zuverlässig liefert. Betroffen sind Produktteams, Auftraggeber aus Industrie und Dienstleistung sowie Finanzplaner, von Startups bis zu Grosskonzernen; das Scheitern der Schätzungen belastet Budgets, Cashflow-Planung und Entscheidungsfristen. Praktische Gegenmittel nenen die Quellen Wahrscheinlichkeitsaussagen, häufige Neuschätzungen und transparentere Annahmen.

Die Lesart der Daten ist klar und unbequem: Schätzungen sind systematisch zu optimistisch. Das bedeutet nicht nur unliebsame Nachverhandlungen, sondern reale finanzielle Folgen. Heise analysiert in seinem Longread historische Studien und konstatiert, dass Projekte über Dekaden hinweg länger dauerten, mehr kosteten und weniger lieferten als geplant. Golo Roden, der Autor und CTO, macht deutlich, dass die Nachfrage der Geschäftsseite nach festen Antworten auf die Frage "Wie teuer? Wie lange?" auf eine Branche trifft, die solche Antworten nicht zuverlässig geben kann.

Warum Schätzungen so oft danebenliegen

Mehrere, sich ergänzende Faktoren erklären das Muster. Erstens: unbekannte Unbekannte sind die Regel, nicht die Ausnahme. Ein Praxisblog konstatiert, dass zu Projektbeginn oft nur rund 60 Prozent des erwarteten Aufwands identifizierbar sind. Der verbleibende Aufwand wird während der Umsetzung entdeckt. Diese Entdeckungen reichen von falsch dokumentierten API-Formaten über unerwartete Lastspitzen bei konkurrierenden Nutzerzugriffen bis zu plattformabhängigen Besonderheiten. Jede solcher Entdeckungen kostet Stunden bis Tage und verschiebt damit Budget und Zeitplan.

Zweitens skaliert Komplexität nicht linear. Ein Beitrag rechnet vor: Mit wenigen Funktionen bleiben Interaktionen überschaubar; bei zehn Funktionen entstehen schon 45 mögliche Interaktionen, bei 15 Funktionen 105. Diese Kombinatorik macht aus marginalen Funktionsänderungen schnell exponentielle Mehraufwände. Das erklärt, warum das Hinzufügen einzelner Features ganze Projekte deutlich verteuern kann, auch wenn die Basisfunktionalität vermeintlich stabil bleibt.

Drittens greifen kognitive Verzerrungen. Entwicklerinnen und Entwickler tendieren dazu, den Idealverlauf zu modellieren. Hinzu kommt Scope Creep: Aus einem einfachen Kontaktformular wird ein Ticket-System mit Prioritäten und Eskalationsregeln. Douglas Hofstadter formulierte eine Regel, die hier in der Praxis oft zitiert wird: Es dauert immer länger als man denkt, selbst wenn man die Hofstadter-Regel berücksichtigt.

Mastheads

Die Formulierung steht in den Quellen als nüchterne, empirische Beobachtung, nicht als Ironie.

Viertens ist die Kommunikation ein strukturelles Problem. Was technische Teams als vorläufige Schätzung verstehen, wird von Auftraggebern häufig als verbindliches Versprechen interpretiert. Dieser Bedeutungsunterschied führt zu veritablen Konflikten über Scope, Termine und Budget. LinkedIn-Autoren wie Volker Schukai empfehlen deshalb Wahrscheinlichkeitsaussagen statt fixer Deadlines, zum Beispiel eine 80-prozentige Wahrscheinlichkeit, dass ein Release innerhalb eines Zeitfensters gelingt.

Was Teams anders machen können

Die Quellen bieten keine Patentrezepte, aber eine Reihe pragmatischer, sich ergänzender Praktiken. Gemeinsam ist ihnen die Einsicht, Schätzungen als lebende Vorhersagen zu behandeln, nicht als ein Einmalversprechen. Das bedeutet: regelmässige Neuschätzungen entlang des Fortschritts, klare Benennung der Annahmen und transparente Kommunikation über Risiken und Unbekannte.

Methodisch raten mehrere Stimmen zur Kombination: Expertenurteil, Story-Points und historische Daten sollen zusammen eine stabilere Basis liefern. Volker Schukai auf LinkedIn nennt explizit Wahrscheinlichkeitsaussagen als Mittel, um Erwartungen zu kalibrieren. Andere Stimmen betonen, dass bessere Tools allein das Problem nicht lösen; es brauche veränderte Denkweisen und Prozesse, die das Unbekannte von Beginn weg einkalkulieren.

Eine kulturelle Komponente spielt mit: Geert Dekkers argumentiert auf LinkedIn, dass massgeschneiderte Software eher mit handgefertigten Autos der Frühindustrialisierung vergleichbar ist als mit Serienproduktion. Jedes Projekt bleibe einzigartig, deshalb lasse es sich schlecht standardisieren. Diese Perspektive verschiebt den Fokus weg von punktgenauen Schätzungen hin zu flexibler Planung und kontinuierlicher Anpassung.

Operativ genannt werden wenige, aber konkrete Massnahmen: Erste, grobe Schätzungen setzen und diese dann periodisch verfeinern; Annahmen dokumentieren und mit Auftraggebern besprechen; Wahrscheinlichkeitsaussagen verwenden statt fester Termine. Solche Praktiken reduzieren nicht alle Überraschungen, sie machen jedoch die Unsicherheit sichtbar und handhabbar.

Für Finanzplaner und Entscheidungsträger heisst das: Budgets und Cashflow-Modelle müssen Puffer und Wahrscheinlichkeiten einrechnen, Entscheidungsfristen sollten Flexibilität erlauben. Wenn Unternehmen weiterhin starre Deadlines und fixe Budgets verlangen, drohen häufige Nachfinanzierungen und verzögerte Markteintritte.

Related Articles

Teams sollten Schätzungen als fortlaufende Vorhersagen behandeln: regelmässige Neuschätzungen, dokumentierte Annahmen und explizite Wahrscheinlichkeitsaussagen. Entscheidend ist, ob Unternehmen diese Praktiken in Projekt-Reviews und Budgetmodellen verankern, zum Beispiel durch Puffer in Cashflow-Prognosen und standardisierte Wahrscheinlichkeitsangaben in Roadmaps.

Dieser Artikel wurde mit KI-Unterstützung erstellt.