Theme 4, Article 3: Designing Public Sector Programmes around Multiple Delivery Clocks

One of the more persistent assumptions in programme management is that time is a single dimension. A programme has a start date, an end date, and a schedule against which progress is measured. If delivery remains on plan, success follows.

Public sector transformation rarely works like that.

Instead, programmes operate against several independent clocks, each exerting its own influence over delivery. Financial years determine when money becomes available. Spending reviews can reshape future investment. Elections alter political priorities. Legislative timetables influence when change becomes possible. Procurement follows statutory processes rather than programme aspirations. Operational services often impose narrow windows within which change can be introduced safely. These clocks do not run at the same speed, nor do they naturally align.

The consequence is that programme teams regularly inherit constraints they neither created nor can control. A programme may be expected to complete before an election despite procurement timescales making that unrealistic. Funding may be approved one year at a time for work that requires sustained investment. Political direction may evolve halfway through delivery, requiring difficult decisions about scope, sequencing, or continued investment.

There is no methodology capable of eliminating these realities. Some decisions will not go the programme's way. Funding may reduce. Priorities may change. Delivery windows may close. The question is therefore becomes how to design a programme that remains viable when external conditions inevitably shift.

This is where programme design becomes critical. A well-constructed plan cannot compensate for a programme architecture that assumes external conditions will remain stable.

Viewed through this lens, this aspect of programme design is more about managing commitment over time. Every significant design decision either preserves future options or progressively removes them.

Understanding when, why and how those options narrow is central to designing programmes that can better withstand competing delivery clocks.

The first consideration is the point at which the programme commits itself to decisions that are difficult, expensive, or impossible to reverse. Every programme reaches points of no return, whether through contract award, technology selection, organisational restructuring, or operational cutover. The earlier these commitments are made, the fewer options remain if circumstances change. Whilst some irreversible decisions are unavoidable, others are simply made earlier than necessary. Preserving flexibility for as long as reasonably possible does not remove risk, but it can prevent the programme becoming locked into assumptions that are no longer valid.

A second consideration is whether the programme can be designed to support incremental delivery. This is frequently advocated as good practice, but it is not always achievable. Some transformations depend upon substantial enabling capability before meaningful operational change becomes possible. Others require multiple components to be delivered before any practical value can emerge. Attempting to force artificial increments into such programmes can increase complexity without reducing risk.

Where incremental delivery is feasible, it offers important advantages. It reduces the scale of individual implementation events, provides opportunities to learn before wider deployment, and allows future investment decisions to be informed by evidence rather than optimism.

Where it is not feasible, programme leaders should recognise that exposure accumulates throughout delivery. Each significant commitment narrows the available options until, eventually, the cost of reversal exceeds the cost of continuing. That point may be reached long before operational value has been fully realised. Good programme design therefore seeks not to eliminate exposure - which is impossible - but to understand how, when, and why that exposure progressively increases.

There is a further consideration that receives far less attention. Many transformational benefits mature slowly. Improved decision-making, cultural change, productivity gains, and service improvement often take months or years to become fully established. Yet programmes frequently conclude shortly after implementation, long before these benefits have had sufficient time to develop. Delivery may have finished, but value realisation has only just begun.

This creates an important design question. If programme funding, governance and accountability conclude at implementation, who remains responsible for nurturing the benefits that justified the investment in the first place? Unless operational ownership has been deliberately established, programmes risk delivering capability successfully whilst leaving value realisation largely to chance.

Programme architecture should also challenge unnecessary dependency. Over time, delivery plans often become increasingly interconnected, with each workstream dependent upon several others. Some of these dependencies are genuine. Others arise simply because activities have evolved together. The greater the interdependence, the more likely it becomes that a delay in one area propagates across the programme. Deliberately separating work wherever practical does not eliminate disruption, but it limits the extent to which disruption becomes systemic.

None of these approaches guarantees success. A change of government may still alter priorities. Funding may still be withdrawn. External events may still overtake carefully considered plans. Programme design cannot remove uncertainty, nor should it pretend otherwise.

What good design can do is reduce unnecessary exposure. It can preserve options for longer, avoid committing too early, recognise where incremental delivery is genuinely possible and where it is not, and ensure that responsibility for long-term value does not disappear the moment delivery concludes.

Public sector transformation will always operate against multiple delivery clocks. The objective is not to synchronise them; that is seldom within the programme's gift. The objective is to ensure that when those clocks inevitably drift apart, the programme has been designed to absorb such consequences as it can rather than simply become another a casualty of time.