Mirum Malum, Mirum Beatum — Überraschungen als Risiko und Ressource managen

Projektmanagement spricht gern über Risiken, Abhängigkeiten und Maßnahmen. Das ist richtig, aber es erfasst nur einen Teil der Unsicherheit. Ein Risiko ist normalerweise etwas, das wir wenigstens als Möglichkeit denken können: Eine Frist könnte rutschen, eine Ressource könnte ausfallen, eine technische Annahme könnte sich als falsch erweisen. Dafür lassen sich Wahrscheinlichkeiten, Auswirkungen und Gegenmaßnahmen diskutieren.

Eine echte Überraschung verhält sich anders. Sie trifft nicht nur den Plan, sondern häufig die Annahme, auf der der Plan beruht. Plötzlich zeigt sich ein Markt anders als erwartet. Ein Nutzer verwendet eine Funktion völlig anders. Ein Modell produziert ein Ergebnis, das weder in das gewünschte Schema noch in die bisherige Fehlerlogik passt. Eine regulatorische, organisatorische oder technische Veränderung verschiebt den Rahmen. Oder ein vermeintlicher Fehler öffnet eine Lösung, nach der niemand gesucht hatte.

Solche Momente sind im Projekt nicht automatisch gut oder schlecht. Entscheidend ist, was sie mit dem Projektziel, den Annahmen und den verfügbaren Handlungsoptionen machen. Genau dafür sind die Arbeitsbegriffe Mirum Malum und Mirum Beatum nützlich.

Risiko ist nicht dasselbe wie Überraschung

Risikomanagement arbeitet mit erwartbarer Unsicherheit. Überraschungsmanagement beginnt dort, wo die vorhandene Erwartungsstruktur nicht mehr ausreicht. Das klingt zunächst akademisch, ist in KI-Projekten aber sehr praktisch.

Wer ein Sprachmodell einsetzt, kann beispielsweise einplanen, dass Ergebnisse geprüft werden müssen. Das ist ein Risiko- und Qualitätsproblem. Überraschend wird es, wenn ein scheinbar falscher Output auf eine unklare Anforderung, eine widersprüchliche Datenbasis oder sogar auf einen neuen Lösungsweg hinweist. Dann muss nicht nur der Output bewertet werden. Möglicherweise muss die eigene Fragestellung neu betrachtet werden.

Dasselbe gilt außerhalb der Technik. Ein Kunde kann ein geplantes Feature ablehnen, aber gerade dadurch ein viel wertvolleres Problem sichtbar machen. Ein Teammitglied kann ausfallen und damit zunächst ein klares Risiko erzeugen, gleichzeitig aber offenlegen, dass das Projekt zu stark an Einzelwissen hängt. Eine Kostensteigerung kann ein Vorhaben gefährden und zugleich erzwingen, dass die Architektur vereinfacht wird. Ein neuer Marktimpuls kann Wachstum versprechen und trotzdem das Kernprojekt destabilisieren.

Die Überraschung ist daher zunächst Information. Die Bewertung folgt erst danach.

Zwei Arbeitsbegriffe für unerwartete Dynamik

Mirum Malum bezeichnet eine Überraschung, die das Projekt zunächst negativ trifft: Sie zerstört eine Annahme, erhöht Aufwand, erzeugt Qualitäts- oder Sicherheitsprobleme, blockiert Arbeit oder gefährdet ein Ziel. Mirum Beatum bezeichnet eine Überraschung, die einen unerwarteten Vorteil eröffnet: eine bessere Lösung, einen neuen Anwendungsfall, eine Abkürzung, ein unerwartet positives Nutzerverhalten oder eine Erkenntnis, die das Projekt stärker macht.

Wichtig ist die zeitliche Formulierung „zunächst". Die Klassifikation ist nicht endgültig. Ein Mirum Malum kann nach einer guten Reaktion zum Ausgangspunkt einer Verbesserung werden. Ein Mirum Beatum kann sich später als Ablenkung, Scope-Explosion oder falsches Signal entpuppen.

Damit wird Überraschungsmanagement zu einer Form der Deutungskompetenz. Nicht jedes unerwartete Ereignis verdient eine Projektänderung. Aber jedes relevante unerwartete Ereignis verdient eine saubere Prüfung.

Der eigentliche Schaden beginnt oft nach dem Ereignis

Viele Projekte scheitern nicht an der ersten Überraschung, sondern an der Reaktion darauf. Unter Druck verändern Teams gleichzeitig Ziele, Prioritäten, Tools und Zuständigkeiten. Neue Informationen werden mit alten Annahmen vermischt. Temporäre Maßnahmen werden zu dauerhaften Strukturen. Später weiß niemand mehr, welche Entscheidung auf welchem Befund beruhte.

