Wie man ein Projekt schätzt, wenn der Kunde selbst noch nicht genau weiß, was er will

Keine Scheingenauigkeit erzeugen, solange das Projekt unklar ist

Ein Kunde braucht ein Dashboard, möchte einen Prozess automatisieren oder eine moderne Website, weiß aber noch nicht genau, was enthalten sein soll. Der Druck, sofort einen Preis zu nennen, ist groß. Niemand möchte schwierig oder unerfahren wirken, also werden ein paar Fragen gestellt, eine plausible Projektversion imaginiert und eine präzise Zahl genannt. Die Zahl wirkt professionell, die Informationsbasis nicht. Eine saubere Summe kann enorme Unsicherheit verstecken, wenn Anforderungen hauptsächlich Annahmen sind.

Präzision und Genauigkeit sind verschieden. Ein Angebot über 7.480 $ kann weniger verantwortungsvoll sein als eine Bandbreite von 6.000–10.000 $, wenn zentrale Anforderungen fehlen. Eine exakte Zahl suggeriert, Unsicherheit sei gelöst, obwohl sie nur verborgen wurde. Später wirkt jedes echte Bedürfnis wie Scope Creep, selbst wenn niemand den ursprünglichen Scope korrekt definieren konnte. Beide Seiten können sich getäuscht fühlen, ohne dass jemand täuschen wollte.

Ihre Aufgabe ist in dieser Phase nicht Zukunftsvorhersage, sondern Unsicherheit so weit zu reduzieren, dass ein kaufmännisches Commitment sinnvoll wird. Manchmal genügen fünfzehn Minuten Klärung. Manchmal braucht es bezahltes Discovery, Audit, Stakeholder-Interviews oder Prototyp. Entscheidend ist, Unsicherheit in den Prozess zu integrieren statt sie als kostenlos zu behandeln. Eine verantwortungsvolle Schätzung beginnt mit dem, was noch unbekannt ist.

Bekanntes, Annahmen und Unbekanntes voneinander trennen

Erstellen Sie drei Listen. Bekannt sind Fakten, die beide Seiten jetzt bestätigen können: bestehendes System, verpflichtender Termin, Nutzerzahl, unterstützte Plattformen oder rechtliche Anforderungen. Annahmen sind Bedingungen, die vorübergehend als wahr gelten, um schätzen zu können: Kunde liefert finalen Text, eine Person genehmigt Design, die bestehende API liefert nötige Daten. Unbekannt sind Fragen, die Aufwand materiell verändern können, aber noch unbeantwortet sind.

Diese Trennung verhindert, dass eine Annahme still zum Versprechen wird. Wenn eine Migration unter der Annahme sauberer Daten geschätzt wird, schreiben Sie das zum Preis. Tauchen später tausende Duplikate auf, ist nachvollziehbar, warum sich die Arbeit ändert. Ohne schriftliche Annahme erinnern Sie sich an eine Bedingung und der Kunde an einen Preis. Ein Satz schafft gemeinsame Referenz.

Priorisieren Sie Unbekanntes nach Wirkung. Nicht jedes Detail muss untersucht werden. Beginnen Sie mit Fragen, die Architektur, Volumen, Spezialisten, Drittkosten, Akzeptanzkriterien oder Zeitplan ändern können. Ein Button-Label hat nicht dieselbe Wirkung wie die Frage, ob ein Legacy-System überhaupt eine API besitzt. High-Impact-Unbekanntes gehört vor die Festlegung des kommerziellen Modells.

• Bekannt: Fakten, die beide Seiten jetzt verifizieren können
• Angenommen: temporäre Bedingung, die eine Schätzung ermöglicht
• Unbekannt: Frage, die Kosten oder Zeitplan materiell verändern kann
• Hoher Impact: verändert Architektur, Volumen, Abhängigkeit oder Akzeptanzkriterien
• Niedriger Impact: Detail, das später ohne Änderung des Geschäftsmodells entschieden werden kann

Bezahltes Discovery nutzen, wenn das Klären echte Arbeit erfordert

Discovery ist kein kostenloses Verkaufsgespräch mit besserem Namen. Müssen Daten geprüft, ein bestehendes System analysiert, Stakeholder interviewt, eine API getestet, ein Workflow gemappt oder Anforderungen definiert werden, entsteht Wert. Das reduziert Kundenrisiko und liefert Informationen für eine verantwortungsvolle Delivery-Schätzung. Früher ausgeführte Arbeit wird nicht kostenlos, nur weil sie vor Implementation stattfindet.

