Die Ausgangssituation

Neulich legte mir ein neuer Projektleiter seine Controlboard-Präsentation vor. Das Vorhaben: KI-Einführung in einem wesentlichen Geschäftsbereich. Die Folien sahen professionell aus: klare Ziele, ansprechende Roadmaps mit fünf Meilensteinen, bunte Kringel zur Visualisierung des iterativen Vorgehens. Alles wirkte durchdacht.

Doch beim genaueren Hinsehen wurde ein fundamentales Problem sichtbar: Es stand nichts Inhaltliches drin.

In der Budgetplanung prangte ein stattlicher Posten für „Change Management". Die Begründung des Projektleiters: „KI ist schließlich ein massives Veränderungsprojekt, da ist Begleitung essenziell." Da kann man nicken. Es klingt logisch, es klingt professionell.

Aber was bedeutet das eigentlich konkret?

Wenn Projektsprache zur Nebelkerze wird

Das ist die „Meta-Falle": Die Kunst, über ein Thema so abstrakt zu sprechen, dass niemand widersprechen kann, aber auch niemand weiß, was am nächsten Montag eigentlich getan werden muss.

Dann ist es kein Plan, sondern nur eine Vokabel.

Entscheider müssen ein Projekt nicht nur logisch nachvollziehen können, sie müssen es innerlich sehen können. Die Testfragen sind simpel:

• Wer geht wohin?
• Mit wem wird gesprochen?
• Was passiert in Woche 1, 2, 3?
• Welche Artefakte entstehen: Entscheidungsvorlagen, Trainings, Prozessänderungen, Guidelines, Templates?
• Was ist am Ende einer Phase anders als vorher, und woran merken wir das?

Was bedeutet „Change Management" in diesem KI-Projekt konkret?

• Geht ein Berater tatsächlich in die Abteilung X, setzt sich neben einen Senior-Mitarbeiter und beobachtet zwei Stunden lang dessen Arbeitsweise, um dann gemeinsam zu erarbeiten, wie ein KI-Tool diesen spezifischen Workflow beschleunigen kann?
• Oder bedeutet „Change Management" lediglich, dass wir eine firmenweite Rundmail mit einem Link zu einem generischen Videokurs verschicken und hoffen, dass die „Kultur" sich von selbst heilt?

Solange diese Fragen nicht beantwortet sind, bleibt ein Projekt „Theater". Nicht, weil es böse gemeint ist, sondern weil es nicht greifbar ist.

Und was man sich nicht vorstellen kann, das genehmigt man auch nicht.

Warum Nebelkerzen im Controlboard so gefährlich sind

Controlboards und GL-Runden funktionieren nach einem einfachen Prinzip: Zeit ist knapp, Vertrauen ist fragil, und jede Unschärfe wird als Risiko interpretiert.

Wenn eine Roadmap nur fünf Meilensteine zeigt, aber nicht sagt, was inhaltlich in diesen Phasen passiert, dann entsteht beim Gegenüber nicht das Gefühl von Struktur, sondern von Nebel.

Das Problem ist: Wenn wir auf der Meta-Ebene verharren, treffen wir keine echten Entscheidungen. Wir verwalten lediglich Begriffe. Ein Controlboard, das ein Budget für „strategische Ausrichtung" freigibt, ohne zu wissen, welche Hebel konkret umgelegt werden, investiert nicht in die Zukunft; es erkauft sich das gute Gefühl, etwas getan zu haben.

Und Nebel führt fast immer zu denselben Reaktionen:

• „Das klingt nach Buzzwords."
• „Wie viel davon ist schon durchdacht?"
• „Wofür genau brauchen wir Budget?"
• „Was genau kaufen wir uns hier ein: Output oder Hoffnung?"
• „Können wir das nicht den Führungskräften (ohne Projektoverhead) überlassen?"

Das ist der Punkt, an dem Projekte häufig scheitern. Nicht wegen mangelnder Motivation, sondern wegen mangelnder Konkretion.

Der Kern: Nicht nur Methodik zeigen, sondern Strategie offenlegen

In meiner Erfahrung ist der häufigste blinde Fleck: Man zeigt Vorgehen, aber man verschweigt die inhaltliche Strategie.

Gerade bei Transformations oder Enablement-Themen (AI ist nur ein Beispiel) gibt es immer mehrere mögliche Zielbilder, die völlig unterschiedliche Maßnahmen bedeuten:

