Missions, not programmes: what a delivery engine looks like

There is a particular kind of failure that nobody writes a post-mortem about, because nothing went wrong.

A three-year programme is scoped carefully. The business case is thorough. Funding is agreed after two rounds of committee. Mobilisation takes four months. The first tangible thing a user can touch arrives fourteen months after the idea was approved — and by then the assumption it was built on has quietly expired. Nobody made a mistake. The process worked exactly as designed. That's the problem.

Missions, not programmes

The alternative is not to abandon long-term planning. There is a time and a place for a multi-year roadmap, and foundations genuinely take years. The alternative is to stop treating the roadmap as the delivery mechanism.

A delivery engine runs missions. A mission is a single, strategically grounded question with a target of a dramatically improved outcome in sixteen weeks. Not a phase, not a workstream — a question, with an owner, and a date.

McKinsey make the same argument in their digital factory model, and their test is a good one: if a mission can't deliver a meaningfully better outcome in around sixteen weeks, the mission is framed wrongly. Scope down until it can.

The missions we've run look like questions, because that's what they are. How do we onboard new staff with the fifty digital skills they need in their first three months? How do we get learning analytics to academics in real time? How do we mark exams digitally? Each is small enough to answer and large enough to matter.

The rules that make it safe

Speed without constraint is how organisations accumulate the mess they hired someone to clear up. So the model carries hard rules.

• Outcomes, not output. A mission is measured on whether something got better, not on what got shipped.
• No new technical debt. Every mission must use enabling technology that adds value beyond its own scope. A mission that leaves a mess behind hasn't succeeded.
• No get-out-of-jail-free card. The team works inside the same architecture governance, data protection and design authority as everyone else. Exemption is what makes innovation teams resented and their output unusable.
• Money follows proof. Budget is drawn incrementally at proof points rather than committed up front — which is what makes the finance director an ally rather than an obstacle.

Who actually does it

Here is the part the literature skips. McKinsey's Rewired runs to 386 pages; by our count, one of them deals with how you resource the initiatives a transformation office sets up. The talent bench — who is actually on the team, where they come from, what happens to their day job — is the single most common reason these models never get off the page.

The answer that works is a small permanent core, typically three people: someone leading the change, someone owning user-centred design, and a project manager. Everything else is temporary and borrowed. A mission team of eight to twelve, assembled for the duration, drawn from the business, the technology function, partners and — in the right settings — customers or students themselves. Cross-functional, self-organising, no internal hierarchy.

One role matters more than the others: a product owner acting as what McKinsey call a doer-in-chief. Not a manager. Someone who coaches weekly, pressure-tests the business case, and removes the things blocking the team. Get that appointment wrong and the model becomes a committee with a whiteboard.

The by-product is the point

McKinsey's research has repeatedly found that only a small minority of staff say their organisation's digital transformation both improved performance and equipped them to sustain the change. Sustaining it is the hard half, and it is the half that method decides.

What makes mission-based delivery worth the disruption isn't the sixteen-week cycle. It's that people who spend four months inside a cross-functional team solving a real problem come out able to do it again. The capability is a by-product of the method rather than a training programme bolted onto the end.

That is also why the model outlives the engagement. A roadmap is a document that someone has to keep updating. An engine is something the organisation runs.