Warum Software-Schätzungen immer falsch sind — und wie du trotzdem planbar bleibst

„Das dauert 3 Wochen.” Es dauerte 7. „Budget: 15.000 €.” Am Ende waren es 28.000 €. Nicht weil jemand gelogen hat. Nicht weil der Entwickler schlecht war. Sondern weil Software-Schätzungen grundsätzlich falsch sind.

Das ist kein Branchenproblem. Es ist ein Naturgesetz der Softwareentwicklung. Und je eher du das akzeptierst, desto besser wirst du damit umgehen.

Warum Schätzungen systematisch falsch sind

Grund 1: Unbekannte Unbekannte

Bei einem Hausbau weißt du von Anfang an: Fundament, Wände, Dach, Fenster, Türen. Die Überraschungen sind begrenzt.

Bei Software weißt du am Anfang 60% dessen was gebaut werden muss. Die restlichen 40% entdeckst du während der Entwicklung:

• „Ach, die API gibt die Daten in einem anderen Format zurück als dokumentiert.”
• „Warte, wenn zwei Nutzer gleichzeitig denselben Datensatz bearbeiten…”
• „Dieses Feature braucht eigentlich auch eine Admin-Ansicht.”
• „Das funktioniert auf iOS anders als auf Android.”

Jede dieser Entdeckungen kostet Stunden bis Tage. Und sie sind nicht vorhersehbar — deshalb heißen sie „unbekannte Unbekannte.”

Grund 2: Komplexität ist nicht linear

10 Features sind nicht doppelt so aufwändig wie 5 Features. Sie sind 4x so aufwändig. Warum? Weil jedes neue Feature mit jedem bestehenden Feature interagieren kann.

Deshalb explodieren große Projekte. Nicht weil die einzelnen Features kompliziert sind — sondern weil ihre Kombinationen es sind.

Grund 3: Optimismus-Bias

Entwickler schätzen wie lange eine Aufgabe dauert wenn alles glatt läuft. Und nichts läuft jemals alles glatt.

Die mentale Rechnung: - Feature X: „Das ist nur ein Formular. 4 Stunden.” - Realität: Formular (2h) + Validierung (1h) + Fehlerbehandlung (1h) + Edge Cases (2h) + Tests (1h) + Design-Anpassung (1h) + Bug der nur in Safari auftritt (2h) = 10 Stunden

Der Entwickler hat nicht gelogen. Er hat geschätzt wie ein Mensch schätzt: optimistisch.

Grund 4: Requirements ändern sich

Am Anfang des Projekts: „Ein einfaches Kontaktformular.” Woche 2: „Können wir auch Dateien anhängen?” Woche 4: „Eigentlich brauchen wir ein Ticket-System.” Woche 6: „Mit Prioritäten und Eskalation.”

Das ursprüngliche Kontaktformular: 1 Tag. Das Ticket-System: 3 Wochen. Die Schätzung vom Anfang? Irrelevant.

Und ja — Scope Creep ist eines der Warnsignale für scheiternde Projekte. Aber selbst ohne Scope Creep ändern sich Anforderungen, weil du während der Entwicklung lernst was du wirklich brauchst.

Die Hofstadter-Regel

„Es dauert immer länger als man denkt, selbst wenn man die Hofstadter-Regel berücksichtigt.” — Douglas Hofstadter

Das ist keine Pointe. Das ist eine wissenschaftlich bestätigte Beobachtung. Selbst wenn du weißt dass Schätzungen falsch sind und einen Puffer einplanst — der Puffer ist meistens auch zu klein.

Die Faustregel für Software-Projekte:

Das ist kein Sarkasmus. Das ist empirische Erfahrung aus tausenden Projekten.

Wie du trotzdem planbar bleibst

Akzeptieren dass Schätzungen falsch sind bedeutet nicht dass du nicht planen kannst. Es bedeutet, dass du ANDERS planen musst.

Strategie 1: In kleinen Einheiten schätzen

Große Blöcke sind ungenau. Kleine Blöcke sind genauer.

Schlecht: „Die App dauert 3 Monate.” Gut: „Sprint 1 (2 Wochen): Login und Nutzerverwaltung. Sprint 2 (2 Wochen): Kundenverwaltung. Sprint 3: …”

Warum: Über 2 Wochen kann sich ein Entwickler nur um Faktor 1,5 verschätzen. Über 3 Monate um Faktor 3.

Strategie 2: Meilensteine statt Deadlines

Statt einen Endtermin zu setzen, definiere Meilensteine. Jeder Meilenstein ist ein funktionierendes Zwischenergebnis:

Der Vorteil: Nach jedem Meilenstein kannst du entscheiden: Weitermachen, Umfang anpassen oder stoppen. Du bist nie „80% fertig mit nichts in der Hand.”

Strategie 3: Budget-Range statt Festpreis

Professionelle Schätzungen kommen in Ranges, nicht als einzelne Zahl:

Schlecht: „Das kostet 15.000 €.” Gut: „Das kostet 12.000–18.000 €. Am wahrscheinlichsten 15.000 €.”