• Geht es um Skills (z.B. besseres Prompting, Guidelines, Kataloge, Coaching)?
• Geht es um Tooling und Integration (z.B. Standard-Tools, IDE-Integration, Plattform, Rechte, Governance)?
• Geht es um Prozess-Redesign (z.B. wie Arbeitsschritte neu verteilt werden)?
• Geht es um Automation (z.B. agentische Workflows, teilautonome End-to-End-Unterstützung)?
• Geht es um Operating Model (z.B. neue Rollen, neue Verantwortlichkeiten, neue KPIs)?

Wenn das nicht explizit gemacht wird, diskutiert das Gremium am Ende nicht über das Projekt, sondern über seine eigenen Annahmen. Jeder hört dasselbe Wort und stellt sich etwas anderes vor. Das ist die perfekte Rezeptur für Verzögerung.

Es geht darum, welche Varianten es im Vorgehen gibt, diese abzuwägen und gemeinsam zu entscheiden, und nicht pauschal davon auszugehen, dass die intuitiv gewählte Variante die beste ist.

„Agile" ist kein Freifahrtschein fürs Nicht-Denken

Ein häufiges Argument, um die Meta-Falle zu rechtfertigen, ist die Agilität. „Wir arbeiten doch agil! In einer komplexen VUCA-Welt können wir heute noch nicht sagen, was im Meilenstein 3 im Detail passiert. Wir fahren auf Sicht und lernen iterativ."

Ganz ehrlich? Das ist in 80% der Fälle eine Ausrede.

Echte Agilität erfordert mehr Vorbereitung und tieferes Durchdenken, nicht weniger. Agilität heißt: klares Ziel, flexibler Weg. Nicht: kein Ziel, aber viel Bewegung.

Wer nicht beschreiben kann, welches konkrete inhaltliche Ergebnis eine Phase haben soll, hat das Thema schlicht nicht durchdrungen. Die Flucht auf die Meta-Ebene ist oft die Flucht vor der kognitiven Anstrengung, die das Detail erfordert. Es ist geistige Bequemlichkeit, getarnt als moderne Methodik.

Der Balanceakt: Warum wir die Meta-Ebene trotzdem fürchten und lieben

Ich muss selbstkritisch gestehen: Die Meta-Ebene ist verführerisch, weil sie sicher ist. Es ist ein psychologischer Schutzmechanismus. Wenn ich zu konkret werde, mache ich mich angreifbar.

Sobald man im Controlboard sagt: „Wir führen am 12. Oktober einen Workshop mit dem Team von Herrn Müller durch, um das Datenmodell für die Agenten-Struktur festzulegen", öffnet man die Tür für Bikeshedding (das Zerreiben von Details, die eigentlich nebensächlich sind). Dann diskutieren die Entscheider plötzlich darüber, ob Herr Müller der richtige Ansprechpartner ist, ob der 12. Oktober nicht zu nah am Herbstferien-Ende liegt oder ob man „Datenmodell" nicht lieber „Informations-Architektur" nennen sollte.

Die Meta-Ebene schützt uns vor diesen zeitraubenden Detail-Diskussionen über Nebensächlichkeiten. Aber dieser Schutz ist teuer erkauft. Er führt dazu, dass das Vertrauen der Führungsebene schleichend erodiert. Sie spüren instinktiv, dass unter den bunten Kringeln kein Fundament liegt.

Es gibt also eine berechtigte Gegenbewegung. Deshalb ist das Ziel nicht „maximal konkret", sondern zweistufig klar:

1. Metaebene, aber präzise: Zielbild, Prinzipien, Entscheidungslogik, Prioritäten.
2. Konkretion, aber fokussiert: die wenigen Handlungen, Ergebnisse und Deliverables, die zeigen, dass es ein echter Plan ist.

Trotzdem würde ich die Gewichtung klar setzen: In den meisten Realitäten ist das dominante Problem nicht „zu konkret", sondern „zu abstrakt". Das Pendel schlägt viel zu weit in Richtung Abstraktion aus.

Nebeneffekt: Das „AI Slop"-Problem

Dieses Meta-Problem zeigt sich nicht nur in Controlboards. Es durchzieht inzwischen die gesamte Wissensarbeit.

Am Markt beobachte ich einen Trend zum oberflächlichen KI-Einsatz: Viele nutzen KI extrem simpel. Sie werfen einen einfachen Prompt ein, erhalten ein glattes, aber generisches Ergebnis und kopieren es ungefiltert als eigenes Arbeitsergebnis.

Das Ergebnis wirkt auf den ersten Blick professionell, ist aber in der Substanz schwach.

Das ist die Meta-Falle auf Task-Ebene: Die KI liefert die perfekte Oberfläche (schöne Sätze, korrekte Grammatik), aber ohne eigenen, tiefen Input und bohrendes Nachfragen bleibt das Ergebnis wertloses Rauschen.

