All-or-Nothing

Planning

Attempting to design the complete migration upfront, before any real learning has taken place.

Migrations that cross organisational boundaries, which is most of them, are vulnerable to this pattern. Without a clear, centralised strategy and an unambiguous mandate for who leads it, individual teams optimise for their own goals. Each makes locally reasonable decisions. Collectively, those decisions produce an incoherent whole.

We have found a simple test for whether this pattern is active: ask five senior stakeholders, independently and without warning, to describe what the migration is for and what success looks like. In our experience, this test returns genuinely consistent answers in fewer than a third of programmes at the point when it first becomes worth asking.

Post-acquisition integrations are the most acute expression of this pattern. Two organisations, each with established ways of working and proprietary technology investments, are asked to converge. Without a decision, made explicitly, with authority, and early, about who leads and on what terms, both will defend their existing approach. The result is not integration. It is parallel operation with a shared name and a growing reconciliation bill.


By the time the plan is finished, the plan is already wrong. The only question is whether the program has the structure to adapt or rigidity to pretend otherwise.

All-or-nothing planning also creates organisational brittleness. When a milestone slips (and in a complex migration, something always slips) teams shift focus from making good decisions to hitting dates. Short-cuts are applied to keep the schedule intact. The migration arrives at its destination on time, but in a condition that falls well short of what was intended. What is lost in this process is the learning.


The consequences

  • The plan is out of date before execution begins, because the planning process itself takes too long.
  • Early failures have a cascading effect across the entire programme, because everything is interdependent.
  • Teams are disempowered, following instructions rather than exercising judgement.
  • Data and insights gathered during migration are ignored because there is no space in the plan to act on them.


Watch for this signal

If the programme’s leadership is treating the plan as a fixed contract rather than a working hypothesis (if changing it requires formal escalation rather than simply good judgement) this pattern is in play.

Root error: resolving uncertainty on paper before reality can surface it.

NEXT: Pattern 4 - Control Instead of Enablement
Visit icpnet.com

Share on social