Die vierschichtige Schätzvorlage, die wir tatsächlich an neue Kunden schicken, warum wir eine Vertrauensbandbreite nennen und was passiert, wenn uns die Zahlen überraschen.

Softwareschätzungen haben ein Reputationsproblem, und sie haben es verdient. Die meisten sind optimistische Fiktion im Tabellenkalkulations-Gewand. Der Kunde hört eine einzelne Zahl. Das Team hört eine Bandbreite mit einem Stoßgebet dran.

Wir machen das lange genug, um offen zu sagen: Das Angebot mit der „einen präzisen Zahl" ist meistens Theater. Mit den Jahren haben wir eine vierschichtige Vorlage entwickelt, die wir vor Vertragsabschluss an jeden neuen Kunden schicken – damit niemand eine Fantasie unterschreibt.

Dieser Beitrag ist diese Vorlage, öffentlich.

Das Problem mit der Einzelzahl

Wenn ein Anbieter auf der letzten Seite des Angebots „EUR 24.000" schreibt, hat er eines von drei Dingen getan:

1. Aggressiv gepolstert – die reale Zahl ist 15.000 €, der Rest ist Puffer für eigene Fehler. 2. Den Sonnenscheinfall geschätzt – nichts Unsicheres, keine Scope-Änderungen, alle Integrationen verhalten sich brav. Dieses Projekt wird überschritten. 3. Die Feature-Liste wörtlich geschätzt – die unscheinbaren 40 % eines echten Projekts (Auth, Rechte, Backups, Deployment, Übergabe) ignoriert. Auch dieses Projekt wird überschritten.

Alle drei Varianten enden am selben Punkt: einem unangenehmen Gespräch in der Projektmitte über „zusätzliche Kosten". Nur der Anbieter entgeht dem, der von Anfang an ehrlich war.

Die vier Schichten, die wir verwenden

Jedes Angebot von uns hat vier Schichten. Jede beantwortet eine andere Frage.

Schicht 1: Der Feature-Kern

Hier hören die meisten Angebote auf: eine Liste von Screens und Verhalten, jeweils mit Stunden.

Wir schreiben diese Schicht so granular wie möglich, aber mit einer strikten Regel: Kein Feature wird isoliert vom Datenmodell geschätzt. Wenn wir die Datenbanktabellen und die wichtigsten Constraints nicht benennen können, schätzen wir noch nicht – wir markieren es als *„Discovery erforderlich"* und bepreisen diese Discovery separat.

Ein typischer Eintrag:

• Bestellübersicht – Liste, Filter, Detailansicht, Statusübergänge (`offen → bezahlt → versendet → geliefert`), Schreibzugriff nur für Rolle `ops`. *42 Stunden.*

Die Stunden sind nicht frommer Wunsch. Sie sind an eine Aufgabe gebunden, die wir schon einmal in einem echten Projekt mit Code-Referenz erledigt haben.

Schicht 2: Die unsichtbare Arbeit

Diese 40 % streicht fast jedes Billigangebot stillschweigend heraus. Wir listen sie explizit:

• Authentifizierung & Rollen: Login, Passwort-Reset, Rollenmatrix, Session-Policy.
• Admin-Werkzeuge: Nutzerliste, Impersonation, Audit-Log, Datenexport.
• Infrastruktur: Domain, SSL, Datenbank, Backup-Job, Monitoring.
• Deployment-Pipeline: Staging-Umgebung, Deployment-Skript, Rollback-Plan.
• Dokumentation: Übergabedokument, Runbook, Liste bekannter Probleme.
• Übergabesitzung: Screenshare, Q&A, aufgezeichnete Tour.

Jede Zeile hier hat eine Zahl. Manchmal möchten Kunden, dass wir diesen Abschnitt streichen, „weil wir uns später darum kümmern". Wir tun es nicht. „Später" ist der Ort, an dem Projekte sterben. Diese Schicht entscheidet, ob die Software das erste Jahr überlebt.

Schicht 3: Das Integrationsrisiko-Budget

Drittanbieter-Integrationen sind die größte Einzelquelle für Schätzungsüberschreitungen. Nicht weil sie schwer sind, sondern weil sie in Produktion anders funktionieren als in der Demo.

Für jedes externe System (Payment-Gateway, SMS-Dienst, Versand-API, ERP, E-Mail-Dienst, SSO) fügen wir hinzu:

