Der 90-Tage AI Sprint

Die meisten KI-Projekte im Mittelstand starten mit einem guten Workshop und enden irgendwann in einer Roadmap-Folie, ohne dass jemand genau sagen kann, wann das eigentlich passiert ist. Der Grund liegt fast nie am Team oder an der Technologie. Er liegt am fehlenden Enddatum.

Wir haben deshalb angefangen, KI-Projekte anders aufzusetzen. Nicht als offene Beratungsleistung, die läuft, bis das Budget aufgebraucht ist, sondern als Sprint mit fixem Ende. 90 Tage, ein Ergebnis, keine Verlängerung durch die Hintertür.

Das Problem mit offenen KI-Projekten

Die meisten KI-Initiativen, die wir bei Mittelständlern in Österreich und Deutschland sehen, starten mit guten Absichten und einem großzügigen Zeitrahmen. Genau der Zeitrahmen wird zum Problem. Ohne festen Endpunkt wächst der Anspruch mit der Projektdauer mit. Aus einem E-Mail-Assistenten wird eine Plattform-Vision. Aus der Plattform-Vision wird ein zweites Architektur-Meeting. Nach vier Monaten gibt es eine sehr gute Folie und kein produktives System.

Das liegt selten an fehlendem Willen. Es liegt daran, dass ein offenes Projekt keinen Druck erzeugt, konkret zu werden. Also haben wir den Druck eingebaut: Nach 90 Tagen läuft etwas, oder das Projekt ist beendet.

Vier Phasen, ein Ergebnis

Strategize

In den ersten zwei Wochen geht es nicht darum, Ideen zu sammeln, sondern ums Gegenteil: eine Liste auf einen einzigen Use Case reduzieren und ein Zielbild definieren, an dem sich später objektiv prüfen lässt, ob der Sprint funktioniert hat. Wer hier zu vage bleibt, verlängert den Sprint um Wochen. Deshalb bestehen wir in dieser Phase auf konkreten Zahlen, nicht auf Formulierungen wie "Effizienz steigern".

Proof of Value

Das ist der Teil, den viele Anbieter überspringen oder durch eine Demo ersetzen. Für uns heißt Proof of Value: echte Nutzer, echte Daten, ein echter Arbeitsablauf, kein Sandkasten. Eine Demo kann man wollen. Einen Prototyp, den ein paar Mitarbeitende zwei Wochen lang tatsächlich benutzt haben, kann man messen. Nur Letzteres zählt bei uns als Proof.

Build

Erst wenn der Proof steht, wird gebaut, und zwar auf Produktionsniveau: Integration in bestehende Systeme, Anbindung an die Datenquellen, die im Alltag tatsächlich verwendet werden, und eine Governance-Schicht, die dafür sorgt, dass das System auch in sechs Monaten noch nachvollziehbar ist. Diesen Unterbau übernimmt bei uns meist SAALT, damit wir nicht bei jedem Projekt das Sicherheits- und Rechtekonzept neu erfinden müssen.

Activate

Der am häufigsten unterschätzte Schritt. Ein System, das niemand im Team benutzt, war kein Sprint, sondern ein teures Experiment. Activate heißt: Schulung, Übergabe, und ein Team, das versteht, warum das System eine Entscheidung trifft, wie es sie trifft, nicht nur, welchen Button man klicken muss.

Warum wir agil arbeiten, nicht im Wasserfall

Vier Phasen klingen nach einem klassischen Wasserfall-Projekt: erst planen, dann bauen, dann übergeben. Der Unterschied liegt darin, wie innerhalb jeder Phase gearbeitet wird. Wir arbeiten in kurzen Zyklen, meist wöchentlich, und zeigen dem Kunden nach jedem Zyklus etwas Funktionierendes, keine Folie darüber, was als Nächstes geplant ist.

Das hat einen konkreten Vorteil: Fehleinschätzungen fallen früh auf. Wenn eine Datenquelle nicht das hergibt, was in der Strategize-Phase angenommen wurde, sehen wir das in der ersten Build-Woche, nicht am Ende des Sprints. Wenn Mitarbeitende den Prototyp anders nutzen als erwartet, etwa weil sie eine ganz andere Frage an das System stellen als vorgesehen, passen wir den nächsten Zyklus daran an, statt stur den ursprünglichen Plan durchzuziehen.

Der zweite Vorteil ist psychologischer Natur, aber nicht weniger wichtig. Eine Geschäftsführung, die alle zwei Wochen ein funktionierendes Stück System sieht, vertraut dem Projekt mehr als eine, die drei Monate lang Statusberichte liest. Das ist auch der Grund, warum die Proof-of-Value-Phase bei uns keine Ausnahme im Sprint ist, sondern das Prinzip für den ganzen Sprint: Jede Phase liefert etwas, das die nächste Woche jemand tatsächlich anfassen kann, nicht nur einen Plan für die Phase danach.

Warum ausgerechnet 90 Tage

Die Zahl ist nicht willkürlich, aber auch nicht magisch. 90 Tage sind kurz genug, dass eine Geschäftsführung sie genehmigt, ohne dafür gleich ein Jahresbudget aufzumachen, und lang genug, dass ein System tatsächlich im Alltag ankommt statt nur in einer Präsentation zu existieren. Kürzer als das schaffen wir selten eine ehrliche Proof-of-Value-Phase. Länger als das beginnt, wie oben beschrieben, der Anspruch zu wachsen.

Der eigentliche Unterschied zur klassischen Beratung liegt aber nicht in der Zahl, sondern im Vertrag dahinter. Klassische Beratung wird nach Aufwand abgerechnet, das belohnt Dauer. Ein Sprint mit festem Preis und festem Endpunkt belohnt das Gegenteil: schnell zu einem funktionierenden System zu kommen, weil zusätzliche Zeit uns Geld kostet, nicht dem Kunden.

Was passiert, wenn es nicht klappt

Ehrlich gesagt: Nicht jeder Use Case übersteht die Proof-of-Value-Phase, und genau das ist der Sinn der Übung. Wenn sich nach vier Wochen zeigt, dass die Datenqualität nicht reicht oder der Use Case zu klein ist, um den Aufwand zu rechtfertigen, ist das kein Scheitern des Sprints. Es ist genau die Information, für die man ihn gebucht hat, nur eben nach vier Wochen statt nach einem Jahr stiller Verlängerungen.

Und wer uns fragt, ob 90 Tage für jedes KI-Projekt reichen: nein. Für manche Themen ist das zu kurz, für andere zu lang. Aber für den Großteil der Fälle, die wir in Erstgesprächen sehen, nämlich einen klar abgrenzbaren Anwendungsfall mit einem konkreten Team dahinter, ist es die Struktur, die am zuverlässigsten zu einem produktiven System führt statt zu einer weiteren Roadmap-Folie.

Wer wissen will, ob der eigene Use Case in diese 90 Tage passt: Sprechen wir drüber.