Was eine Discovery technisch leistet — und warum „kostenlos" ein Etikettenschwindel ist
Wir werden im Pitch-Prozess regelmäßig gefragt, warum wir Discovery — die zwei- bis vierwöchige Phase, in der wir Architektur, Risiken und Aufwand für ein Mandat klären — in Rechnung stellen. Andere Anbieter, so der Einwand, machen das doch „kostenlos". Stimmt: viele Anbieter rechnen Discovery nicht separat ab. Sie rechnen sie über die Implementierungsphase rein, und zwar mit zwei Konsequenzen, die der Klient zunächst nicht sieht.
Erstens: Eine „kostenlose" Discovery ist immer eine Verkaufs-Discovery. Das Ziel ist nicht, das Problem zu verstehen, sondern den Auftrag zu schreiben. Das Ergebnis ist ein Angebot, das den Zuschlag bekommen soll — nicht eines, das stimmt. Die Standish Group dokumentiert seit Mitte der 90er Jahre im jährlichen CHAOS-Report konsequent, dass mehr als 50 % aller IT-Projekte ihre ursprünglichen Ziele verfehlen, und „incomplete requirements" führt die Ursachenliste an [1]. Das ist kein Zufall — es ist das direkte Ergebnis einer Discovery, die zur Sales-Phase degradiert wurde.
Zweitens: Wenn Discovery in der Delivery enthalten ist, gibt es keinen sauberen Ausstiegspunkt. Der Klient bekommt ein Angebot, sagt Ja oder Nein zum Gesamtpaket — und wenn die Discovery zeigt, dass das Projekt anders zugeschnitten werden sollte, gibt es keine vertragliche Schiene, das einzubauen. Bei einer bezahlten Discovery dagegen ist das Ende der Phase ein echter Entscheidungspunkt.
Die Cost-of-Change-Kurve: Boehm, 1981 — und immer noch wahr
Barry Boehm hat 1981 in „Software Engineering Economics" empirisch belegt, dass die Kosten zur Korrektur eines Fehlers exponentiell mit der Phase steigen, in der er entdeckt wird [2]. Ein in der Anforderungsphase eingebauter Fehler kostet im Betrieb das 50- bis 200-fache der Aufdeckungskosten in der Discovery. Spätere empirische Arbeiten aus dem NIST („The Economic Impacts of Inadequate Infrastructure for Software Testing", 2002) bestätigen die Größenordnung: Fehler, die erst nach dem Release entdeckt werden, verursachen Folgekosten in Höhe von 40 % des Projektbudgets [3].
Übersetzt in die Engagement-Realität heißt das: 30 Tage Senior-Discovery — typischerweise 30.000–60.000 € — sparen in einem 600.000-€-Mandat im Schnitt 240.000 €. Das ist nicht Theorie, sondern die Ökonomie, mit der wir täglich rechnen. Klienten, die uns nach einem gescheiterten Mitbewerber-Mandat aufsuchen, zahlen diese Differenz immer — entweder vorher in der Discovery oder hinterher in der Sanierung.
Was eine seriöse Discovery konkret liefert
Was bezahlt eine Discovery konkret? Drei Dinge. Erstens: Senior-Personal, das sich tief mit Ihrer Domäne, Ihrer bestehenden Infrastruktur und Ihren regulatorischen Constraints auseinandersetzt. Nicht ein Workshop, sondern Tage am Whiteboard mit Ihren Engineers und Tagen alleine im Code-Review. Zweitens: eine Risiko-Matrix, die nicht nur die offensichtlichen Risiken auflistet, sondern auch die zweite Reihe — die Risiken, die erst durch Architekturentscheidungen entstehen, die wir gemeinsam treffen.
Drittens: einen Implementierungsplan mit Phasen, Übergaben und einem expliziten Kill-Switch nach jeder Phase. Sie wissen vor Beginn jeder Phase, was Sie für welches Geld bekommen und wann Sie aussteigen können. Das ist die Definition von Risk-Transfer im Sinne der COSO-ERM-Definition [4]: der Anbieter trägt das Lieferrisiko, weil er es in zwei bis vier Wochen bewiesen hat — nicht in zwei bis vier Quartalen.
Wie eine solche Discovery konkret aussehen kann, zeigt unsere Arbeit für Sahel Beauty: vier bis fünf disparate SaaS-Lösungen wurden in zwei Wochen Discovery zu einem konsolidierten Plattform-Entwurf, bevor eine Zeile Code entstand. Die Discovery hat dort 22.000 € gekostet und ein Migrationsbudget von 380.000 € auf 250.000 € reduziert.
Wann wir „Nein" sagen — und warum das Ihr Vorteil ist
Etwa eines von vier Discovery-Mandaten endet bei uns nach der Discovery, weil die ehrlichste Empfehlung lautet, das Projekt anders zu schneiden oder nicht zu machen. Das geht nur mit bezahlter Discovery. Ein Anbieter, der die Discovery nur über den nachfolgenden Auftrag refinanziert, kann es sich nicht leisten, am Ende der Discovery zu empfehlen, das Projekt nicht zu machen.
Wir können. Und das ist der wertvollste Teil unserer Arbeit: die Empfehlungen, die einen Klienten davon abhalten, ein Projekt zu starten, das in der vorliegenden Form scheitern würde. Diese Empfehlungen kommen nicht aus Pessimismus, sondern aus Pattern-Recognition über zwölf Jahre und ein paar Dutzend Engagements.
Preis und Lieferung im Überblick
Der Preis einer Discovery liegt typischerweise zwischen 18.000 € und 60.000 €. Das ist ein Bruchteil dessen, was eine falsch zugeschnittene Implementierung kostet — und der einzige Weg, dass Sie nicht ein „günstiges" Angebot bekommen, das in der dritten Phase Change-Requests in Höhe des Ursprungsangebots produziert. Wir haben Mandate gesehen, in denen die nicht-bezahlte Discovery eines Mitbewerbers den Klienten am Ende das Vier- bis Fünffache des ursprünglichen Angebots gekostet hat.
Wenn Sie also vor der Wahl stehen zwischen einer kostenlosen und einer bezahlten Discovery: fragen Sie sich, wer das Risiko trägt. Bei der kostenlosen Discovery tragen Sie es — verpackt in ein Angebot, das verkaufen soll. Bei der bezahlten Discovery trägt es der Anbieter — er muss in zwei bis vier Wochen einen Plan liefern, der trägt, oder er bekommt den Folgeauftrag nicht.
- [1]Standish Group, CHAOS Report — laufende Jahresausgaben zur Erfolgsquote von IT-ProjektenThe Standish Group (2015) · report
- [2]Software Engineering Economics (Boehm, 1981) — Cost-of-Change-Kurve über ProjektphasenBarry W. Boehm (1981) · book
- [3]The Economic Impacts of Inadequate Infrastructure for Software Testing (NIST Planning Report 02-3)NIST / RTI International (2002) · report
- [4]COSO Enterprise Risk Management — Integrating with Strategy and PerformanceCommittee of Sponsoring Organizations of the Treadway Commission (2017) · standard
- [5]Brooks, F.P. — The Mythical Man-Month — fundamentale Engagement-ÖkonomieFrederick P. Brooks Jr. (1975) · book
Question on the post? Write to us.
Boutique vs. Großberatung: Wann was passt — und warum die Frage falsch gestellt ist
Die Wahl ist keine Glaubensfrage. Brooks' Gesetz (1975), Putnams Software-Equation und Larmans Untersuchung großer Programme zeigen, in welchen Profilen Boutique- oder Großberatungs-Modelle ökonomisch überlegen sind. Mit Entscheidungsraster.
Warum wir auf Senior-Teams setzen — und was das wirtschaftlich bedeutet
Empirisch belegte Produktivitätsunterschiede zwischen Senior- und Junior-Engineers reichen von 1:10 (Boehm, 1981) bis 1:28 (DeMarco/Lister Coding War Games). Was das für Pricing, Scope und Liefermodell bedeutet — und warum „günstig" am Ende teurer wird.