Der Pre-Mortem: Wie Schweizer KMU KI-Projekte richtig starten

Zwischen 60 und 80 Prozent aller KI-Einführungsprojekte in kleinen und mittleren Unternehmen erreichen ihre ursprünglichen Ziele nicht. Diese Zahl ist nicht neu, und die Hauptursachen sind es auch nicht: unklare Zielsetzungen, unterschätzte Datenqualitätsprobleme, fehlende interne Akzeptanz und ungenügende Ressourcenplanung. Was mich in meiner Beratungspraxis immer wieder überrascht, ist nicht das Scheitern selbst, sondern wie vorhersehbar es oft war. Die meisten Probleme waren bereits beim Projektstart sichtbar, wenn man mit der richtigen Methode hingeschaut hätte.

Die Pre-Mortem-Technik ist genau dafür entwickelt worden. Gary Klein, Kognitionspsychologe und Entscheidungsforscher, beschrieb sie 1989 als Gegenstück zur klassischen Post-Mortem-Analyse. Der Unterschied: Man wartet nicht, bis das Projekt gescheitert ist, um die Ursachen zu analysieren. Man versetzt sich vor Projektstart in die Zukunft und nimmt an, das Projekt sei bereits gescheitert, dann arbeitet man rückwärts zu den Ursachen.

Warum klassische Risikoanalysen versagen

Konventionelle Risikoanalysen leiden unter einem gut dokumentierten psychologischen Phänomen: Wenn ein Team bereits Energie in ein Projekt investiert hat, setzt Planungsoptimismus ein. Kritische Stimmen werden abgemildert, Risiken werden kleiner bewertet als sie es verdienen, und unangenehme Szenarien werden aus der Liste gestrichen, weil sie die Projektstimmung belasten.

In der Schweizer Unternehmenskultur kommt ein weiterer Faktor hinzu: Der Konsens als Entscheidungsgrundlage ist in vielen mittelständischen Unternehmen tief verankert. Das ist eine Stärke bei der Implementierung, weil Entscheide breite Unterstützung geniessen. Es ist eine Schwäche bei der Kritik, weil offen geäusserte Zweifel als mangelnde Loyalität interpretiert werden können.

Die Pre-Mortem-Technik umgeht dieses Problem elegant: Sie macht kritisches Denken zur expliziten Aufgabe. Wer Risiken benennt, folgt nicht seiner Skepsis, sondern dem definierten Prozess.

Die 7-Phasen-Kickoff-Struktur

Ein vollständiger Projektkickoff für ein KI-Einführungsprojekt in einem Schweizer KMU sollte sieben Phasen umfassen. Ich beschreibe sie in der Reihenfolge, in der sie in einem strukturierten Meeting durchgeführt werden, typischerweise über einen halben bis ganzen Tag.

Phase 1: Rollenklärung. Bevor über das Projekt gesprochen wird, werden die Rollen im Raum explizit benannt. Wer ist Projektauftraggeber mit Entscheidungskompetenz? Wer ist Projektleiter mit operativer Verantwortung? Wer sind Fachexperten ohne Entscheidungsrecht, aber mit unverzichtbarem Wissen? Wer hat ein Veto-Recht bei regulatorischen Fragen (typisch: Compliance, Datenschutzbeauftragter)?

Diese Klärung wirkt banal, ist aber entscheidend. In der Praxis entstehen die meisten Projektkonflikte nicht aus inhaltlichen Differenzen, sondern aus Rollenunsicherheiten: Wer hat das letzte Wort, wenn es Uneinigkeit gibt?

Phase 2: SMART-Zieldefinition. Das Ziel des KI-Projekts wird schriftlich fixiert. SMART steht für spezifisch, messbar, erreichbar (achievable), relevant und zeitgebunden. Ein unbrauchbares Ziel klingt so: "Wir wollen KI in unsere Buchhaltung integrieren." Ein brauchbares Ziel: "Bis zum 30. September wird die automatische Rechnungsprüfung für Lieferantenrechnungen unter CHF 5.000 ohne manuelle Kontrolle durchgeführt, mit einer Fehlerquote unter 0.5 Prozent, gemessen an einer Stichprobe von 200 Rechnungen."

Der Unterschied ist nicht Perfektionismus, er ist operationaler Klarheit. Nur wenn das Ziel messbar ist, kann am Projektende beurteilt werden, ob es erreicht wurde.

Phase 3: Scope-Definition, inklusive Out-of-Scope. Was zum Projekt gehört, wird definiert. Mindestens genauso wichtig: was explizit nicht zum Projekt gehört. Die Out-of-Scope-Liste verhindert Scope Creep, das schleichende Wachstum des Projektumfangs, das die häufigste Ursache für Budget- und Zeitüberschreitungen ist.

Bei einem KI-Buchhaltungsprojekt könnte die Out-of-Scope-Liste enthalten: Integration mit dem bestehenden CRM-System (separates Projekt), Analyse von Belegen aus dem Vorjahr (Phase 2), Optimierung der MWST-Voranmeldung (wird manuell fortgeführt). Diese Abgrenzungen müssen schriftlich festgehalten werden, weil mündliche Vereinbarungen in Projekten erstaunlich schnell vergessen gehen.

