Working as a Service When You're Stuck in Programme Delivery
A field guide for teams who want to deliver actual change
So you’re a leader or team trying to improve a real service for real people. Maybe you’re building the next version of a product, or replacing a legacy system, or doing some kind of discovery or analysis.
But you’re working in a ways that’s designed for programme delivery. It’s not about learning, value, or user needs. It’s unwieldy governance, up-front requirements, technology-led milestones and rigid deliverables. Organisational fiction, especially when it comes to software delivery.
If you’re close to the problem that needs solving, take heart! You can make it work anyway. Before we get going, there are two essential pre-requisites.
First: Accept what you can’t control
Let’s name the constraints:
You’re reporting to a programme board that wants milestone RAGs, not service outcomes.
Funding is tied to a business case, not a team remit.
You’re handed work as a solution (“build X”) instead of a problem (“solve Y”).
It’s not ideal. But it doesn’t mean you’re powerless.
Second: Work with what you’ve got
Here’s the irony:
If you’re in a major public sector programme, you might be most ‘nimble’ delivery there.
Programmes have goals, ownership, budget, remit, people and accountability. That’s more than ‘Business As Usual’ gets.
Problematic as it is, you can’t work with what you don’t have. So instead of focussing on the gaps, use the momentum.
People will need clarity as the works get more complicated with time - and you can meet that need.
Got that? Here we go!
1. Shift how you frame the work (even if the structures don’t)
Instead of...
“Delivering Phase 2 of the roadmap”
“Building the new casework tool”
“Meeting the programme milestone”
Try framing as...
“Solving the X problem for Y users”
“Enabling faster, fairer decisions across Z services”
“Reducing failure demand by fixing this specific drop-off point”
Unpack what we assume about the improvements, like “We believe X change will result in better quality data for faster, fairer decisions.” It will even help expose the actual scope and ‘definition of done’ for a given change.
Spoiler alert: reframing doesn’t change governance immediately. But it makes things tangible and changes how people talk, prioritise, and learn.
2. Find your allies
You’ll need relationships across:
Operations: They know where the real friction is. Include them early. Speak to their pain points and goals.
Policy: Don’t wait for sign-off. Bring them into the problem framing. Speak to policy intent in measurable ways.
Tech/architecture: If they’re treated as blockers, reframe them as enablers. Speak to what they do and for whom.
If you have a service map, use it to identify critical relationships beyond the org chart and usual ways of working. What team is in charge at that stage? Turn up to meetings where your framing can get backing and build advocacy.
Use “can we explore this together?” over “we need you to approve this.” Influence, not escalation, is your currency.
3. Show your work in service terms
Even if you’re asked for deliverables, show how these relate to service outcomes. Situate the work as service improvement:
Before/after user journeys
Time to complete a task (for staff or users)
Operational pain points resolved
Drop-offs, delays, or inconsistencies reduced
A service context can help group related changes, whether for a set of users, a point in the service journey or a critical task. This is about more ‘timeless’ stuff, like making good decisions about what people can or can’t do and the service meets its purpose.
Create a parallel story of value that’s grounded in the service outcome, not just spend and features.
4. Treat governance as a design constraint
Just like legacy tech or policy, you can’t remove it. But you can work around it.
Here are some examples:
⛰ Constraint: Rigid milestone tracking
🧗🏻 Workaround: Break your work into testable increments that happen to align with milestones
⛰ Constraint: Solution already defined
🧗🏻 Workaround: Revisit the problem with user - or any - evidence, to show how your approach better meets the intent
⛰ Constraint: Benefits defined ambiguously and upfront
🧗🏻 Workaround: Introduce new metrics linked to operations and service success to clarify existing ones
⛰ Constraint: Board only meets monthly
🧗🏻 Workaround: Set up a regular internal cadence for decisions, and feed aligned updates to the board
Speak clearly to what the rigid plan assumes and reframe it in learning terms. Get tangible evidence or data to back you up.
For a given milestone, say what we expect to be able to do by then and what we need to learn to do it. Show progress against that learning.
Name the intent and assumptions guiding the work. Then frame your plan and the work you will do in those terms.
5. Keep surfacing the gap between “done” and “works”
When the programme celebrates a milestone, ask:
Did the user outcome actually improve?
Are teams delivering more easily or reliably?
What’s actually different in real usage?
If not, say so.
Use show and tells, reviews or demos to show what’s working in practice (or not). Narrate the distance between what was delivered and what still isn’t usable.
Governance can only improve when it becomes visibly misaligned with value. Speak to value at every level, from scope to outcome, and make it unambiguous.
6. Talk about what comes after the programme
Most programmes believe they will magically vanish at “delivery.” Instead, they drag on and become monolithic structures with no one to “hand off” to.
Start planning for sustainability early:
Who owns this when you’re done?
What team will maintain and improve it?
What capability or handover is needed?
Tell the story of how this change could be owned and improved. Make fictional dashboards to provoke new ideas about sustainable ownership: who would look at them?
Argue that handover is a risk, not a milestone and use that to make the case for stable teams. Better yet, set goals for that risk and work out how to decrease them over time. At X or Y point in time, what is the service impact if the programme were to stop?
7. Finally: Work like a service team, even if you’re not called one
Frame your work in outcomes
Centre the user and frontline reality
Make decisions visible
Learn in small loops
Push ownership as close to delivery as you can
It’s all service improvement, whether it’s aimed at service or internal users. And it makes life easier for those all those who need to oversee, join up and do the work.
You don’t need permission to think in service terms. Start doing it. Others will follow.