Lessons Learned from a Project Turnaround
- Michael Philipzen

- 2 days ago
- 2 min read
What the last twelve months in a high-pressure transformation really taught us.
Large transformation programs rarely fail because of a lack of ambition. They struggle because complexity, ambiguity, and unresolved assumptions accumulate faster than decisions.
The turnaround described here did not come from a new target architecture, but from introducing very concrete operating formats at exactly the points where the project had previously stalled.
1. The “Process Factory” turned discussions into decisions
The “Process Factory” was introduced as a structured, industrialized setup to work through end-to-end processes in a fixed cadence, with clear entry criteria and concrete outputs. It was not a workshop series, but a production line for decisions: Processes that survived left with a clear design; those that didn’t were explicitly rejected. Lesson:
A turnaround needs formats that force closure. Open discussions do not scale in complex programs.
2. The “Klärwerk” stopped ambiguity from silently spreading
The “Klärwerk” acted as a dedicated clarification space for unresolved topics: contradictory requirements, unclear ownership, implicit assumptions. Topics entered “dirty” and were not allowed to leave unresolved. Every outcome was binary: clarified, decided, or consciously postponed with consequences.
Lesson:
Ambiguity is not dangerous because it exists – it is dangerous because it remains unaddressed.
3. The “Test Arena” reframed testing as a steering instrument
The “Test Arena” established early, visible testing as a core element of design validation rather than a downstream quality gate. What failed here was treated as a design issue, not a test defect. This created immediate feedback loops between process design, system behavior, and organizational readiness.
Lesson:
Early testing disciplines decisions. Late testing merely documents failure.
4. The “Cutover Control Center” changed how the project thought about go-live
The “Cutover Control Center” was not set up as a last-minute go-live war room, but as a long-running coordination and transparency model. Dependencies, prerequisites, and operational risks were made explicit months in advance and tracked continuously.
Lesson:
Cutover does not fail on the weekend. It fails in the months where assumptions remain unspoken.
5. Parallel worlds required orchestration, not forced harmonization
Old and new system worlds deliberately coexisted. The turnaround did not aim for premature harmonization, but for clear rules on interaction, responsibility, and boundaries.
Not everything had to be clean – everything had to be controllable.
Lesson:
In turnarounds, manage ambiguity consciously instead of pretending it does not exist.
6. Governance shifted from control to navigation
Governance bodies were streamlined and repurposed: fewer status updates, clearer decision scopes, explicit trade-offs. The focus moved from reporting progress to enabling direction.
Lesson:
Governance either increases decision velocity – or it becomes organizational drag.
7. Expectation clarity outweighed technical excellence
Many conflicts dissolved not through better solutions, but through explicit alignment on expectations: What is in scope? What is not? What is “good enough” for now?
Lesson:
Turnarounds rarely fail due to lack of expertise. They fail due to unspoken expectations.
Let's keep on moving, folks!



Comments