Phase 4: Meilensteinplanung. Das Projekt wird in überprüfbare Teilziele zerlegt. Jeder Meilenstein hat ein Datum und eine Definition, was "erreicht" bedeutet. Bei einem dreieinhalbmonatigen Einführungsprojekt könnte das so aussehen: Woche 2, Datenbewertung abgeschlossen und Datenqualitätsbericht vorgelegt; Woche 6, Pilotbetrieb mit 10 Prozent der Rechnungen gestartet; Woche 10, Pilotauswertung, Go/No-Go-Entscheid für Vollbetrieb; Woche 14, Vollbetrieb gestartet und Zielmessung initiiert.

Phase 5: Stakeholder-Analyse. Wer wird durch das Projekt beeinflusst, der nicht im Raum sitzt? Das Treuhandbüro hat typischerweise Mitarbeiter, die bestimmte Aufgaben bisher manuell erledigten. Diese Personen sind Stakeholder mit einem legitimen Interesse am Projektergebnis. Wie wird mit ihrer Unsicherheit über Jobveränderungen umgegangen? Werden sie in die Pilotphase einbezogen?

Externe Stakeholder können Mandanten sein (werden sie über den KI-Einsatz informiert?), der IT-Dienstleister (wer übernimmt Support?), und im regulierten Bereich auch die Aufsichtsbehörde.

Phase 6: Der Pre-Mortem-Workshop. Jetzt kommt die Kerntechnik. Alle Anwesenden erhalten eine Minute Stille und die Aufgabe: "Stellen Sie sich vor, es ist der 31. Dezember des Projektjahres. Das Projekt ist gescheitert. Was ist schiefgelaufen?"

Jede Person schreibt ihre Antworten auf Post-its oder in ein geteiltes Dokument, anonym, ohne Diskussion. Dann werden die Antworten vorgelesen und gruppiert. Die häufigsten Kategorien in meinen Workshops: technische Probleme (Datenqualität, Systemintegration), menschliche Faktoren (Widerstand, fehlendes Know-how, Schlüsselperson ausgefallen), Ressourcenprobleme (Zeit, Budget, externe Abhängigkeiten) und regulatorische Überraschungen (nDSG-Anforderungen wurden unterschätzt, FINMA-Abstimmung fehlte).

Diese Gruppierung wird zur Risikoliste. Für die Top-5-Risiken werden Gegenmassnahmen definiert und Verantwortliche benannt.

Phase 7: Teamregeln und Eskalationspfade. Wie arbeitet das Team zusammen? Wie oft wird ein Statusmeeting abgehalten? Wer wird informiert, wenn ein Meilenstein gefährdet ist? Bis zu welchem Betrag kann der Projektleiter selbst Ausgaben genehmigen?

Diese Regeln verhindern, dass im Projektalltag Zeit mit Abstimmungsfragen verloren geht, die vorab hätten geregelt werden können.

Der Devil's Advocate als Strukturrolle

In der Schweizer Geschäftskultur ist offene Kritik in Gruppen mit impliziter Hierarchie oft gedämpft. Eine elegante Lösung: die formelle Rolle des "Advocatus Diaboli" oder Devil's Advocate. Eine Person wird explizit beauftragt, für einen definierten Zeitraum gegen den Projektentwurf zu argumentieren. Diese Rolle ist temporär, nicht persönlich, und schützt die Person davor, als Querulant wahrgenommen zu werden.

In einem KI-Projekt-Kickoff lasse ich typischerweise den Devil's Advocate nach Phase 2 auftreten: Nachdem das SMART-Ziel definiert wurde, argumentiert die Rolle fünf Minuten lang, warum dieses Ziel nicht erreichbar oder nicht sinnvoll ist. Oft führt das zur Präzisierung des Ziels oder zur Aufnahme eines wichtigen Risikos in die Pre-Mortem-Liste.

Out-of-Scope ist kein Verzicht

Ein häufiges Missverständnis: Etwas als "out of scope" zu deklarieren bedeutet, es aufzugeben. Das Gegenteil ist richtig. Out-of-Scope-Definitionen schützen das Kernprojekt. Ein KI-Einführungsprojekt, das gleichzeitig die Datenbankstruktur modernisieren, eine neue Mitarbeiter-App einführen und die Buchführungssoftware wechseln soll, wird an seiner eigenen Ambition scheitern.

In meiner Praxis verwende ich die "Parking Lot"-Methode: Alle Ideen und Anforderungen, die nicht in den aktuellen Scope fallen, werden auf einer "Parking Lot"-Liste erfasst. Sie sind nicht vergessen, sondern für ein späteres Projekt reserviert. Das reduziert den psychologischen Druck, alles sofort lösen zu müssen, und erhöht die Fokussierung auf das aktuelle Projektziel.

Von der Theorie zur Praxis in Schweizer KMU

Die grösste Hürde bei der Einführung dieser Methodik ist nicht die Komplexität, sondern die Geduld. Ein sorgfältig vorbereiteter Kickoff dauert einen halben Tag. In vielen KMU herrscht die Überzeugung, dass man diese Zeit besser ins Projekt selbst investieren sollte.

Meine Antwort darauf ist empirisch: Von den KI-Projekten, die ich begleitet habe und die einen vollständigen Kickoff mit Pre-Mortem hatten, haben über 80 Prozent ihre Kernziele innerhalb des definierten Zeitrahmens erreicht. Von jenen, die ohne diese Struktur gestartet sind, waren es weniger als ein Drittel.

Investierter Aufwand für den Kickoff: vier bis acht Stunden. Gesparte Problemlösungszeit bei einem gescheiterten Projekt: Wochen. Die Mathematik ist eindeutig.