Individualsoftware in 12 Wochen: Was realistisch ist — und was nicht
Zwölf Wochen reichen, um ein echtes System in Produktion zu bringen: ein Kundenportal, eine Mobile App, einen KI-Agenten mitten in Ihren Abläufen. Sie reichen nicht für alles — und Anbieter, die zu allem in 12 Wochen Ja sagen, sind die, die den Termin reißen. Der Unterschied zwischen einem glaubwürdigen 12-Wochen-Plan und einem Verkaufsspruch liegt in drei Dingen: was vor dem Build gestrichen wird, wie oft Sie funktionierende Software sehen und was passiert, wenn der Termin rutscht.
Warum Tempo scheitert: am Scope, nicht am Tippen
Softwareprojekte fliegen selten auseinander, weil Engineers zu langsam programmieren. Oxford-Forscher, die 1.471 IT-Projekte untersuchten, fanden eine durchschnittliche Kostenüberschreitung von 27 %, wobei jedes sechste Projekt um 200 % überzog — und die PMI-Umfrage unter 5.402 Fachleuten zeigt, dass 52 % der Projekte unter Scope Creep leiden und rund 10 Cent von jedem Projekt-Euro in schlechter Performance versickern. Hinter beiden Zahlen steht dasselbe Muster: ein Scope, der nie wirklich fixiert war, plus Feedback, das Monate zu spät kommt, um noch zu wirken. Jedes ehrliche Tempo-Versprechen muss diese beiden Ursachen angreifen — alles andere ist Marketing.
Was die Delivery-Forschung tatsächlich stützt
Der stärkste Beleg für schnelle Lieferung betrifft die Batch-Größe. Das DORA-Forschungsprogramm zeigt: Arbeit in kleinen Batches sagt sowohl Software-Delivery-Performance als auch Unternehmensleistung voraus — Features in Tagen statt Wochen geschnitten, Änderungen schnell deploybar, Feedback-Schleifen kurz genug, um schlechte Ideen zu stoppen, bevor sie das Budget fressen. Eine wöchentliche Demo funktionierender Software auf echten Daten ist die praktische Anwendung dieses Befunds — sie ist Fortschrittsbericht, Scope-Kontrolle und Frühwarnsystem in einem. Zwölf Wochen mit wöchentlichen Demos sind zwölf Chancen zur Kurskorrektur; zwölf Wochen mit einer großen Enthüllung am Ende sind eine.
Die Anatomie eines ehrlichen 12-Wochen-Plans
Ein glaubwürdiger Plan wird bei den eigenen Wochen konkret. Unserer: Die Wochen eins und zwei sind ein bezahlter Scoping-Sprint — den Prozess kartieren, Zugriff auf Systeme und Daten sichern, Scope, Erfolgsmetriken und Testplan fixieren; am Ende stehen ein Architekturdokument, ein Festpreis und ein Go/No-Go. Woche drei liefert ein Walking Skeleton: den dünnsten funktionierenden Schnitt, end to end, auf Ihren echten Daten. Die Wochen vier bis acht sind die Build-Schleife mit einer Demo pro Woche. Die Wochen neun und zehn gehören Härtung, Dokumentation und Runbooks. In den Wochen elf und zwölf läuft das System erst im Shadow Mode, dann live, dann folgt die Übergabe. Verlangen Sie von jedem Anbieter, der Tempo verspricht, sein Gegenstück zu diesem Absatz.
Was 12 Wochen ausschließen
Ehrlichkeit über die Grenzen gehört zum Versprechen. In 12 Wochen passen nicht: eine Alles-Plattform für jede Abteilung, ein kompletter ERP-Ersatz mit einem Dutzend Legacy-Anbindungen, ergebnisoffene Forschung oder ein KI-Agent, dessen Daten erst Monate der Bereinigung brauchen — diese Bereinigung ist ihre eigene Phase eins. Die Disziplin, die 12 Wochen real macht: auf den ersten Workflow mit messbarem Wert schneiden, ihn in Produktion bringen und von einem laufenden System aus erweitern. Ein schmales System, das in Woche 12 live ist, schlägt ein breites, das ein Jahr lang bei 60 % steht — denn das eine erzeugt Umsatz, Feedback und Vertrauen, das andere Statusmeetings.
Was es möglich macht
Vier Zutaten, alle unspektakulär. Ein Scope, den beide Seiten vor dem Build unterschreiben, damit Woche fünf nicht mit der Neuverhandlung von Woche zwei verbracht wird. Ein Entscheider auf Ihrer Seite, der Fragen in Stunden beantwortet, nicht in Gremienzyklen. Ein Senior-Team, das end to end baut, ohne Übergaben zwischen Gewerken. Und Produktionsdisziplin ab der ersten Woche — kontinuierliches Deployment ab Tag drei, in kleinen Batches, damit „in Produktion gehen“ in Woche zwölf ein Nicht-Ereignis ist statt einer Klippe. Nichts davon ist heldenhaft; alles davon ist selten — deshalb klingt das Versprechen kühner, als es ist.
Die Frage, die ein Versprechen von einem Plan trennt
Fragen Sie den Anbieter: Was passiert, wenn Sie den Termin verpassen? Ein ehrlicher Betrieb hat eine vertragliche Antwort — unsere lautet: Wir bauen kostenlos weiter, bis das System auf den unterschriebenen Scope live ist. Lassen Sie sich dann den Wochenplan und den Demo-Rhythmus zeigen, bevor Sie irgendetwas unterschreiben. Ein Anbieter, der Ihnen den Liefergegenstand von Woche drei nicht schriftlich zeigen kann, bittet Sie, seinen Optimismus zu finanzieren. Ein Anbieter, der es kann — und den Termin in den Vertrag schreibt — hat die Denkarbeit, die zwölf Wochen realistisch macht, bereits geleistet.
Kann ein KI-Agent wirklich in 12 Wochen produktionsreif sein?
Ein sauber gescopter Agenten-Workflow — mit seinen Integrationen, Freigabe-Gates, Eval-Suite und Monitoring — ja. Ein Assistent für das ganze Unternehmen: nein. Der schmale Agent geht live und verdient sich seinen Ausbau; der breite bleibt eine Demo. Der Scope entscheidet das ganze Spiel.
Was, wenn mein Projekt wirklich länger als 12 Wochen braucht?
Dann sagt der Scoping-Sprint das in Woche zwei — und Sie entscheiden mit Architekturdokument und Phasenplan in der Hand, nachdem Sie zwei Wochen riskiert haben, nicht ein Quartal. Größere Builds werden als Phasen ausgeliefert, jede mit eigenem Live-Meilenstein, statt als ein langes Versprechen.
Was brauchen Sie von uns, damit 12 Wochen realistisch bleiben?
Drei Dinge: einen benannten Entscheider, der Scope-Fragen binnen eines Tages beantwortet, Zugriff auf die relevanten Systeme und Daten in Woche eins und Teilnahme an der wöchentlichen Demo. Projekte reißen Termine weit öfter wegen langsamer Antworten als wegen harter Engineering-Probleme.