• Ein Discovery-Slice – meist 4 bis 8 Stunden – für echtes Lesen der Doku und einen minimalen Smoketest gegen die tatsächliche Sandbox.
• Einen Risikopuffer proportional dazu, wie oft wir mit genau dieser Integration gearbeitet haben. Ein Gateway, das wir monatlich liefern, bekommt 10 % Puffer. Ein regionales Gateway, das niemand im Team kennt, bekommt 40 %.

Wir sagen dem Kunden genau, welche Integration in welcher Kategorie ist und warum. Das ist der schnellste Weg, ein späteres „warum hat das mehr gekostet als ihr gesagt habt" in ein „wir hatten diese als Risiko markiert" zu verwandeln.

Schicht 4: Die Vertrauensbandbreite

Diese Schicht nimmt kaum jemand auf – und sie verändert das ganze Gespräch.

Statt einer Einzelzahl nennen wir eine Bandbreite mit expliziter Vertrauensstufe:

• P50 (der realistische Median) – was das Projekt kostet, wenn nichts Ungewöhnliches passiert.
• P80 (unangenehm, aber plausibel) – was es kostet, wenn zwei der bekannten Risiken eintreten.
• P95 (schlechtester vernünftiger Fall) – wenn die Hälfte der Risiken eintritt und eine Überraschung dazukommt.

Eine typische Schlusszeile sieht so aus:

• P50: 21.500 €
• P80: 26.000 €
• P95: 31.000 €
• Wir schlagen vor, auf P80 zu unterzeichnen, mit schriftlichem Scope-Change-Prozess. Schaffen wir es unter P50, bleibt die Differenz als Guthaben für die Wartung.

Diese letzte Klausel ist die stärkste Änderung, die wir je an unserem kommerziellen Modell vorgenommen haben. Sie gleicht unsere Interessen mit denen des Kunden ab – auf dem einzigen Weg, der wirklich zählt: finanziell.

Wie wir Änderungen während des Projekts behandeln

Ein Vertrag auf P80 hat trotzdem Änderungsanfragen. Wir behandeln sie nach einem simplen schriftlichen Protokoll:

1. Die Änderungsanfrage wird im gleichen Tracker wie der ursprüngliche Scope erfasst. 2. Wir schätzen sie genauso – kleiner Feature-Kern, mitgezogene unsichtbare Arbeit, Risikobandbreite. 3. Der Kunde stimmt schriftlich zu, bevor wir anfangen. 4. Die Bandbreite wird in der geteilten Projekttabelle aktualisiert, die beide Seiten sehen.

Nichts wird per Handshake im Chat entschieden. Das ist kein Misstrauen; es ist die Erinnerungspolitik, die verhindert, dass ein Chat zum Streitfall wird.

Was wir tun, wenn uns Zahlen überraschen

Manchmal merken wir mitten im Projekt, dass unsere Schätzung falsch war – nicht wegen einer Änderung, sondern weil wir in Schicht 1 oder 3 etwas übersehen haben. Echte Engineering-Teams stoßen darauf.

Unsere Regel: Wir sagen es dem Kunden in dem Moment, in dem wir es wissen – nicht in dem Moment, in dem die Rechnung fällig wird.

Das Gespräch läuft so: „Wir haben X gefunden. So wurde es in unserer Ursprungsschätzung nicht abgebildet. Drei Optionen – ein günstigerer Scope, eine bezahlte Änderung zu unseren Baukosten (ohne Marge auf die Korrektur), oder Neukalkulation, wenn die Lücke größer als 15 % ist." Fast immer entscheiden Kunden sich für Option zwei – denn die Alternative, eine leise Überschreitung bei der Rechnung, ist die, die die Beziehung ruiniert.

Das ehrliche Fazit

Schätzungen sind keine Vorhersagen. Sie sind geteilte Annahmen über eine unsichere Zukunft. Die Aufgabe einer guten Schätzung ist nicht, richtig zu sein; es ist, prüfbar, überarbeitbar und fair zu sein, wenn sie sich als falsch herausstellt.

Wenn du Anbieter vergleichst und einer nennt dir eine einzelne präzise Zahl ohne Bandbreite, ohne Abschnitt für unsichtbare Arbeit und ohne Änderungsprotokoll – dann siehst du nicht den selbstbewussteren Anbieter. Du siehst den weniger transparenten.

Schick uns gern ein Projektbriefing, wir lassen es kostenlos durch diese Vorlage laufen, auch wenn du am Ende jemand anderen beauftragst. Im schlimmsten Fall gehst du mit einer ehrlicheren Zahl in der Hand.

Original Source: So schätzen wir Softwareprojekte ehrlich – die Vorlage, die jeder neue Kunde bekommt