In den meisten Projekten gilt stillschweigend: Jede Abweichung ist ein Schätzfehler. 300 Stunden geschätzt, 340 gebraucht, also Fehlschätzung, und eine Rechtfertigung ist fällig.
Die Frage „Wann ist eine Abweichung ein Schätzfehler?“ wird selten gestellt. Dabei hängt an der Antwort Vertrauen. Teams stehen für etwas gerade, das gar kein Fehler war. Und der echte Fehler bleibt unentdeckt, weil niemand zwischen den Fällen unterscheidet.
Wann ist eine Abweichung ein Schätzfehler: die Definition
Aus der Projektpraxis hat sich eine Definition bewährt: Ein Schätzfehler liegt vor, wenn der tatsächliche Aufwand die geschätzte Bandbreite verlässt und die Ursache dafür schon zum Zeitpunkt der Schätzung erkennbar gewesen wäre.
Das sind zwei Bedingungen, und beide müssen erfüllt sein. Daraus ergeben sich drei Fälle:
- Der Aufwand liegt innerhalb der Bandbreite. Dann hat die Schätzung funktioniert, auch wenn der Wert über dem Mittelwert liegt.
- Der Aufwand liegt außerhalb der Bandbreite, die Ursache war aber nicht absehbar. Das ist kein Schätzfehler, sondern ein Projektrisiko, das eingetreten ist. Ein Beispiel wäre eine Schnittstelle, die sich nach dem Start ohne Vorwarnung ändert.
- Der Aufwand liegt außerhalb der Bandbreite, und die Ursache hätte man kennen können. Das ist ein Schätzfehler, und aus ihm lässt sich lernen.
Bei den 300 geschätzten und 340 gebrauchten Stunden hängt die Antwort deshalb von der Spanne ab. Lag sie zum Beispiel bei 250 bis 420 Stunden, ist nichts schiefgegangen. Hat dagegen niemand eine Spanne genannt, fehlt die Grundlage für die Bewertung.
Vier typische Ursachen
Wenn ein Schätzfehler vorliegt, steckt dahinter meist eine von vier Ursachen:
- Ganze Aufgaben wurden vergessen, etwa Projektmanagement, Qualitätssicherung, Dokumentation, Installation oder Support.
- Die Arbeit wurde zu grob zerlegt.
- Risiken wurden kleingeredet.
- Faktisch wurde nur der beste Fall geschätzt, und die beiden anderen Werte der Dreipunktschätzung sind kosmetisch gefüllt.
Wie ein Schätzprozess aufgebaut ist, der diese Ursachen vermeidet, steht im Beitrag Softwareprojekte schätzen. Hier geht es um die Bewertung danach.
Die Schätzung war nicht falsch, sondern unvollständig
Ein Fall zeigt den ersten Punkt deutlich. Ein Projekt ist vier Monate zu spät, aber kein einziger Entwickler hat sich verschätzt. Das ist kein Widerspruch. Geschätzt wurde die Implementierung und sonst nichts. Alles andere ist trotzdem angefallen, es stand nur nirgends:
- das Projekt aufsetzen
- Analyse und Spezifikation
- Tests der Schnittstellen zu anderen Systemen, etwa ERP, Shop oder Lohnbuchhaltung
- Projektmanagement und Qualitätssicherung
- technische Dokumentation und Benutzerhandbuch
- Schulung der Anwender
- Installation und Support während der Einführung
Dazu kommen Anforderungen, über die im Kick-off niemand spricht, weil sie selbstverständlich wirken. Muss die Anwendung auf dem Handy laufen? Wie schnell muss eine Seite laden? Auf welcher Infrastruktur läuft sie am Ende? Nichts davon ist ein Sonderfall, das stand vom ersten Tag an fest. Es tauchte nur in keiner Zeile der Schätzung auf.
Die Schätzung war also nicht falsch. Sie war unvollständig. Das merkt man erst, wenn das Projekt schon läuft, und dieselbe Lücke kommt im nächsten Projekt wieder, auf exakt dieselbe Weise. Auch wir haben früher selbst Posten vergessen und es im Budget gespürt.
Einen schnellen Test gibt es auch für Verantwortliche, die selbst nie schätzen, aber mit der Zahl planen, Kapazitäten daran hängen oder sie im Lenkungskreis nennen. Sie nehmen die letzte Schätzung, die auf ihrem Tisch lag, und suchen darin nach Projektmanagement, Schulung, Dokumentation und einem Wort zu den Schnittstellen. Wer nur Funktionen findet, weiß, warum die Planung nie aufgeht. Eine Prüfung in fünf Schritten liefert der Beitrag Aufwandsschätzung prüfen.
Nicht die einzelne Abweichung zählt, sondern die Summe
Einzelne Aufgaben liegen immer daneben, in beide Richtungen. Das gehört zum System. Eine Aufgabe, die länger dauert, wird durch eine andere ausgeglichen, die schneller geht. Kritisch wird es erst, wenn die Abweichungen einseitig sind.
Landet fast alles über dem Normalwert, ist das kein Problem von 30 Einzelschätzungen. Es ist ein Problem der Grundhaltung beim Schätzen oder der Projektfaktoren, also etwa einer Schnittstelle, die in allen Aufgaben mitläuft. Wer das erkennt, korrigiert an der richtigen Stelle, statt einzelne Entwickler für einzelne Positionen zur Rede zu stellen.
Die Bandbreite ist ein Arbeitsmittel, kein Angebot
Intern arbeitet ein Team mit einer Spanne aus günstigem, realistischem und ungünstigem Wert. Dem Auftraggeber legt man keine Spanne vom Faktor drei auf den Tisch. Er bekommt einen Wert, und es wird ausgewiesen, wie viel Risiko darin steckt. Intern bleibt die Spanne, extern wird daraus eine Zahl mit Begründung.
Für die Bewertung heißt das: Die Spanne muss intern dokumentiert sein. Sonst lässt sich nach dem Projekt nicht entscheiden, ob eine Abweichung innerhalb oder außerhalb lag.
Ein Schätzfehler wird erst zum echten Fehler, wenn niemand daraus lernt
Der wichtigste Schritt kommt nach dem Projektende. Die tatsächlichen Werte werden gegen die Schätzung gelegt, und das Team schaut sich die Muster an: Welche Posten fehlten? Wo lag die Spanne zu eng? Welche Risiken wurden unterschätzt? Beim nächsten Mal wird besser geschätzt. Genau so ist unser Schätzsheet entstanden, Projekt für Projekt.
Das Schätzsheet enthält die Dreipunktschätzung, Risikofaktoren, die häufig vergessenen Posten und eine Checkliste. Es eignet sich für eigene Schätzungen und als Vergleichsmaßstab neben einer Schätzung, die ein Dienstleister vorlegt. Das Schätzsheet gibt es als Excel und als Google Sheet zum Download.
Schätzsheet Download
Fazit
Eine Abweichung ist erst dann ein Schätzfehler, wenn der Aufwand die Bandbreite verlässt und die Ursache schon bei der Schätzung erkennbar war. Alles andere ist Streuung oder ein eingetretenes Risiko. Wer so unterscheidet, entlastet Teams von unnötigen Rechtfertigungen, findet die echten Ursachen wie vergessene Posten schneller und verbessert die nächste Schätzung.