Discovery kann als Festpreis angeboten werden, wenn die Outputs klar sind: Anforderungskarte, technische Bewertung, priorisierter Scope, Wireframes und Implementation Estimate. Ist die Untersuchung selbst unsicher, eignet sich Stundenabrechnung mit Cap. Definieren Sie, was der Kunde am Ende erhält, statt unbegrenzte Recherche zu verkaufen. Gutes Discovery endet mit besseren Entscheidungen, nicht nur mehr Dokumenten.

Besonders sinnvoll ist Discovery, wenn der pessimistische Delivery-Fall viel teurer als der optimistische ist. Kann eine Integration zwei Tage oder sechs Wochen dauern, macht der Durchschnitt das Risiko nicht fair. Investieren Sie eine kleinere Summe, um herauszufinden, in welcher Welt Sie sich befinden, und schätzen Sie anschließend anhand von Fakten. Der Kunde erhält Kontrolle und Sie riskieren Ihre Marge nicht auf Basis unbekannter Informationen.

Mit Bandbreiten statt einer magischen Zahl schätzen

Solange Unsicherheit bleibt, ist eine ehrliche Bandbreite besser als Scheingenauigkeit. Eine sinnvolle Bandbreite ist nicht fünf bis fünfzig Tausend. Sie ist an Szenarien gekoppelt: Untergrenze an konkrete günstige Annahmen, Obergrenze an bekannte Risiken oder komplexere Optionen. Erklären Sie, was das Projekt bewegt. Eine Bandbreite ohne Gründe ist vage; eine an Entscheidungen gebundene Bandbreite ist nützlich.

Für unsichere Tasks können drei Punkte genutzt werden: optimistisch, wahrscheinlich, pessimistisch. Die Formel (optimistisch + 4 × wahrscheinlich + pessimistisch) ÷ 6 liefert einen Planning-Wert und bewahrt die Range. Wichtiger als die Formel ist, den pessimistischen Fall vor dem Commitment aufzuschreiben. Ist der vernünftige Worst Case kaufmännisch untragbar, muss das Delivery-Modell vor Vertragsabschluss geändert werden.

Braucht der Kunde einen Budgetdeckel, nutzen Sie stufenweise Freigaben. Discovery kann auf einen Betrag begrenzt werden; Implementation startet erst nach neuer Genehmigung. Eine weitere Option ist Time and Materials mit Wochen-Cap oder Not-to-exceed. Das kommerzielle Modell soll Unsicherheit enthalten, nicht leugnen. Budgetkontrolle kann aus Grenzen und Checkpoints kommen statt aus erfundenem finalem Scope.

• Untergrenze an explizite günstige Annahmen binden
• Obergrenze an benannte Risiken oder komplexere Optionen binden
• Drei-Punkt-Schätzungen für unsichere Tasks verwenden
• Caps und Checkpoints zur Budgetkontrolle einsetzen
• Eine sehr breite Range nicht nur für ein schöneres Angebot zum festen Mittelwert machen

Annahmen und Ausschlüsse direkt in die Schätzung schreiben

Eine Schätzung mit unklarem Scope ist nur so gut wie ihre Annahmen. Platzieren Sie wichtige Annahmen beim Preis: Wer liefert Content, wie viele Stakeholder genehmigen, welches Datenformat wird erwartet, welche Systeme sind zugänglich, wie viele Revisionen sind enthalten, welche Drittkosten ausgeschlossen. Das sind Rechengrundlagen, keine juristische Dekoration.

Ausschlüsse sind genauso wichtig. Sie sind weder feindlich noch eine Weigerung zu helfen; sie definieren die Grenze der aktuellen Entscheidung. Sind Copywriting, Übersetzung, Migration Cleanup, Legal Review, Advanced Analytics oder Custom Integrations nicht enthalten, sagen Sie es. Ein klarer Ausschluss kann später zur Option statt zum Konflikt werden.

Nutzen Sie normale Sprache. Ziel ist kein Dokument, das einen Anwalt besiegt, sondern dass zwei Menschen denselben Satz lesen und ungefähr dasselbe Projekt sehen. Würde eine Annahme den Kunden überraschen, muss sie vor Annahme des Angebots besprochen werden. Die beste Schätzung hat nicht mehr Disclaimer, sondern weniger versteckte Interpretationen.

Phasen und echte Optionen statt eines Alles-oder-nichts-Angebots anbieten

Unklare Projekte werden leichter kaufbar, wenn sie in Entscheidungen geteilt werden. Statt eines großen unsicheren Budgets bieten Sie eine erste Phase, die Klarheit schafft, und eine zweite, die die definierte Lösung liefert. Auch Minimum-Viable- und erweiterte Variante sind sinnvoll, solange der Kunde Komplexität priorisiert. Kleinere Entscheidungen lassen sich leichter schätzen und stoppen.

