We have seen the pattern often enough now that we recognise it on sight. A programme begins well visible progress, stakeholder enthusiasm, quick wins in the first quarter. Then, somewhere around the halfway point, momentum starts to decay. By the end of the year, the programme has delivered some value but not the value promised, and the organisation is not quite sure how to explain the gap.
The pattern and why it recurs
The 60 percent point is where the easy work is done. The processes that were obviously broken have been addressed. The low-hanging integrations have shipped. The team is still moving, but the next layer of problems is harder it requires change management, not just software delivery.
Most transformation programmes are scoped and staffed for software delivery. They are not resourced for the organisational change that makes the software work. This is the design flaw. The technology is rarely the limiting factor.
The technology is rarely the limiting factor. It is almost always the gap between what the software enables and what the organisation is prepared to do differently.
Three root causes
Scope expansion without budget expansion. The programme scope grows as the team learns more about the problem. Requirements that were vague in month one crystallise into new work in month four. Without a structured mechanism to reprioritise, the team takes on more than the budget supports and delivers less than either party expects.
Stakeholder fatigue. Early transformation programmes succeed partly on novelty and executive attention. That attention is not sustainable. As competing priorities emerge, the programme loses the sponsorship it needs to push through the hard organisational changes process redesign, retraining, role adjustments.
Technology-first governance. Transformation steering committees are usually dominated by IT, project management, and finance. The business units most affected operations, sales, customer service are represented in early workshops but absent from ongoing governance. Decisions get made without the people who understand the operational consequences.
The governance failure
Most transformation post-mortems identify governance as a contributing factor. The honest version of that finding is that nobody was accountable for the business outcome only for the delivery milestones.
Delivery governance asks: are we on time and on budget? Outcome governance asks: is the business performing differently? The first question can be answered in a status report. The second requires someone with operational authority to be asking it at every review and empowered to redirect the programme when the answer is no.
Programmes that finish strong almost always have a named senior executive not the CTO or the PMO lead who is personally measured on the business outcome. That person changes the conversation in every steering committee.
What prevents it
Design the programme in phases, each ending with a measurable business outcome rather than a feature set. This forces prioritisation, creates natural checkpoints for scope management, and gives the organisation an opportunity to demonstrate value incrementally rather than waiting for a single large release.
Budget explicitly for change management from the outset typically 20 to 30 percent of the total technology investment. This includes training, process documentation, and the operational overhead of transitioning teams from old ways of working to new ones.
Identify the business unit champion before the programme starts. This is the person who will use the software daily, who will suffer if it fails, and who has enough credibility in the organisation to drive adoption. They are not a project sponsor they are a business owner with skin in the game.
- Phase outcomes by business result, not feature delivery each phase should stand alone as a value event
- Reserve 20–30% of the total budget for change management before the first line of code is written
- Assign a named business champion with operational authority, distinct from the executive sponsor
- Implement a formal scope management process from day one verbal scope changes become disputes
- 01Design programmes around measurable business outcomes per phase, not feature delivery milestones
- 02Budget 20–30% of technology spend explicitly for change management it is not optional overhead
- 03Assign outcome accountability to a senior business leader, not a project manager or IT director
- 04Treat scope expansion as a budget conversation, not a project management problem