Schätzfehler verstehen und systematisch vermeiden
Die erste Kostenschätzung eines Softwareprojekts weicht häufig von den späteren Ist-Werten ab – teilweise deutlich. Das ist nicht zwingend ein Versagen, sondern oft eine Folge komplexer Projektrahmenbedingungen. Wer die typischen Ursachen für Fehlschätzungen kennt, kann systematischer gegensteuern. Dieser Artikel analysiert die häufigsten Gründe und zeigt bewährte Gegenmaßnahmen.
1. Die häufigsten Schätzfehler
Der Optimismus-Bias
Menschen schätzen Aufwand systematisch zu niedrig ein. Besonders bei Aufgaben, die sie selbst gut kennen, wird die Komplexität unterschätzt.
- Typische Unterschätzung: 30–50 % des tatsächlichen Aufwands
- Besonders ausgeprägt bei: Erfahrenen Entwicklern (Paradox: Sie vergessen die Schwierigkeiten, weil sie Lösungen kennen)
Die „schon gemacht"-Illusion
Eine Anforderung klingt vertraut, aber die Details unterscheiden sich:
- „Login haben wir schon öfter gebaut" → Aber nicht mit SSO, 2FA und LDAP-Anbindung
- „Dashboard ist Standard" → Aber nicht mit Echtzeit-Daten aus 5 verschiedenen Quellen
Das Planungstrugschluss-Phänomen
Projekte werden anhand des Best-Case-Szenarios geplant, nicht anhand der wahrscheinlichsten Realität:
| Szenario | Annahme | Realität |
|---|---|---|
| Best Case | Alles läuft glatt | Tritt in < 10 % der Fälle ein |
| Likely Case | Normale Schwierigkeiten | Tritt in 60–70 % der Fälle ein |
| Worst Case | Massive Probleme | Tritt in 20–30 % der Fälle ein |
Die Werte in dieser Tabelle basieren auf Branchenschätzungen, Praxiserfahrungswerten und marktüblichen Angaben.
Die meisten Schätzungen basieren auf dem Best Case.
2. Die fünf häufigsten Ursachen für Fehlschätzungen
| Ursache | Typische Auswirkung | Beispiel |
|---|---|---|
| 1. Unvollständige Anforderungen | +30–50 % Kosten | „Das hatten wir nicht besprochen" |
| 2. Integrationsaufwand unterschätzt | +20–40 % Kosten | API-Dokumentation veraltet, Edge Cases |
| 3. Testing vergessen oder unterschätzt | +15–25 % Kosten | „Testing machen wir am Ende" |
| 4. Abhängigkeiten nicht berücksichtigt | +10–30 % Kosten | Zulieferer liefert nicht rechtzeitig; angespannter Fachkräftemarkt erschwert kurzfristige Kapazitäten [1] |
| 5. Kommunikationsaufwand ignoriert | +10–20 % Kosten | Meetings, Feedback, Abstimmung |
Die Werte in dieser Tabelle basieren auf Branchenschätzungen, Praxiserfahrungswerten und marktüblichen Angaben.
3. Gegenmittel: Bessere Schätzungen produzieren
Gegenmittel 1: Historische Daten nutzen
Vergleichen Sie mit abgeschlossenen Projekten:
Korrekturfaktor = Tatsächliche Kosten früherer Projekte ÷ Geschätzte Kosten
Wenn Projekte im Schnitt 1,4x teurer werden als geschätzt:
→ Neue Schätzung = Rohschätzung × 1,4Gegenmittel 2: Drei-Punkt-Schätzung konsequent anwenden
Für jede Position drei Werte abfragen:
| Position | Optimistisch | Wahrscheinlich | Pessimistisch | PERT-Wert |
|---|---|---|---|---|
| Login-System | 5 Tage | 8 Tage | 15 Tage | 8,7 Tage |
| Dashboard | 10 Tage | 15 Tage | 25 Tage | 15,8 Tage |
| API-Integration | 8 Tage | 12 Tage | 25 Tage | 13,5 Tage |
Die Werte in dieser Tabelle basieren auf Branchenschätzungen, Praxiserfahrungswerten und marktüblichen Angaben.
PERT = (O + 4×W + P) ÷ 6
Gegenmittel 3: Von verschiedenen Personen schätzen lassen
Unabhängige Schätzungen von 2–3 Personen liefern oft eine realistischere Bandbreite als eine einzelne Schätzung.
Gegenmittel 4: Bekanntes von Unbekanntem trennen
| Kategorie | Puffer |
|---|---|
| Bekannte Aufgaben (schon oft gemacht) | +10–15 % |
| Teilweise bekannt (ähnlich gemacht) | +20–30 % |
| Unbekannt (noch nie gemacht) | +40–60 % |
| Forschung/Prototyping nötig | +60–100 % |
Die Werte in dieser Tabelle basieren auf Branchenschätzungen, Praxiserfahrungswerten und marktüblichen Angaben.
Gegenmittel 5: Progressive Verfeinerung
Statt einer einmaligen Schätzung: Verfeinern Sie schrittweise.
| Zeitpunkt | Genauigkeit | Methode |
|---|---|---|
| Projektidee | ±50–100 % | Analogie |
| Nach Anforderungsworkshop | ±30–50 % | Parametrisch |
| Nach Architekturentwurf | ±15–30 % | Bottom-Up |
| Nach Sprint 1–2 | ±10–20 % | Velocity-basiert |
Die Werte in dieser Tabelle basieren auf Branchenschätzungen, Praxiserfahrungswerten und marktüblichen Angaben.
4. Typische Projektverläufe: Plan vs. Realität
| Meilenstein | Geplant | Typisch real | Abweichung |
|---|---|---|---|
| Konzeptphase | 3 Wochen | 4–5 Wochen | +33–67 % |
| Design-Abnahme | Woche 6 | Woche 8–10 | +33–67 % |
| MVP fertig | Woche 14 | Woche 18–22 | +29–57 % |
| Go-Live | Woche 20 | Woche 26–30 | +30–50 % |
Die Werte in dieser Tabelle basieren auf Branchenschätzungen, Praxiserfahrungswerten und marktüblichen Angaben.
5. Praxisbeispiel: Schätzung korrigieren
Ein Unternehmen plant eine Mitarbeiter-App. Erste Schätzung eines Entwicklers: 45 Tage, 45.000 €.
Korrektur mit den Gegenmitteln:
| Position | Erste Schätzung | Nach 3-Punkt-Schätzung | Mit Korrekturfaktor (1,35) |
|---|---|---|---|
| Frontend | 15 Tage | 18 Tage | 20 Tage |
| Backend | 15 Tage | 19 Tage | 22 Tage |
| Integrationen | 8 Tage | 12 Tage | 14 Tage |
| Testing | 5 Tage | 8 Tage | 9 Tage |
| PM/Abstimmung | 2 Tage | 6 Tage | 7 Tage |
| Gesamt | 45 Tage | 63 Tage | 72 Tage |
| Kosten (× 1.000 €/Tag) | 45.000 € | 63.000 € | 72.000 € |
Die Werte in dieser Tabelle basieren auf Branchenschätzungen, Praxiserfahrungswerten und marktüblichen Angaben.
Tatsächliche Kosten nach Projektabschluss: 68.000 € – die korrigierte Schätzung war 6 % daneben, die erste 34 %.
Fazit und Einordnung
1. Erste Schätzungen sollten als vorläufige Orientierung verstanden werden: Sie sind eher ein Startpunkt als eine abschließende Aussage.
2. Systematische Korrekturen können die Präzision erhöhen: Historische Korrekturfaktoren, Drei-Punkt-Schätzungen und unabhängige Sichtweisen helfen oft weiter.
3. Bekanntes und Unbekanntes sollten getrennt bewertet werden: Unklare Aufgaben verdienen in der Regel mehr Puffer.
4. Schätzungen profitieren von schrittweiser Verfeinerung: Mit jeder Phase verbessern sich Datenbasis und Aussagekraft.
5. Die Dokumentation von Schätzungen und Ist-Werten schafft Lernkurven: So lassen sich spätere Korrekturfaktoren belastbarer entwickeln.
Quellen
- Bitkom – Der Arbeitsmarkt für IT-Fachkräfte (2026-01-01)