10 Foundations for Change Delivery: Deciding the Rules of the Game

In our recent blog, Delivery Certainty is Designed in, Not Hoped For, we argued that successful change does not happen because a programme is important, well-intentioned or full of capable people.

Certainty has to be designed in.

That starts with clarity: what needs to be delivered, why it matters, who owns what, how decisions will be made, where the risks sit, and what happens when reality challenges the plan. One practical way to create that clarity is to agree the rules of the game before delivery pressure builds.

Not bureaucratic rules. Not another layer of methodology. And not a replacement for formal project management principles. At deploy12, we already adopt recognised project management principles informed by PMI/PMBOK good practice. Those provide the professional discipline for how projects and programmes should be managed.

The foundations below are different.

They are practical alignment points for a specific change initiative. Once agreed, they provide guide rails for decisions and reduce the risk of sponsors, delivery teams, suppliers and stakeholders quietly working to different versions of success – because that is where complexity often starts: not in the plan itself, but in the gaps between assumptions.

You have probably experienced instances where one stakeholder is protecting speed, but another is protecting scope, or where the business assumes process change is included, but Technology assumes it is not. When this occurs, it’s likely that governance can see the problem, but nobody is clear who has the right to make the call.

By the time those differences surface, the programme is already paying for the ambiguity.

These 10 foundations are designed to reduce that risk.

They should be considered, challenged and agreed during set-up, then used actively in kick-offs, onboarding, steering groups, sprint reviews and decision forums.

The test is simple: when a trade-off appears, can the programme point back to its agreed foundations and make a clear decision?

If it can, delivery becomes cleaner, faster and more controlled. If it cannot, the programme spends too much time renegotiating reality under pressure.

So here is our working list — not exhaustive, but deliberately practical.

1. Buy or build — decide once, early 
Most organisations are buying, configuring and integrating, not building from scratch. State that clearly from the start. Otherwise, programmes drift into accidental hybrids: bought platforms, heavy customisation and bespoke workarounds that increase cost, complexity and risk without anyone consciously choosing that path.

2. Adopt the package, or adapt the package 
COTS platforms usually come with embedded processes, controls and design assumptions. Agree early whether the business will adapt to the package’s standard ways of working, or whether the package will be customised to fit existing processes. Both choices have consequences for cost, complexity, adoption and future upgrade paths.

3. Integration before optimisation 
Be clear whether the programme is integrating a new solution into the current operating model or also redesigning processes, merging functions and changing how work gets done. Either route can be valid, but they are different programmes. Confusing the two creates avoidable scope, cost and delivery risk.

4. Everything is owned by somebody, always 
Every action, risk, decision, dependency, deliverable and outcome needs a named accountable owner. Not a forum, function or vague team label. A specific person/ role. Ownership does not mean doing everything personally; it means being accountable for making sure the work moves and decisions happen.

5. One accountable sponsor, one decision path 
Complex change needs clear sponsorship, not multiple routes to a decision. There can be many interested leaders, but there should be one accountable sponsor, clear decision rights and a timeboxed escalation path. Without that, difficult decisions move sideways and delivery teams are left waiting.

6. Outcomes first, outputs second 
Deliverables matter, but they are not the point. The programme should first define the outcomes it exists to achieve: customer, risk, cost, control, compliance, colleague or operational outcomes. Outputs are only valuable if they move the organisation closer to those agreed outcomes.

7. Make trade-offs explicit 
Every programme eventually faces pressure across scope, time, cost, quality and risk. Agree early what must be protected, what can flex and who has authority to decide. That does not remove difficult decisions, but it makes them faster, cleaner and more transparent when pressure builds.

8. One version of the truth 
Delivery confidence depends on shared reality. There should be one plan, one set of numbers, one risk view, one dependency picture and one agreed narrative for governance. If different teams carry different truths, meetings become debates about reality rather than decisions about delivery.

9. A Doable Plan beats an optimistic plan 
Optimistic plans are easy to create. A Doable Plan reflects the actual capacity, capability, sequencing, dependencies and constraints the programme must work within. It should still be ambitious, but it must be credible enough for people to believe in, govern against and deliver.

10. Minimum viable governance, maximum decision velocity 
Good governance is not more meetings, heavier packs or extra approval layers. It is about making the truth visible and enabling decisions quickly enough to keep delivery moving. Governance should be lean, honest and decision-focused, creating control without slowing the programme down.

The leadership choice

Change programmes rarely fail because people did not work hard enough.

They fail because risk was allowed to build in the gaps: unclear ownership, competing priorities, untested assumptions, slow decisions, weak adoption planning and governance that observed problems rather than unlocked them.

Those gaps are expensive.

They create delay, rework, supplier friction, missed benefits and avoidable pressure on the people trying to deliver. By the time they become visible at steering committee or ExCo level, the programme is often already paying for decisions that should have been made much earlier.

That is why these 10 foundations matter.

They are not deploy12’s formal project management principles. They are not a methodology, and they are not another governance framework.

They are a practical way of reducing delivery risk before it becomes delivery failure.

Used well, they align sponsors, delivery teams, business stakeholders and external partners around the decisions that matter most: outcomes, ownership, trade-offs, adoption, governance and truth.

They will not remove complexity. but they will make the risks clearer, the decisions faster and the route to delivery more controlled.

For senior leaders, that is the real choice.

Leave the assumptions to surface under pressure, or design the certainty in from the start.

If your programme needs more than optimism, let’s talk.