Lessons Learned from a Project Turnaround

Was uns die vergangenen zwölf Monate in einer kritischen Transformation wirklich gelehrt haben.

Große Transformationsprogramme scheitern selten an mangelnder Ambition. Sie scheitern, weil Komplexität, Unklarheiten und ungelöste Annahmen sich schneller anhäufen als Entscheidungen.

Die hier beschriebene Wende kam nicht durch eine neue Zielarchitektur zustande, sondern durch die Einführung sehr konkreter Turnaround - Formate genau an den Stellen, an denen das Projekt zuvor ins Stocken geraten war.

1. Die “Process Factory” verwandelte Diskussionen in Entscheidungen

Die “Process Factory” wurde als strukturiertes, industrialisiertes Setup eingeführt, um End-to-End-Prozesse in einem festen Rhythmus mit klaren Einstiegskriterien und konkreten Ergebnissen durchzuarbeiten. Es handelte sich nicht um eine Workshop-Reihe, sondern um eine Produktionslinie für Entscheidungen: Prozesse, die überlebten, erhielten ein klares Design; diejenigen, die scheiterten, wurden ausdrücklich abgelehnt. Lektion:

Der Turnaround erfordert Formate, die einen Abschluss erzwingen. Offene Diskussionen sind in komplexen Programmen nicht skalierbar.

2. Das „Klärwerk“ verhinderte, dass sich Unklarheiten stillschweigend ausbreiteten

Das „Klärwerk“ diente als spezieller Raum zur Klärung ungelöster Themen: widersprüchliche Anforderungen, unklare Zuständigkeiten, implizite Annahmen. Die Themen wurden „ungeklärt“ eingebracht und durften nicht ungelöst bleiben. Jedes Ergebnis war binär: geklärt, entschieden oder bewusst mit Konsequenzen verschoben.

Lektion:

Unklarheiten sind nicht gefährlich, weil sie existieren – sie sind gefährlich, weil sie ungelöst bleiben.

3. Die „Testarena” definierte Tests neu als Steuerungsinstrument.

Die „Testarena” etablierte frühzeitige, sichtbare Tests als Kernelement der Designvalidierung und nicht als nachgelagertes Qualitätskontrollinstrument. Was hier fehlschlug, wurde als Designproblem behandelt, nicht als Testfehler. Dies schuf unmittelbare Feedbackschleifen zwischen Prozessdesign, Systemverhalten und organisatorischer Bereitschaft.

Lektion:

Frühzeitiges Testen diszipliniert Entscheidungen. Spätes Testen dokumentiert lediglich Fehler.

4. Das „Cutover Control Center” veränderte die Herangehensweise des Projekts an die Inbetriebnahme.

Das „Cutover Control Center” wurde nicht als War Room für die Inbetriebnahme in letzter Minute eingerichtet, sondern als langfristiges Koordinations- und Transparenzmodell. Abhängigkeiten, Voraussetzungen und operative Risiken wurden Monate im Voraus explizit gemacht und kontinuierlich verfolgt.

Lektion:

Ein Cutover scheitert nicht am Wochenende. Es scheitert in den Monaten, in denen Annahmen unausgesprochen bleiben.

5. Parallele Welten erforderten Orchestrierung, keine erzwungene Harmonisierung.

Alte und neue Systemwelten koexistierten bewusst. Der Turnaround zielte nicht auf eine vorzeitige Harmonisierung ab, sondern auf klare Regeln für Interaktion, Verantwortung und Grenzen. Nicht alles musste sauber sein – alles musste kontrollierbar sein.

Lektion:

Gehen Sie bei Turnarounds bewusst mit Unklarheiten um, anstatt so zu tun, als gäbe es sie nicht.

6. Governance verlagerte sich von Kontrolle zu Navigation

Die Governance-Gremien wurden gestrafft und neu ausgerichtet: weniger Status-Updates, klarere Entscheidungsbereiche, explizite Kompromisse. Der Fokus verlagerte sich von der Berichterstattung über den Fortschritt hin zur Ermöglichung der Ausrichtung.

Lektion:

Governance erhöht entweder die Entscheidungsgeschwindigkeit – oder sie wird zu einem organisatorischen Hemmnis.

7. Klare Erwartungen waren wichtiger als technische Bravour

Viele Konflikte wurden nicht durch bessere Lösungen gelöst, sondern durch eine klare Abstimmung der Erwartungen: Was gehört zum Aufgabenbereich? Was nicht? Was ist derzeit „gut genug”?

Lektion:

Turnarounds scheitern selten aufgrund mangelnder Fachkenntnisse. Sie scheitern aufgrund unausgesprochener Erwartungen.

Let's keep on moving, folks!