A transformation plan often begins with a date: a data centre must close, a separation agreement must be completed, or a new capability must be in place by a particular point.
That date matters. But it doesn't tell us how the programme will get there.
In a complex technology transformation, Planning brings together what has been learned through Discovery and Scope and tests whether the proposed delivery approach can work in practice. It connects the delivery requirement to the people, capabilities, dependencies and constraints that will shape the route into Delivery.
The result should be a credible path that can be challenged, improved and adapted as evidence develops.
Start with the logic established in Scope
By the time Planning begins, Discovery should have established an understanding of the landscape and the context around the transformation. Scope should have developed that understanding into a credible view of what needs to change, the likely delivery requirement, and the relationships between the things that need to move together or in sequence.
Planning shouldn't discard that work and start again. It takes the transition logic and begins to put time and real-world delivery conditions around it.
If two application groups must transition together, when can the necessary technology, business and operational capability be available? If one group must move before another, how much time is needed between them? Where coexistence is possible, could it provide useful flexibility?
The answers may challenge assumptions made during Scope. That is part of the process: planning should feed better evidence back into the delivery approach.
Begin with a delivery hypothesis
I find it useful to start with a moveable framework showing the main delivery packages, significant enablers, known dependencies and constraints against a broad timeline.
At this stage, a package placed in a particular month is a hypothesis to be tested. The initial framework gives experienced people something tangible to challenge.
For example, a migration package might depend on a target environment becoming available. Rather than treating “target ready” as a fixed date, the discussion can explore what that package actually needs. Does the whole environment need to be complete? Could the required components be prioritised? Can the build start earlier or receive additional capacity? Is there an interim approach that creates useful flexibility?
A dependency describes something that must be managed. It should prompt questions about the available delivery options.
Develop the priority packages
The next step is to open up the priority packages and understand what delivering each one entails. That includes the major activities, prerequisites, supplier involvement, business testing, operational readiness, milestones and demand on specialist teams.
The aim is to develop enough detail to manage the package towards its transition. The detailed, step-by-step cutover plan comes later, as the event approaches.
Not every package needs that level of detail at the same time. Work that is approaching Delivery may need a well-developed package plan, while later work remains at framework level until there is enough evidence—and a practical reason—to go deeper.
As package plans develop, they will improve or challenge the initial framework. If the evidence shows that the original position doesn't work, move the package or reconsider the approach rather than forcing the detail to fit.
Integration is where programme-level problems become visible
An individual package can look achievable and still be impossible in the context of the wider programme.
Three migrations may each need a reasonable amount of network effort. But if all three require the same specialists in the same month, the combined demand may exceed the available capacity. The same applies to business testers, suppliers, operational teams, target platforms and security capabilities.
There may also be timing conflicts between packages. One group's testing might require an interface weeks before another group plans to provide it. Or several packages may depend on a shared capability whose procurement or implementation has a long lead time.
This is why integration means more than putting separate plans into one schedule. It means testing how the work fits together and making the decisions needed when it doesn't.
Those decisions might involve resequencing, splitting or combining packages, accelerating an enabler, securing additional capacity, changing the delivery approach or revisiting a constraint. The goal is to establish the best credible programme-level path, rather than preserve every date from the first framework.
Watch for the less obvious critical path
The most visible workstream isn't always the one driving the programme. Application migrations may attract the most attention, while connectivity, identity, supplier mobilisation, operational readiness or business capacity determines when those migrations can actually happen.
Follow the prerequisites and constraints far enough to understand what creates the real delivery position. A capability needed in six months may require a decision, purchase order or build activity now.
Move into Delivery as work becomes ready
A programme doesn't need every package to reach the same level of planning maturity before Delivery can begin. Priority work can progress when its delivery path has been sufficiently developed and tested against the relevant dependencies, capacity, operational constraints and programme commitments.
That is different from being ready to execute a migration. Once a package enters Delivery, the team still needs to develop the detailed preparation, transition, cutover and stabilisation plans appropriate to that event.
Meanwhile, later packages continue through Scope and Planning. Delivery generates new evidence, which should improve the plans for the work that follows.
The first plan is a working hypothesis. Its job is to help the programme learn what will work, expose what will not, and make the decisions needed to move forward with confidence.