Your business case runs for five years. Your system implementation plan may run for 18 months, two years, perhaps three. It starts with mobilisation and works through design, build, testing, data, cutover, go-live and a couple of months of hypercare.
Too often, the transformation programme adopts the same horizon. Once the technology is stable, the implementation team leaves, the programme closes, and the business takes over the benefits realisation.
Yet most of the value the board approved has not arrived yet. It is still sitting in years two, three, four and five of the business case. In my experience, a benefit that nobody owns and chases never arrives.
For years, I planned transformation programmes backwards from go-live. And I was good at it. The plans were detailed, the milestones were clear, and design, build, test, data migration and cutover were tightly managed. When dates moved, we replanned and kept going.
Once the technology was stable, the programme could close. My team was usually already preparing for the next implementation, sometimes in another country.
Most of the value a board approves lands in the years after go-live, and a benefit nobody chases never arrives.
That competence hid something from me for longer than it should have. We were extremely precise about what had to happen before go-live. We were much less specific about what had to happen afterwards for the business case to become real.
I think about that differently now.
If the business case commits the organisation to five years of benefits, I want the transformation programme to have a five-year horizon too.
That does not mean keeping the implementation team together for five years. After go-live, the programme changes shape. The system implementation may finish a few months after go-live. But the transformation programme continues around the outcomes it was funded to deliver. The value owners remain accountable. The benefits remain planned. Dependencies remain visible. Progress against the business case is still governed.
The programme finishes when the transformation has delivered what the organisation approved, or when the remaining business case has been consciously rebaselined.
I still plan backwards. I just start further out.
Start from the final year of the business case
The usual planning question is: what do we need to do to hit go-live?
That question still matters though. But I now ask another one first: what has to be true by the final year of the business case?
Suppose the board has approved a five-year transformation case. Start in year five.
What value should have been realised by then?
Which business measures should have moved, which costs should have come out, and which processes, risks, revenues or productivity should look different?
Then work backwards.
Before asking what it takes to hit go-live, ask what has to be true by the final year of the business case, then work back to mobilisation.
what has to be true in year four for year five to happen?
what must be in place in year three?
what has to change in the business during year two?
what needs to be enabled at go-live?
and what, therefore, has to be designed, built, tested, and prepared during implementation?
That creates a different planning logic. Instead of starting with implementation and eventually handing over the benefits, you start with the business case, work through the benefits and business changes required to deliver it, identify the capabilities needed, and then determine what the technology implementation must enable.
The technology plan still matters. It just sits inside a larger transformation plan.
Make the transformation programme as long as the business case
This is the first thing I would change on many programmes.
Put the business case and the transformation programme plan side by side and look at the final date on each. If the business case runs to 2031 and the transformation programme disappears in 2028, ask who is managing the difference.
System implementation is one phase of a transformation.
The transformation programme itself should run for as long as the business case it was funded to deliver.
A five-year transformation programme does not need the same level of activity every year. The first two years may contain thousands of implementation activities and tens (sometimes, hundreds) of people. Years three to five may include far fewer actions around benefit milestones, process adoption, further releases, operating model changes, and the measures in the business case. The programme’s purpose does not change: it still exists to turn the approved investment into the outcomes that justified it in the first place.
I now see system implementation as one phase of the transformation.
Build the benefits realisation plan during mobilisation
At mobilisation, the pressure is usually elsewhere. Get the team in place. Confirm scope. Mobilise the workstreams. Start design. Protect the date.
The benefits are there, but often as headline numbers in the business case: £20M cost reduction, a five-day month-end close, lower working capital, 30% faster onboarding. Those are useful commitments, but they are not yet plans.
Turn every headline benefit into a plan at mobilisation: phase it across the years the business case expects, with what has to change for each year’s step to happen.
One of the first things I now want to see is a benefits realisation plan that takes every material benefit and phases it across the years in which the business case expects it to arrive.
Take a simple example: faster month-end close.
The business case may promise a five-day close. The benefits realisation plan needs to show the route to it. For example, the close takes 12 working days today. In year one it falls to 8 days after intercompany reconciliation moves into the new solution. In year two, it falls to 6 days once regional finance teams stop making specific adjustments outside the system. In year three, it reaches 5 days after the remaining process and data changes are embedded.
Now the benefit can be managed.
The first improvement may depend heavily on the system. Later improvements may depend much more on process discipline, operating model changes, data quality, or behaviour inside the business.
Those activities still need dates and owners. Otherwise, the business case quietly assumes the value will arrive at go-live, without anyone managing what has to produce it.
Capture the baseline while you still can
This is one of the easiest things to postpone and one of the hardest things to reconstruct later.
You need to know where you started.
I have seen programmes reach go-live with a clear description of the new capability but a weak answer to a much more basic question: what was the number before we changed it?
Sometimes the old reports have disappeared. Definitions have changed. The legacy system has been retired. People who understood the previous process have moved on.
Record each benefit’s baseline while the old system, its reports and the people who understood the process are still there.
Then the transformation is trying to prove improvement against a baseline nobody properly captured.
Record it early. For every material benefit, agree on what the current measure is, where the number comes from, what exactly it means and how the same outcome will be measured after go-live.
The system may change. The definition of success cannot quietly change with it.
For each benefit, I want three things to be clear: where we are today, where we should be each year, and what has to change to move between the two.
If those answers are missing, the benefit is still largely a promise.
Give every benefit a value owner
Most business cases contain an owner column. That does not necessarily mean the benefit is owned.
“Finance”, “Operations”, “Business” or “Transformation Board” are organisational labels. What I want to see is a named business leader accountable for each material benefit: one person who will still care about the number after the implementation team has gone.
And I want that person involved early.
An owner with a target explains afterwards why the benefit did not arrive.
An owner with a plan sees it going off track while there is still time.
If a value owner appears at handover, they inherit a solution whose important design decisions have already been made. If they are accountable for delivering £10M of value three years later, they should have a voice while the programme decides what capabilities, data, and process changes will make that £10M possible.
Then they need a plan, not just an annual target: the activities, dates, dependencies and decisions required to realise the benefit, planned with the same seriousness we apply to implementation.
An owner with a target can explain afterwards why the benefit did not arrive. An owner with a plan can see it going off track while there is still time to intervene.
If the owner column on your programme contains a committee rather than a person, I wrote previously about what happens when a committee is named as the owner of a change.
Connect the benefits plan to the implementation plan
This is where benefits management often becomes detached from delivery.
The implementation team has its plan. The benefits team has its register. They meet around go-live. They should be connected from the beginning.
When scope has to go to protect the go-live date, ask one question beyond delivery risk: what value moves with it?
Suppose the programme needs to remove scope to protect the go-live date. The usual discussion asks what can move, what creates the least delivery risk and what can be deferred into a later release.
The benefits plan adds another question: what value moves with it?
Perhaps removing one capability delays £4M of benefit by a year. Another item may have little effect on the business case. Perhaps protecting the go-live date is still the right decision.
The difference is that the sponsor now sees the value consequence alongside the delivery consequence.
The same applies to design decisions. A simplification may reduce implementation risk but constrain a later benefit. Poor data quality may delay automation benefits. A deferred integration may change the year in which working capital improvement begins. A process decision may make a business-case assumption impossible.
When the two plans are connected, those consequences become visible before the decision is made.
That is why I no longer think benefits realisation begins after implementation. The implementation is already making decisions about which benefits will be possible later.
Go-live remains an important anchor
Planning backwards from the benefits does not make go-live less important. A large proportion of the benefits cannot begin until the new capability is in use, so I still treat go-live as a major planning anchor. What changes is where it sits.
It is no longer the right-hand edge of the transformation plan. It sits somewhere in the middle.
Before go-live, implementation dominates the programme. After go-live, the balance shifts toward adoption, business change, and value realisation.
Put the first weeks after go-live into the value owners’ plans now: what stops, what starts, and which measure should begin to move.
The first activities after go-live should already exist in the value owners’ plans. What changes on the first Monday? Which old process stops? Which new behaviour starts? Which measure should begin moving? Who checks whether it has? What happens if it does not?
I wrote earlier this month about how to capture what should run differently from day one on a single page.
Hypercare can still end. The implementation team can still leave. The transformation programme continues.
The programme should change shape after implementation
This is where I expect some people to disagree.
Why keep a programme open for five years when most of the delivery work is finished? Because keeping the transformation programme alive does not mean keeping the implementation machinery alive. The team should get smaller. Meetings should become fewer. Some forums should disappear. Some responsibilities should move into normal business governance.
Organisations tend to govern a transformation most closely while the money goes out, and step back just as the promised value should start coming back.
But there should still be a coherent transformation plan, clear ownership and an executive view of whether the investment is producing what was promised. Otherwise we create a strange asymmetry.
The organisation governs the spending intensively while the money is going out, then reduces the governance just as the promised value is supposed to start coming back.
What if the benefits are handed to BAU?
They can be.
But “BAU owns the benefits” is not, by itself, a governance model.
Before benefits pass to business as usual, name who will still compare actual value with the investment decision the board made.
The more important question is what still connects those benefits to the transformation and its approved business case.
Who can see that benefit A is slipping because business change B never happened?
Who challenges a value owner whose measure has not moved?
Who decides whether to rebaseline a benefit?
Who tells the sponsor that the original business case is no longer achievable?
Who compares actual value with the investment decision the board made several years earlier?
Those questions may eventually be handled by a transformation office, portfolio governance, finance or another permanent business forum. That can work, provided the transition is deliberate, and the transformation does not disappear simply because the technology implementation is complete.
For me, that continuing horizon still belongs in the transformation programme plan, even when the mechanism that runs it becomes lighter and moves into permanent governance.
If your programme already ends with the implementation
You do not need to rebuild the implementation plan. Leave it alone. It is probably doing exactly what it was designed to do.
Add the part that is missing.
Mid-programme, leave the implementation plan alone.
Add baselines, phased benefits and named value owners, and extend the plan to the end of the business case.
Take the business case and work through each material benefit. Establish the baseline. Phase the benefit across the remaining years. Name one value owner. Ask what has to happen each year for the value to arrive. Identify what that plan depends on. Then connect those dependencies back to current programme decisions and extend the transformation programme plan to the end of the business case.
You may find uncomfortable things: a benefit nobody wants to own, a number nobody knows how to measure, a target with no credible route behind it, a saving dependent on functionality that has already left scope, a year-three benefit dependent on a business change nobody has planned, or an owner who had no idea their name was in the business case.
They are the reason to do it now, while the programme can still change something.
Start with one benefit
You do not need to redesign your entire programme tomorrow.
Plan one significant benefit properly, from its baseline to its final year, then put its timeline next to your programme plan and look at the gap.
Take one significant benefit from the approved business case and ask:
what is the baseline?
what should this benefit deliver in each year of the business case?
who owns it?
what has to happen for each step to occur?
which current programme decisions affect it?
where does it sit in the transformation plan after go-live?
If you cannot answer those questions, you are not managing the benefit with the same discipline as the implementation.
Do it properly for one benefit, then put its timeline next to your current programme plan.
The gap becomes very obvious.
For years, I planned transformations backwards from go-live.
I still plan backwards. I just start further out.
I start at the final year of the business case and work back through the benefits, the business changes, the capabilities and the system implementation until I reach mobilisation.
If the business case runs for five years, I want the transformation programme to span those five years too.
Go-live is an important milestone in that plan. It is not the end of it.
Roman