Bei KI-Projekten steigt dieses Risiko, weil neue Optionen extrem schnell erzeugt werden können. Für jedes Problem lässt sich in wenigen Minuten eine alternative Architektur, ein neues Tool, ein anderer Workflow oder ein neues Modell vorschlagen. Diese kreative Geschwindigkeit ist wertvoll. Sie kann aber den Eindruck erzeugen, dass auf jede Überraschung sofort mit einer neuen Lösung reagiert werden müsse.

Professioneller ist ein anderer Ablauf: erst stabilisieren, dann interpretieren.

Stabilisieren bedeutet nicht, nichts zu tun. Es bedeutet, die Wirkung der Überraschung einzugrenzen, damit die Analyse nicht unter laufendem Chaos stattfindet. Erst danach wird geprüft, welche Annahme getroffen wurde, was sich tatsächlich verändert hat und welche Handlungsoptionen daraus entstehen.

Ein Fünf-Schritte-Protokoll für Überraschungen

Für den praktischen Einsatz hilft ein kurzes Protokoll, das sowohl negative als auch positive Überraschungen gleich behandelt. Damit wird verhindert, dass Risiken nur defensiv und Chancen nur euphorisch verarbeitet werden.

Die Stärke dieses Ablaufs liegt darin, dass Mirum Malum und Mirum Beatum zunächst denselben Prüfprozess durchlaufen. Eine positive Überraschung erhält damit eine Beweispflicht. Eine negative Überraschung erhält die Chance, mehr als nur Schaden zu sein.

Mirum Malum: Erst schützen, dann reparieren

Bei einer negativen Überraschung entsteht schnell der Impuls, sofort eine Lösung zu bauen. Genau hier lohnt sich Disziplin. Bevor optimiert wird, muss klar sein, was eigentlich geschützt werden soll.

Wenn eine wichtige Annahme nicht mehr gilt, muss nicht automatisch das gesamte Projekt neu geplant werden. Vielleicht betrifft die Abweichung nur einen Teil des Lösungswegs. Vielleicht bleibt das Ziel intakt, während lediglich ein technischer Pfad ersetzt werden muss. Vielleicht ist der Befund noch gar nicht belastbar genug, um eine strategische Änderung zu rechtfertigen.

Ein gutes Reaktionsmuster trennt daher vier Ebenen: Ereignis, Wirkung, Annahme und Entscheidung. Das Ereignis ist das, was passiert ist. Die Wirkung beschreibt, was unmittelbar blockiert oder gefährdet wird. Die Annahme zeigt, welche bisherige Vorstellung nicht mehr trägt. Erst die Entscheidung bestimmt, ob eine lokale Korrektur, ein Test, eine Eskalation oder eine Neuplanung erforderlich ist.

Diese Trennung verhindert, dass ein lokaler Fehler zum globalen Projekturteil wird.

Mirum Beatum: Chancen brauchen dieselbe Strenge wie Risiken

Positive Überraschungen sind psychologisch gefährlicher, als sie wirken. Ein plötzlich funktionierender Ansatz, ein unerwartet positives Feedback oder eine neue technische Möglichkeit kann sofort Begeisterung erzeugen. Im Projektmanagement ist Begeisterung jedoch noch kein Business Case und noch keine Priorität.

Eine Chance ist erst dann projektwirksam, wenn sie mindestens drei Fragen übersteht: Ist der Effekt real, ist er reproduzierbar, und verbessert er das Kernziel stärker als die dafür nötige Veränderung kostet?

Gerade KI erzeugt laufend faszinierende Nebenwege. Ein Modell kann eine neue Funktion vorschlagen. Eine Analyse kann ein benachbartes Marktsegment entdecken. Ein Prototyp kann zufällig einen anderen Anwendungsfall besser bedienen als den ursprünglich geplanten. All das kann wertvoll sein. Aber wenn jede interessante Idee sofort integriert wird, verwandelt sich Mirum Beatum sehr schnell in Feature Creep.

Deshalb braucht eine positive Überraschung nicht weniger Governance als ein Risiko. Sie braucht nur eine andere Prüfhaltung: nicht „Wie verhindern wir das?", sondern „Unter welchen Bedingungen verdient diese Chance einen Platz im Projekt?"

Fehler sind keine Chancen – aber sie können Hinweise enthalten

Ein besonders wichtiger Grenzfall entsteht durch Fehler. Es wäre falsch, Fehler romantisch als Innovation zu verkaufen. Die meisten falschen Ergebnisse sind zunächst genau das: falsch. Sie müssen erkannt, eingegrenzt und korrigiert werden.

Trotzdem kann ein Fehler Information enthalten. Wenn ein KI-System eine Aufgabe systematisch anders interpretiert als erwartet, kann das auf eine schwache Spezifikation hinweisen. Wenn verschiedene Modelle an derselben Stelle scheitern, kann die Datenbasis widersprüchlich sein. Wenn ein unerwarteter Output eine völlig andere, aber plausible Perspektive eröffnet, kann sich daraus eine Hypothese ergeben, die separat getestet werden sollte.