How to Lead Transformation Beyond the Programme: A Guide for SROs
How SROs can lead sustainable service change that outlives programmes
If the programme ended tomorrow, what improvement would we have delivered? How able are we to keep improving?
That’s a question every Senior Responsible Owner (SRO) should track throughout a programme.
If delivery means “we built a new casework system,” but there’s no team to adapt it, no ownership of the outcomes it supports, and no mandate to keep learning, then you risk recreating the circumstances that triggered a programme in the first place.
I wrote about how delivery teams can create impact in a programme context. This article is for programme sponsors, SROs, and senior leaders responsible for “transformation,” particularly when that transformation is structured as a time-bound, supplier-heavy programme. It offers a way to lead that leaves your organisation more capable, not more dependent.
Not every change needs a programme
This is the first fork in the road. The moment there's any serious funding or IT complexity involved, it becomes A Programme™.
It’s worth asking whether that’s the best vehicle.
A programme is useful when there’s no other way to:
Move large amounts of money across financial years
Mobilise change across multiple teams or silos
Force coherence in an otherwise fragmented system
But if a programme hoards all the authority, energy, and knowledge, you’ve just concentrated delivery rather than invested in your organisation’s capability.
So if you go down this path, you need to lead in a way that makes the programme disposable, not central.
Design the programme to be disposable
The bigger the programme, the bigger the risk: that delivery becomes disconnected from reality, and change collapses when the scaffolding is removed.
So design it to be disposable. From day one:
Programmes are risky because they try to hold too much for too long. When they absorb all the authority, all the funding, and all the momentum, they create a vacuum behind them.
Programme vs Service-Oriented Governance
Governance is too often a convoluted control tower rather than an enabling function. A transformational programme reports into service outcomes, not the other way around.
Here are some key principles:
Boards are critical for monitoring outcomes and unblocking decisions. They need to empower cross-functional teams to escalate what they can’t solve, not to ask permission for what they can, and hold suppliers accountable for value rather than deliverables.
SROs can shift governance by making service owners visible, empowered, and funded and considering where the result of the programme will ‘live.’ The programme should ultimately transfer capability, not just deliver assets. It should act as a booster stage, not a new orbit.
Get the right roles and remit
If you don’t yet have the roles that make service-oriented governance work, don’t fake them. Fund them. Support them. Legitimate them.
Here’s a starter:
Consider which roles will ensure that a) the changes made are the right ones and b) changes will evolve without requiring a permanent programme presence. Frame roles as a governance or delivery risk, rather than a resourcing footnote.
Give service owners the authority to stop or redirect work that doesn’t serve the service. Fund their capacity to steward the whole service, not just passively consume delivery.
Delivery teams should be working closely with those who will run the change day-to-day. Bring them into the change from day 1 instead of a big bang update. Consider who will have the remit to change or iterate it and how operations will input.
Ensure suppliers work to value-based acceptance criteria (e.g. measurable improvement, user adoption), including capability uplift. Consider tying payment or contract extensions to success criteria beyond ‘shipped.’
Working with blockers
Of course there will be a natural immunity to change. You’re disrupting practices where familiarity and expertise has been built up, where roles are clear and remits habitual.
Of course it’s important to get the messaging right, but don’t rely on it. You’ll face all kinds of resistance:
Ops teams (understandably) won’t trust the hype of “transformation”
Architecture boards will freeze things “until it’s all agreed”
Procurement will demand fixed requirements for things you haven’t even learned yet
Business case keepers will ask how you can justify “funding a team with no delivery”
And that’s perfectly normal - disrupting predictability is a big deal. It’s not that people ‘don’t like change.’ It’s that we don’t like being changed.
But this is the work of transformation. You’re not just leading a programme. You’re leading a renegotiation of how work gets done, who gets to decide, and what value looks like, for a sustainable return on investment.
So resistance isn’t failure, it’s a sign of life and evidence that you’re on track to something different. Which (famously) is the only way to get different results.
Anticipate resistance and consider how to work with it. Speak to concerns, stay grounded in what needs doing and let people work to their strengths.
When enterprise architecture wants to blueprint the whole thing:
Invite them into early, cross-disciplinary bounded discovery work
Let them set guardrails, not dictate designs
Frame the work in service continuity terms and ask: what enables safe change in live environments?
When finance wants every deliverable priced up:
Translate funding into capabilities, not just assets
Show how stable teams reduce risk and rework
Use service metrics to justify spend (e.g. decision turnaround time, user trust, reduction in failure demand)
When legacy teams try to orbit the new team and pull authority back:
Anchor authority in service ownership
Make remit explicit: who decides, on what, for what purpose
Use governance to protect decision velocity and service integrity
Say what “transformation” looks like
You need to say clearly what “transformation” means. It’s meant to be a rallying cry, but most people are tired of it: it’s ambiguous, unspecific and implies change for change’s sake.
Say why it’s happening, what we’re doing about it and what value we assume it’s going to deliver for whom. Instead of saying “we’re modernising our casework system,” say:
“We’re making it easier for teams to track, share, and act on applications, so decisions can be made faster, with fewer handoffs and less duplication.”
You can’t track “modernisation,” but you can track speed, reduction in handoffs and duplication and you know what team can report that result.
Here are some commonly used phrases with more useful ways to talk about what your programme might actually be doing.
Set up the programme for a phased handover
By the end of your programme, you should be able to show:
A live service that works better than it did before
A stable team with decision rights and feedback loops
A supplier relationship that’s value-led, not contract-bound
A governance model that devolves, rather than hoards
And enough internal capability that if your programme ended next week, the service could still improve
Consider how ownership can be phased, instead of waiting for the cliff edge.
90% of the work may live ‘inside’ the programme at the start, with a target for a 50/50 split at a given point. The programme may still be the engine, but the capacity to keep it going is being created in parallel.
Work out what this means in your context. Track your capacity for ownership and improvement as you go, so it’s clear what’s realistically needed to make this happen. Does it require a new role to be in place by X time? Or for a change in existing remits? Or for a new set of relationships between existing teams?
Designing a programme to build what will eventually outgrow it takes more than good governance.
It takes restraint, trust, and the willingness to let go of control long before the outcomes are guaranteed
You’ll have to protect things that don’t look like progress yet
You’ll have to back people who are naming the real risks, not just managing the perceived ones
You’ll likely need to do it within structures that were never built to reward that kind of leadership
But it is possible. You can use a programme to deliver real value. Not just in outputs, but in how your organisation sees problems, makes decisions, and owns its services.
It doesn’t have to be overnight. But it can be on purpose, for the long term.