Die Lösung ist dieselbe wie im Controlboard: konsequent nach unten fragen, ob an die KI oder an sich selbst.

• „Was heißt das konkret?"
• „Wie sieht das in der Praxis aus?"
• „Welche Ergebnisse entstehen und wann?"
• „Wer macht was bis nächsten Freitag?"

AI kann helfen, schneller zu sein. Denken muss man trotzdem.

Das Gegenmittel: Konkretheit als Denkwerkzeug

Die Lösung ist einfach formuliert, aber schwer umzusetzen: Beschreibe, was tatsächlich passiert. So konkret, dass sich jemand visuell vorstellen kann, was vor sich geht.

• Statt „Stakeholder Management":

„Wir führen in den nächsten drei Wochen sechs Interviews mit den Leitern der betroffenen Bereiche, je 45 Minuten, um Top-5 Hürden zu erfassen. Ergebnis ist eine priorisierte Hürdenliste und eine Entscheidungsvorlage, was wir zentral lösen und was lokal bleibt."

• Statt „Pilotierung":

„Wir wählen zwei Teams mit klar definierten Use Cases aus, setzen Baseline-Metriken, arbeiten vier Wochen in festem Rhythmus, und liefern am Ende ein Pilot-Playbook inklusive Checkliste, Setup, Lessons Learned und Rollout-Empfehlung."

• Statt „Change Management":

„Wir machen drei Formate: 60-Minuten Intro-Session, 90-Minuten Hands-on-Workshop, wöchentliche Office Hours. Parallel definieren wir Champions pro Bereich und haben ein Kommunikationspaket mit konkreten Do’s und Don’ts. Erfolg messen wir über Nutzung, Zeitersparnis und Qualitätsindikatoren."

Wenn du merkst, dass du etwas nicht konkret beschreiben kannst, dann ist das ein Signal: Du musst noch weiter nachdenken.

Praktische Checkliste für deine nächste Controlboard-Story

• Kann ich für jede Phase ein konkretes Ergebnis nennen?

Nicht nur „Meilenstein erreicht", sondern „Playbook fertig", „Pilot abgeschlossen", „Entscheidung X getroffen", „Prozess Y geändert".

• Sind Rollen als Handlungen beschrieben?

„macht Change" reicht nicht. „führt 8 Workshops durch, etabliert Champions-Netzwerk, setzt Kommunikationsplan um" ist belastbar.

• Ist die Strategie eindeutig?

Was ist das Zielbild, und was ist explizit nicht Zielbild? Welche Optionen wurden bewusst ausgeschlossen? Gilt es die Strategie vielleicht sogar zuallererst zu diskutieren, bevor über das Projekt gesprochen wird?

• Wo sind die Ungewissheiten benannt?

Nicht versteckt, sondern als Hypothesen mit Testplan. Sagt: „Wir wissen noch nicht, ob wir auf Agenten oder Prompting setzen, deshalb untersuchen wir in Phase 2 genau diese drei Kriterien."

• Kann ein Außenstehender sich das als Ablauf vorstellen?

Zeigt nicht nur die Prozess-Roadmap, sondern skizziert den Zielzustand. Wie sieht der Arbeitsplatz in 12 Monaten aus? Was genau tut jemand dann nicht mehr, was er heute noch tut? Wenn das unklar bleibt: weiterdenken.

Abschluss: Konkretion ist Respekt gegenüber Entscheidungszeit

Abstraktionen haben ihren Platz. Aber zu oft verstecken sie mangelnde Durchdringung eines Themas. Sie wirken wie professionelle Projektarbeit, sind aber letztlich Fassade.

Metaebene ist wichtig. Aber Metaebene ohne Konkretion ist wie Architektur ohne Statik: sieht gut aus, trägt nicht.

Entscheider durchschauen das. Und sie haben recht damit, solche Vorschläge kritisch zu hinterfragen. Das ist erstmal kein unfaires Mikromanagement und auch kein Signal einer fehlenden Vertrauenskultur. Das ist normales Unternehmertum.

Die beste Prüfung für jede Präsentation, jedes Konzept, jeden Plan: Kann sich jemand ohne Vorkenntnisse vorstellen, was passieren wird? Wenn nicht, zurück an den Schreibtisch.

Der Artikel ist auch eine Erinnerung an mich selbst. Ich rutsche da ebenfalls rein. Wörter sind schneller als Denken. Aber Projekte werden nicht durch Wörter entschieden, sondern durch glaubwürdige Bilder davon, was morgen tatsächlich passiert.

Denk es zu Ende. Bis es greifbar wird. Bis es vielleicht sogar wehtut. Erst dann hast du eine Strategie, und kein Theaterstück.