Warum KI-Projekte scheitern und was Schweizer Teams daraus lernen können

Mehr als die Hälfte aller KI-Projekte in europäischen KMU erreichen weder die gesetzten Ziele noch den geplanten Zeitrahmen. Das ist keine Schätzung, sondern der wiederkehrende Befund aus Branchenerhebungen von McKinsey, Gartner und dem Digitalverband Bitkom. In der Schweiz kenne ich dieses Muster aus eigener Beobachtung gut.

Was ich im Laufe von Jahren in der Beratung festgestellt habe: Projekte scheitern fast nie an der Technologie selbst. Sie scheitern an Menschen, Prozessen und Erwartungsmanagement. Und das ist eigentlich eine gute Nachricht, denn diese Faktoren sind beeinflussbar.

Der häufigste Fehler: Erwartungen ohne Fundament

Das typische Scheiternsmuster beginnt im Kick-off-Meeting. Die Projektleitung, oft unter Druck der Geschäftsführung, die auf einer Konferenz eine beeindruckende Demo gesehen hat, formuliert Projektziele wie "die KI soll unsere Buchhaltung automatisieren" oder "der Kundenservice soll vollständig KI-gestützt werden". Was fehlt: eine klare Definition, was "automatisieren" bedeutet, welche Ausnahmefälle gelten, welche Daten vorhanden sind, und was der akzeptable Fehlerbereich ist.

Ich nenne dieses Muster "Scope-Zauberei": Der Umfang wird gross angekündigt, bleibt aber undefiniert. Im Projektverlauf füllt jeder Beteiligte die Lücken mit seinen eigenen Vorstellungen. Das Ergebnis ist unvermeidlich: Budgetüberschreitungen, weil nicht geplante Anforderungen auftauchen. Zeitverzögerungen, weil Nachforderungen eingearbeitet werden müssen. Unzufriedenheit aller Stakeholder, weil jede Partei ein anderes Projekt erwartet hat.

Der Fall Hole-in-One AG

Ein konkretes Beispiel aus meiner Beratungspraxis, das ich mit Genehmigung des Unternehmens in anonymisierter Form beschreiben darf: Ein mittelgrosses Vertriebsunternehmen, das ich hier als Hole-in-One AG bezeichne, startete 2023 ein KI-Projekt zur Automatisierung der Angebotserstellung. Das Budget war mit 180 000 Franken festgelegt. Die Laufzeit mit acht Monaten.

Neun Monate später war das Budget zu zwei Dritteln aufgebraucht, das System befand sich noch immer in der Pilotphase, und drei von fünf Vertriebsmitarbeitenden nutzten es nicht. Warum? Bei der Nachanalyse, die ich durchführte, stellten sich die eigentlichen Ursachen heraus:

Erstens waren die Anforderungen nie schriftlich fixiert worden. Was als "Automatisierung der Angebotserstellung" begann, wurde im Projektverlauf um CRM-Integration, Mehrsprachigkeit (Deutsch und Französisch) und automatische Rabattregeln erweitert, ohne dass das Budget oder die Laufzeit angepasst wurden.

Zweitens fehlte ein Abnahmekriterium. Niemand hatte definiert, wann das System "gut genug" war. Die IT-Abteilung hatte ein anderes Qualitätsverständnis als der Vertrieb, und die Geschäftsführung erwartete ein System, das die Demo-Ergebnisse aus der Präsentation des Anbieters reproduzierte, die mit optimierten Testdaten erstellt worden waren.

Drittens fehlte eine Entscheidungsinstanz für Konflikte. Wenn IT und Vertrieb unterschiedlicher Meinung waren, wurde eskaliert. Die Geschäftsführung entschied entweder gar nicht oder in beide Richtungen gleichzeitig.

Das Projekt wurde schliesslich mit einem neuen, reduzierten Scope und einem klaren Anforderungsdokument neu aufgesetzt. Es dauerte weitere vier Monate, funktioniert seither zuverlässig und ist heute das meistgenutzte interne Tool des Unternehmens.

Frühwarnsignale erkennen

Scheiternde KI-Projekte zeigen fast immer frühe Warnsignale. Das Problem ist nicht, dass sie unsichtbar wären, sondern dass sie zu oft ignoriert oder schöngeredet werden.

Erstes Warnsignal: Das Team spricht mehr über technische Features als über Geschäftsprobleme. Wenn Statusmeetings primär um Modellgenauigkeit, Trainingsiterationen oder API-Limits kreisen, statt um "Welches Geschäftsproblem haben wir diese Woche besser gelöst?", ist das ein Zeichen dafür, dass das Projekt den Boden unter den Füssen verliert.