Optionen sollten reale Scope-Unterschiede darstellen, nicht künstliches Price Anchoring. Manueller Import jetzt versus automatische Integration nach API-Prüfung oder fünf Kernseiten versus komplette Content-Migration sind echte Wahlmöglichkeiten. Der Kunde wählt einen Business-Trade-off und Sie tun nicht so, als würden beide Versionen gleich viel Arbeit erfordern. Manchmal weiß ein Kunde nicht, was er will, weil Features noch nie um dasselbe Budget konkurrieren mussten.

Staging schafft natürliche Stopppunkte. Zeigt Discovery, dass ein Feature wirtschaftlich nicht sinnvoll ist, kann der Kunde mit nützlichen Erkenntnissen aufhören. Discovery wird damit zu einem eigenständigen Entscheidungsasset statt zu einer Gebühr auf dem Weg zur echten Arbeit. Eine gute erste Phase bleibt auch wertvoll, wenn die zweite nie beginnt.

• Discovery zuerst, Implementation-Angebot danach
• Minimum Viable Scope versus erweiterter Scope
• Bekannter Core als Festpreis, unsichere Integration stundenbasiert
• Milestone-Freigabe vor dem nächsten Budget
• Optionale Module nach Validierung des Kernergebnisses

Vorab definieren, wie neue Informationen Preis und Zeitplan verändern

Ein unklarer Projekt sollte klarer werden. Der Prozess muss sagen, was mit neuen Informationen passiert. Passt eine neue Anforderung in Deliverable und Annahmen, kann sie eine Präzisierung sein. Fügt sie Output, Abhängigkeit, Integration, Zielgruppe oder Akzeptanzkriterium hinzu, braucht es Change Request oder neue Schätzung. Die Regel sollte auf Folgen beruhen, nicht darauf, wie klein der Wunsch klingt.

Warten Sie mit der Klassifizierung nicht bis zur Rechnung. Verändert eine Entdeckung den Aufwand, pausieren Sie die betroffene Arbeit und dokumentieren Sie den Impact: Was hat sich geändert, Zusatz- oder Minderkosten, Zeitplaneffekt, neue Annahmen. Ändert sich das kommerzielle Commitment, holen Sie schriftliche Freigabe ein. Zwei Minuten Klärung vor Implementation sind billiger als Streit nach Delivery.

Das schützt auch die Beziehung. Kunden hassen überraschende Rechnungen meist mehr als die Nachricht, dass ein neuer Wunsch zusätzlich kostet. Ein ruhiger Change-Prozess gibt ihnen Kontrolle: genehmigen, anderes entfernen, verschieben oder Original-Scope behalten. Das ist eine Geschäftsentscheidung, kein Konflikt. Ein gutes Projekt darf lernen, ohne dass jede neue Information jemandem als Fehler zugerechnet wird.

Beispiel: Ein Dashboard schätzen, bevor Anforderungen existieren

Ein Kunde möchte ein internes Operations-Dashboard. Er weiß, dass Sales, Inventar und Mitarbeiterdaten zusammengehören, hat aber Metriken, Datenqualität und Berechtigungen noch nicht definiert. Ein fixer Implementation-Preis würde Antworten erfinden. Stattdessen bieten Sie Discovery an: Workshop, Prüfung der drei Datenquellen, Berechtigungskarte, Wireframes und priorisierten Scope. Diese Outputs lassen sich sinnvoll bepreisen.

Danach wissen Sie: Sales und Inventar haben stabile APIs, Mitarbeiterdaten liegen in inkonsistenten Tabellen. Implementation kann nun geteilt werden: Core-Dashboard als Festpreis auf zwei bekannten APIs plus begrenzte Datenbereinigungs- und Importphase für Staff. Der Kunde erhält eine engere Range und entscheidet, ob Automatisierung den Mehrpreis wert ist. Ein großer Risk Guess wird durch zwei kontrollierbare Commitments ersetzt.

Das macht Sie nicht weniger entscheidungsfreudig. Es bringt Entscheidungen nur in die richtige Reihenfolge. Zuerst wird die Arbeit bezahlt, die Wissen erzeugt, dann die Arbeit, die baut. Diese Reihenfolge trennt häufig ein gesundes Projekt von einem Fixed-Price-Versprechen, das auf zwei unterschiedlichen Vorstellungen basiert. Bei unklarem Scope kann der erste professionelle Preis der Preis für Klarheit selbst sein.

• Geschäftsergebnis vor Features klären
• High-Impact-Unbekanntes vor Festpreis identifizieren
• Discovery verkaufen, wenn Klärung echte Arbeit benötigt
• Bandbreiten und Caps nutzen, solange Unsicherheit bleibt
• Annahmen in schriftliche Bedingungen verwandeln
• Neu schätzen, wenn neue Informationen das Projekt materiell verändern