Method

Most programmes run a technical track and, somewhere downstream of it, a workstream for people. I run them as one track from day one. The second one is not a workstream. It is the part that decides whether any of the first one survives contact with the organisation.

The five moves below are not proprietary and I make no claim that they are novel. They are the moves that get skipped, or done once at kickoff and never again. Doing them properly, in order, for the whole length of a programme is the entire difference.

Map

Who owns what, formally and actually. Where confidence has already been spent, and by whom. Which previous attempts still cast shadows, and how long those shadows are.

Most programmes skip this because the org chart is sitting right there and looks like an answer. It is not. An org chart tells you who may be accountable. It does not tell you who is listened to, which director quietly withheld support from the last attempt, or which team has been reorganised three times in five years and has learned that waiting is cheaper than engaging. Those facts decide the outcome, and none of them are written down.

Nothing gets sequenced until the map exists.

Frame

Every capability traces to a number the business already measures — adoption, cycle time, cost-to-serve, revenue enabled. Business cases, not architecture diagrams.

This is partly honesty and partly survival. A programme framed in architectural terms cannot defend itself in month nine, when the budget conversation arrives and the only evidence available is that the architecture is progressing. A programme framed in the business’s own numbers can.

If a capability cannot be traced to a result, that is not a framing failure. It is a signal that the capability may not be worth building, and it is considerably cheaper to discover that now.

Move

Every organisation already contains people pulling in the right direction, usually without a mandate and often without much recognition. I find them, give them a visible role, and let their results create the pull that mandates never do. Evidence moves people. Announcements do not.

The harder half is the middle. The managers who run today’s systems hear “your way is wrong” in every new platform, and they are not being paranoid — frequently that is precisely what is being said. The reframe is simple and it is true: they are the domain experts the new system depends on. The question shifts from “what is being done to my team?” to “what do I need this system to do?” A blocker becomes a source of requirements.

This part is slow, and it is the work. It cannot be done from a steering committee.

Build

Two things get built: the capability, and the shared language it needs in order to survive.

The language matters more than it sounds. The business stops asking why IT is so slow. IT stops asking what the business actually wants. Both sides get a common set of measures they can look at together and see — for the first time, in many organisations — whether the thing is working.

The capability is teams that own their domains end to end, with the authority to decide and the funding to act. Standing those up is the point at which the programme stops needing me.

Leave

The intended outcome of every engagement is an organisation that no longer needs me. The capability should end up inside your organisation, not mine.

So the handover is designed at the start rather than improvised at the end: named owners for each domain, the operating rhythm running without me in the room, and a deliberate period where I am present but not driving. If I am still essential to the challenge you first brought me in for, the engagement has failed on its own terms, whatever the programme dashboard says.

Being asked to take on a different problem is a separate matter entirely. That is the work having succeeded, not the work continuing.

The diagnostic sprint

Two kinds of client arrive at the same engagement. One is about to commit serious budget and wants to know what they are walking into. The other committed months ago and the programme has stopped moving. It is one piece of work in both cases — Map and Frame, run at pace — and the difference is only where you are standing when you call.

If you are calling about a stalled programme, one thing is worth saying plainly before anything else. Thirty days is the length of the engagement. It is not a claim about the length of the repair. A programme that took many months to stall does not come right in a month, and anyone who tells you otherwise is selling the same optimism that put you here.

What thirty days is enough for is finding out what is actually wrong, and agreeing what to do about it on evidence solid enough to survive the next steering committee.

• Days 1 to 10 — Map. Interviews across the leadership team and a deliberate layer below it, where the unfiltered version tends to live. Who owns what formally, who is actually listened to, where confidence has already been spent, and which previous attempt still casts a shadow over this one.
• Days 11 to 20 — Diagnose. Separate the technical blockers from the organisational ones and say plainly which is binding. In my experience it is rarely the technology, but the point of the sprint is to establish that for your programme rather than assert it from mine.
• Days 21 to 30 — Re-sequence. A revised plan with the people track and the technical track on one line, named owners against each domain, and the first moves chosen because they are visible and achievable rather than because they are next in the plan.

You leave the sprint with a written diagnosis naming the binding constraint, a re-sequenced plan your team can run, and a go / no-go recommendation — including, where that is the honest answer, a recommendation to stop. The blueprint is yours whether or not you continue with me.

It is deliberately short and deliberately bounded. If the conclusion is that you do not need me after it, the sprint did its job.

What it costs

Fixed fee where the scope is bounded. Hourly for the embed.

The diagnostic sprint (up to 30 days) has edges, so it carries a price. Go / no-go gates sit between stages, so you are never committed past the evidence, and you keep the blueprint whether or not you continue.

The embedded advisory (six to eighteen months) is hourly, because open-ended work sold as a package is either padded or an argument about change requests. Two to four days a week, scaling with programme phase, plus specialists from my network where the work needs them.