Zweites Warnsignal: Stakeholder beteiligen sich nicht mehr aktiv. Wenn die Schlüsselpersonen aus Fachabteilungen aufhören, an Workshops oder Reviews teilzunehmen, liegt das meist daran, dass sie kein Vertrauen mehr in das Projekt haben. In der Schweizer Unternehmenskultur wird das oft nicht laut kommuniziert, sondern durch Rückzug signalisiert.

Drittes Warnsignal: Der Scope wächst still. Neue Anforderungen werden in Meetings nebenbei eingebracht und meist stillschweigend akzeptiert, weil niemand als Blockierer gelten will. Ohne formalen Change-Management-Prozess akkumulieren sich diese kleinen Erweiterungen zu einem fundamental anderen Projekt als ursprünglich geplant.

Viertes Warnsignal: Budgetberichte werden vage. Wenn die Antwort auf "Wie viel Budget haben wir noch?" lautet "Wir schauen das noch an", ist die Kontrolle verloren.

Die Pre-Mortem-Technik als Schutzinstrument

Eine der wirkungsvollsten Techniken, die ich in der Projektbegleitung einsetze, ist das Pre-Mortem. Die Idee ist einfach und provokant: Am Anfang eines Projekts, idealerweise nach der Planungsphase und vor der eigentlichen Umsetzung, versammeln sich alle Beteiligten mit der gemeinsamen Annahme: Stellen Sie sich vor, es ist heute 12 Monate später. Das Projekt ist gescheitert. Was ist schiefgelaufen?

Die Methode wurde vom Psychologen Gary Klein entwickelt und adressiert einen bekannten Denkfehler: Menschen neigen dazu, in der Planungsphase Risiken zu unterschätzen und Hindernisse kleinzureden. Wenn die Gruppe gefragt wird "Was könnte schiefgehen?", kommen oberflächliche Antworten. Wenn die Gruppe aufgefordert wird, in die Zukunft zu blicken und ein bereits eingetretenes Scheitern zu erklären, aktiviert das andere Denkmuster.

In einem Workshop, den ich 2024 für ein Zürcher Finanzunternehmen moderierte, identifizierte das Pre-Mortem in zwei Stunden acht kritische Risiken, die der formale Risikoplan in drei Wochen nicht gefunden hatte. Darunter: die fehlende DSGVO-Compliance-Prüfung für den eingesetzten Cloud-Anbieter, ein ungelöstes Problem mit der Datenqualität in einer Quelldatenbank, und ein Mitarbeitender aus der Fachabteilung, der das Projekt aktiv sabotieren würde, weil er seinen Arbeitsplatz gefährdet sah.

Keines dieser Risiken wäre im normalen Planungsprozess aufgetaucht. Alle drei wurden durch das Pre-Mortem proaktiv adressiert, bevor sie zu Problemen wurden.

Formaler Projektabschluss, auch bei Misserfolg

Ein Aspekt, der in der Schweizer KMU-Praxis systematisch vernachlässigt wird, ist der formale Projektabschluss. Das gilt besonders bei gescheiterten Projekten. Die menschliche Reaktion auf ein gescheitertes Projekt ist verständlich: Das Thema wird begraben, die Beteiligten wollen nicht daran erinnert werden, und die Organisation möchte weitermachen.

Das ist ein teurer Fehler. Jedes gescheiterte Projekt enthält wertvollere Erkenntnisse als ein erfolgreiches, einfach weil es die Grenzen des eigenen Vorgehens explizit sichtbar gemacht hat. Ein formaler Abschluss beinhaltet mindestens drei Elemente.

Erstens eine strukturierte Lessons-Learned-Session, in der alle Beteiligten ohne Schuldzuweisungen reflektieren, was funktioniert hat, was nicht funktioniert hat, und was beim nächsten Mal anders gemacht werden sollte. Diese Ergebnisse werden schriftlich fixiert und zugänglich gemacht.

Zweitens eine Stakeholder-Kommunikation, die ehrlich über das Ergebnis informiert. In der Schweizer Unternehmenskultur ist das oft eine Überwindung, aber eine Führungskraft, die offen kommuniziert "Wir haben gelernt, dass wir X falsch eingeschätzt haben", gewinnt mehr Vertrauen als eine, die das Scheitern totschweigt.

Drittens eine explizite Entscheidung: Abbruch, Neustart mit geändertem Scope, oder Pause. Diese Entscheidung gehört dokumentiert und kommuniziert, nicht still getroffen.

Unternehmen, die eine Kultur des strukturierten Lernens aus Misserfolgen aufbauen, sind nach meiner Beobachtung nicht diejenigen, die weniger scheitern. Sie sind diejenigen, die schneller lernen. In einer technologischen Umbruchphase wie der aktuellen ist das ein echter Wettbewerbsvorteil.