129 Stunden gegen 49: Anatomie eines Fehlers in der Aufwandsschätzung
In unserem Archiv liegt ein saisonales Landingpage-Projekt. Abgerechnet wurden 49 Stunden. Tatsächlich verbraucht wurden 129. Das Projekt ist abgenommen, der Kunde zufrieden, die Zahlung eingegangen – und es ist der einzige Fall, in dem ich beide Zahlen mit Sicherheit kenne, weil beide in den Unterlagen erhalten geblieben sind.
Eine Abweichung um das 2,6-Fache ist weder Rekord noch Ausnahme. In einer Felduntersuchung von 52 Projekten trat eine Aufwandsüberschreitung in 76 % der Fälle auf, im Durchschnitt betrug sie 41 %. Die Frage, die bei der Aufwandsschätzung eines Projekts zu stellen ist, lautet nicht „wie viele Stunden“, sondern „zu welchem Zeitpunkt und auf welcher Grundlage wurde diese Zahl genannt“.
Eine Schätzung ist nicht deshalb falsch, weil jemand die Stunden schlecht zählt. Sie ist falsch, weil sie genannt wird, bevor die Anforderungen festgelegt sind, und die zuerst genannte Zahl danach als Ankereffekt für alle folgenden Neuberechnungen wirkt. Die Lösung liegt nicht in genauerer Rechnung, sondern darin, die Schätzung zu einer eigenständigen Prozessstufe zu machen – nach der Festlegung des Leistungsumfangs und vor der Unterschrift.
Wohin die 80 unvorhergesehenen Stunden geflossen sind
Die Antwort „die Komplexität unterschätzt“ erklärt nichts und behebt nichts. Hilfreich ist etwas anderes: die Abweichung in einzelne Ereignisse zu zerlegen, die sich jeweils benennen und datieren lassen. In diesem Projekt waren es fünf solcher Ereignisse, und keines davon sah im Moment seines Auftretens wie ein Problem aus.
Die Schätzung wurde vor der Festlegung des Leistungsumfangs genannt. Die Zahl fiel im ersten Telefonat, als Antwort auf die Frage „ungefähr wie viel wird das“. Die grobe Zahl sollte dem Kunden nur die Größenordnung der Kosten vermitteln – und wurde stattdessen zur vereinbarten Zahl. Zwischen „ungefähr“ und „vereinbart“ lag kein einziges Dokument.
Jede Präzisierung kam einzeln. Einen Block mit dem Programm ergänzen. Preise in zwei Währungen anzeigen. Eine separate Version für den Newsletter erstellen. Jede einzelne Präzisierung bedeutete eine halbe bis eine Stunde, und sie abzulehnen wirkte kleinlich. Die Summe dieser halben Stunden machte den größten Teil der Abweichung aus.
Die Abstimmung galt als kostenlos. In die Schätzung floss die Arbeit von Designer und Layouter ein. Nicht enthalten waren: der Schriftwechsel, drei Korrekturrunden am Text, das Warten auf Materialien, der erneute Zusammenbau, nachdem der Kunde das Layout einem Kollegen gezeigt hatte. Das sind Stunden des Projektleiters und Stunden des Ausführenden, und sie fallen an – unabhängig davon, ob sie eingeplant wurden oder nicht.
Die Saisonalität hat den Puffer aufgezehrt. Das Projekt war für den Jahreswechsel bestimmt, der Starttermin stand fest. Wenn die Arbeit sich verzögert und das Datum fixiert ist, bleibt als einzige verfügbare Ressource die Zeit der Mitarbeiter am Abend und am Wochenende. Der Puffer, der sich in einem gewöhnlichen Projekt in einer Terminverschiebung ausdrückt, äußerte sich hier unmittelbar in Mehraufwand.
Niemand hat zwischendurch neu gerechnet. Das Signal für die Überschreitung tauchte etwa zur Halbzeit auf – und wurde nicht zu einem Gespräch. Ein Gespräch über Geld, wenn die Arbeit zur Hälfte erledigt ist, ist immer unangenehmer als am Anfang, deshalb wird es bis zum Ende aufgeschoben, wo es keinen Sinn mehr hat.
| Ereignis | Was verloren geht | Wer es bemerkt |
|---|---|---|
| Schätzung vor Festlegung des Leistungsumfangs genannt | Das Recht, die Zahl gesichtswahrend zu revidieren | Niemand – die Zahl wirkt wie ein Glücksfall |
| Präzisierungen kommen einzeln | Stunden der Ausführenden, jeweils eine nach der anderen | Der Ausführende – und schweigt |
| Abstimmung ist nicht in der Schätzung enthalten | Die gesamte Zeit des Projektleiters | Niemand – diese Stunden werden nirgends erfasst |
| Fixiertes Datum ohne Puffer | Abende und Wochenenden des Teams | Das Team – in Form von Erschöpfung, nicht als Zahl |
| Keine Neuberechnung zur Halbzeit | Die Möglichkeit, sich zu einigen | Die Geschäftsführung – am Monatsende |
Achten Sie auf die dritte Spalte. Drei von fünf Ereignissen sieht im Unternehmen niemand: Für sie gibt es weder einen Bericht noch einen Verantwortlichen noch einen Moment, in dem sie auffallen müssten. Genau deshalb wiederholen sie sich.
Warum die zuerst genannte Zahl alle folgenden bestimmt
Die Abweichung in der Schätzung ist keine Eigenschaft eines bestimmten Teams. Es ist eine stabile Gesetzmäßigkeit, die in unterschiedlichen Stichproben und in unterschiedlichen Ländern reproduziert wurde. Und sie hat einen Mechanismus, der eigens beschrieben ist.
In der Untersuchung realer Softwareprojekte trat eine Aufwandsüberschreitung in 76 % der Fälle auf, im Durchschnitt betrug sie 41 %. In der Zusammenfassung früherer internationaler Übersichtsarbeiten nennt der Autor eine typische Unterschätzungsspanne von 30–40 %.
Die Einschränkung dieser Daten sei selbst genannt: Die Stichprobe ist norwegisch, zwanzig Jahre alt, und die tatsächlichen Stunden wurden aus den Aussagen der Projektleiter erhoben, nicht aus einem Zeiterfassungssystem. Der Wert liegt nicht in der Genauigkeit des Prozentsatzes, sondern in der Beständigkeit des Befunds selbst – Aufwandsüberschreitung erweist sich als Normalfall, nicht als Abweichung.
Jetzt wird es interessant. Eine Übersicht empirischer Arbeiten zur Expertenschätzung zeigt, dass es nicht an der Arithmetik liegt, sondern an der Reihenfolge, in der die Zahlen auftauchen.
Expertenschätzungen des Aufwands verschieben sich systematisch zur zuerst genannten Zahl – dem „Anker“. Eine frühe grobe Einschätzung, die bei minimaler Informationslage entsteht, beeinflusst spätere Neuberechnungen weiter, selbst nachdem präzisierte Anforderungen vorliegen.
Es handelt sich um eine Übersichtsarbeit, die fremde Experimente zusammenfasst, einige davon Laborversuche – einen genauen Anteil der Fälle, in denen der Ankereffekt wirkt, enthält sie nicht. Aber die qualitative Schlussfolgerung erklärt unseren Fall genauer als jede Zahl: „ungefähr 49“ im ersten Telefonat war keine Schätzung. Es war ein Anker, an dem sich danach alle Berechnungen ausrichteten, auch jene, die bereits mit vollständigem Verständnis des Leistungsumfangs erstellt wurden.
Was sich nach diesem Projekt geändert hat
Die Konsequenz, die wir gezogen haben, betraf nicht die Rechenmethode, sondern die Struktur des Prozesses. Die Schätzung hörte auf, eine Bemerkung im Gespräch zu sein, und wurde zu einer eigenständigen Stufe mit eigenem Input und Output. Der Ablauf sieht seither so aus: Anfrage, Klärung der Aufgabe, Lastenheft, Aufwandsschätzung, Abstimmung, Durchführung, Abnahme, drei Tage Abnahmefrist.
In diesem Ablauf sind zwei Dinge entscheidend. Erstens: Die Schätzung steht nach dem Lastenheft, nicht davor – kalkulieren lässt sich nur, was beschrieben ist. Zweitens: Zwischen Schätzung und Durchführung steht die Abstimmung, also ein expliziter Punkt, an dem beide Seiten dieselbe Zahl sehen und bestätigen.
Der zweite Teil der Lösung ist finanzieller Natur. Im Support entstanden Wartungspauschalen mit ausdrücklich benanntem Leistungsumfang und einem separaten Satz für Stunden darüber hinaus. Nicht weil das lukrativer wäre, sondern weil bei diesem Aufbau das Gespräch über zusätzliche Stunden nach einer Regel geführt wird und nicht nach Stimmungslage.
Wie groß die typische Abweichung tatsächlich ist
Außerhalb dieses Vergleichs bleibt das Wichtigste: Durchschnittswerte täuschen. Die Verteilung der Überschreitungen ist asymmetrisch – der Großteil des Risikos sitzt nicht in der Mitte, sondern im Ausläufer der Verteilung, und genau deshalb schützt eine Planung nach dem Durchschnitt nicht.
In einer Stichprobe von 1.471 IT-Projekten lag die durchschnittliche Budgetüberschreitung bei 27 %. Dabei erwies sich jedes sechste Projekt als „schwarzer Schwan“: Budgetüberschreitung im Schnitt 200 % und Terminüberschreitung von fast 70 %.
Die Einschränkung ist hier erheblich: Es handelt sich um große Unternehmens- und Regierungsinitiativen, nicht um ein saisonales Landingpage-Projekt. Übertragbar ist nicht der Maßstab, sondern die Form der Verteilung. Eines von sechs Projekten läuft aus dem Ruder, und es wird durch den Gewinn der übrigen fünf finanziert.
Was sich 2026 geändert hat und was nicht
Geändert hat sich, dass ein Teil der Arbeit tatsächlich schneller geworden ist. Prototyp, Textentwurf, Anforderungsanalyse, erste Version eines Schemas – all das entsteht jetzt spürbar schneller, und die Versuchung, die Schätzung deswegen zu senken, ist groß. Nicht geändert hat sich, woher die Abweichung stammt: Sie stammt aus dem Leistungsumfang, nicht aus der Ausführungsgeschwindigkeit.
52 % der Projekte, die in den vorangegangenen 12 Monaten abgeschlossen wurden, waren von unkontrollierter Ausweitung des Leistungsumfangs (Scope Creep) betroffen. Fünf Jahre zuvor lag dieser Wert bei 43 %.
Der Bericht beruht auf Selbstauskünften von Praktikern und wurde von einem Berufsverband veröffentlicht, der ein Interesse daran hat, seine eigenen Standards zu verbreiten – das sollte man im Hinterkopf behalten. Aber die Richtung der Veränderung ist aufschlussreich: Der Anteil der Projekte mit Scope Creep steigt, statt zu sinken – trotz zwei Jahrzehnten methodischer Weiterentwicklung.
Die praktische Schlussfolgerung daraus ist einfach. Wenn ein Werkzeug die Ausführung um das Doppelte beschleunigt hat, der Leistungsumfang aber weiterhin einzeln und stillschweigend präzisiert wird, bleibt die Abweichung zwischen Schätzung und Ist-Wert bestehen – sie wird nur in anderen Einheiten ausgedrückt.
Vier Regeln der Projektsteuerung, die den größten Teil der Abweichung beseitigen
Keine Zahl vor der Festlegung des Leistungsumfangs nennen
Auf die Frage „ungefähr wie viel“ gibt es eine sichere Antwort: eine Größenordnungsspanne und einen Termin, bis zu dem die Schätzung vorliegt. Alles andere wird zum Anker.
Nicht nur die Produktion kalkulieren
Abstimmung, Warten auf Materialien, Korrekturrunden und erneuter Zusammenbau sind Stunden. Stehen sie nicht in der Schätzung, existieren sie trotzdem im Ist-Aufwand.
Festhalten, was nicht enthalten ist
Die Liste der Ausschlüsse ist kürzer als die Leistungsliste und wirkt besser als diese. Gerade sie macht aus einer Präzisierung ein eigenes Gespräch statt einer kostenlosen Zugabe.
Zur Halbzeit neu rechnen
Legen Sie einen Punkt fest, an dem der Ist-Wert mit der Schätzung verglichen wird, und machen Sie ihn verpflichtend. Ein unangenehmes Gespräch in der Projektmitte ist billiger als ein stillschweigendes Abschreiben am Ende.
Wenn eine Zahl im Schriftwechsel auftaucht, bevor der Leistungsumfang beschrieben ist, schätzen Sie das Projekt nicht mehr – Sie verhandeln über eine Zahl, die zufällig gefallen ist.
Häufig gestellte Fragen zur Aufwandsschätzung
Wie schätzt man den Aufwand eines Projekts richtig, wenn die Anforderungen noch nicht feststehen?
Gar nicht – und das ist die ehrliche Antwort. Vor der Festlegung des Leistungsumfangs wird nicht das Projekt geschätzt, sondern eine Stufe: wie viel Zeit die Anforderungsanalyse und die Erstellung des Lastenhefts in Anspruch nehmen. Diese Stufe lässt sich genau schätzen, weil ihr Inhalt bekannt ist. Die Schätzung des gesamten Projekts erfolgt danach, und der Kunde erhält nicht eine Zahl zu Beginn, sondern zwei zu festgelegten Zeitpunkten.
Was tun, wenn der Kunde sofort eine Zahl verlangt?
Eine Größenordnungsspanne nennen und einen Termin, bis zu dem die Schätzung vorliegt. Die Spanne muss breit genug sein, um nicht selbst zum Anker zu werden: „zwischen zwei und sechs Wochen, genauer nach dem Lastenheft“. Eine enge Spanne, aus dem Wunsch genannt, kompetent zu wirken, funktioniert wie eine exakte Zahl und erzeugt dasselbe Problem.
Welchen Risikopuffer sollte man in die Schätzung einplanen?
Ein prozentualer Risikopuffer löst das Problem nicht, weil die Abweichung durch die Änderung des Leistungsumfangs entsteht, nicht durch eine ungenaue Berechnung. Wirksam ist etwas anderes: eine separate Budgetposition für Anforderungen, die nach der ersten Ergebnispräsentation auftauchen, mit eigenem Verantwortlichen und einer Regel für ihre Verwendung. Fehlt diese Position, werden die Anforderungen trotzdem umgesetzt – auf Kosten des Ausführenden.
Wie aussagekräftig ist die Abweichung 129 gegen 49 Stunden?
Das ist ein Projekt eines einzelnen Unternehmens, kein Branchenmaßstab. Aussagekräftig daran ist nicht das Verhältnis, sondern dass beide Zahlen erhalten geblieben sind: Der tatsächliche Aufwand wurde festgehalten, nicht aus dem Gedächtnis rekonstruiert. In den meisten Unternehmen lässt sich ein solcher Vergleich gar nicht anstellen, weil der tatsächliche Aufwand nirgends erfasst wird.
Die Zahlen „129 Stunden tatsächlich“ und „49 Stunden abgerechnet“ stammen aus der internen Kalkulation eines saisonalen Landingpage-Projekts im Archiv von Alego.Digital. Die Abfolge der Stufen (Anfrage → Klärung → Lastenheft → Aufwandsschätzung → Abstimmung → Durchführung → Abnahme → drei Tage Abnahmefrist) und das Pauschalmodell mit separatem Satz für zusätzliche Stunden stammen aus dem Regelwerk für die Kundenkommunikation derselben Periode. Es handelt sich um interne Dokumente des Unternehmens des Autors; sie wurden nicht von unabhängiger Seite geprüft und dienen als Illustration der Mechanik, nicht als Branchenmaßstab. Die Liste der fünf Ereignisse, in die die Abweichung zerlegt wurde, ist anhand der Projektunterlagen und des Schriftwechsels rekonstruiert.
- Moløkken-Østvold K. J. Effort and Schedule Estimation of Software Development Projects. University of Oslo, PhD thesis, August 2004. simula.no
- Jørgensen M. A Review of Studies on Expert Estimation of Software Development Effort. Journal of Systems and Software, 2004. simula.no
- Flyvbjerg B., Budzier A. Why Your IT Project May Be Riskier Than You Think. Harvard Business Review, September 2011. hbr.org
- Project Management Institute. Pulse of the Profession 2018 (Befragung von 5.402 Teilnehmern). pmi.org