Die Range kommuniziert Unsicherheit — und gibt dir als Auftraggeber die Möglichkeit für den schlimmsten Fall zu planen. Wenn dein Budget bei 15.000 € liegt und die Schätzung „12.000–18.000 €” lautet, weißt du: Es wird knapp. Besser das vorher zu wissen als am Ende überrascht zu werden.

Strategie 4: Puffer einplanen — bewusst

Der einfachste Trick: Nimm die Schätzung und multipliziere sie mit 1,5.

• Geschätzt: 8 Wochen → Plane: 12 Wochen
• Geschätzt: 15.000 € → Plane: 22.500 €

Das klingt nach viel. Aber es ist ehrlicher als eine optimistische Schätzung die dann überschritten wird. Und wenn das Projekt innerhalb der Schätzung bleibt — umso besser.

Strategie 5: Scope als Variable, nicht als Konstante

Bei den meisten Projekten sind 3 Variablen im Spiel:

• Scope (Umfang): Was gebaut wird
• Budget (Kosten): Was es kostet
• Timeline (Zeit): Wie lange es dauert

Du kannst 2 davon fixieren. Die dritte muss flexibel sein. Die meisten Auftraggeber fixieren Budget und Timeline — und sind dann überrascht wenn der Scope nicht reinpasst.

Besserer Ansatz: Fixiere Budget und Timeline. Mach den Scope flexibel. „Wir haben 15.000 € und 8 Wochen. Was bekommen wir dafür?” Das ist die Frage die zu realistischen Ergebnissen führt.

Was du von deinem Entwickler verlangen solltest

Ein professioneller Entwickler sollte:

1. Ranges statt Punktschätzungen geben: „8.000–12.000 €” statt „10.000 €”
2. Annahmen dokumentieren: „Diese Schätzung basiert auf der Annahme dass die API X kann und Y vorhanden ist”
3. Risiken benennen: „Das größte Risiko ist die Integration mit eurem alten System”
4. Regelmäßig aktualisieren: Nach jedem Sprint die Restaufwand-Schätzung anpassen
5. Transparent sein: „Wir sind bei 60% des Budgets und 50% des Umfangs — es wird knapp”

Wenn dein Entwickler auf die Frage „Wie genau ist deine Schätzung?” antwortet: „Ziemlich genau” — sei skeptisch. Ehrliche Antwort: „Innerhalb von ±30%, wenn sich die Anforderungen nicht ändern.”

Mehr dazu: Worauf du bei einem Entwickler achten solltest.

FAQ: Häufig gestellte Fragen

Heißt das, ich soll Festpreis-Projekte vermeiden?

Nicht unbedingt. Festpreis funktioniert wenn die Anforderungen glasklar sind und sich nicht ändern. Für MVPs und erste Versionen ist Festpreis oft möglich — weil der Umfang begrenzt ist. Für komplexe, evolutionäre Projekte ist Time-and-Materials (Stundenbasis) mit Budget-Cap oft ehrlicher.

Wie unterscheide ich eine schlechte Schätzung von einem schlechten Entwickler?

Eine schlechte Schätzung wird transparant kommuniziert und korrigiert: „Wir haben uns verschätzt, hier ist der neue Plan.” Ein schlechter Entwickler liefert Ausreden statt Updates und wird erst bei Nachfrage transparent. Der Unterschied liegt in der Kommunikation, nicht in der Abweichung.

Soll ich mit der günstigsten Schätzung gehen?

Nein. Die günstigste Schätzung ist fast immer die optimistischste. Vergleiche nicht nur den Preis, sondern auch: Was ist inklusive? Welche Annahmen wurden gemacht? Wie wird mit Änderungen umgegangen? Die „günstigste” Schätzung wird oft die teuerste wenn der Nachtrag kommt.

Wie viel Puffer ist angemessen?

50% auf die Erstschätzung. Ja, das klingt viel. Aber die Forschung zeigt dass Software-Projekte im Durchschnitt 66% über der ursprünglichen Schätzung liegen. 50% Puffer ist nicht pessimistisch — es ist realistisch.

Fazit: Plane für Unsicherheit, nicht für Perfektion

Software-Schätzungen sind immer falsch. Das ist okay. Es ist kein Zeichen von Inkompetenz — es ist die Natur der Arbeit. Was zählt ist nicht die Genauigkeit der Schätzung, sondern wie du mit der Ungenauigkeit umgehst.

Kleine Einheiten. Meilensteine statt Deadlines. Ranges statt Punktschätzungen. Puffer einplanen. Scope flexibel halten. Und vor allem: Transparenz von deinem Entwickler verlangen.

Dann kannst du planbar bleiben — selbst wenn die Schätzungen falsch sind.

Du planst ein Software-Projekt und willst von Anfang an realistisch kalkulieren? Wir arbeiten mit transparenten Meilensteinen, ehrlichen Schätzungen und ohne böse Überraschungen.

Jetzt Projekt kalkulieren lassen