“We’re ready.”
I have heard those two words from boards on the brink of more major programme failures than I can count. They are said in good faith. The board genuinely believes them. And they almost always precede a programme that costs more, takes longer, and exposes the organisation to more risk than anyone in the room expected on the day of the decision.
This is a book about what should come before “we’re ready” — and what should come instead.
I have spent thirty years delivering major programmes and, more often, recovering them after they have gone wrong. Power generation, transmission, regulated utilities, public infrastructure, large-scale industrial work. Different sectors; the same handful of underlying problems. By the time a programme has slipped from successful into trouble, the immediate cause looks technical — a delayed contractor, a scope dispute, a budget overrun, a risk that became an issue no one had a plan for. Trace it back, and the root cause almost always lies in choices the organisation made before the programme even started: how it judged its own readiness, how it chose its delivery model, how it set itself up to govern the work. The technical failure is the symptom. The set-up was the disease.
That is what this book is about. The choices an organisation makes before a major programme begins — and the methodology that lets those choices be made deliberately rather than by drift.
Who this is for
This book is written for anyone in an owner organisation — a body that commissions major capital programmes rather than delivering them on contract — who is about to commit, or has just committed, to a programme they have not delivered before at that scale. Boards. Sponsors. Programme directors who have just been handed the role. Finance directors signing off the business case. Non-executives wondering whether the assurance they have been given actually means anything.
It is also for the professional advisers who sit alongside those people — consultants, lawyers, accountants — who have to give counsel on programme readiness without necessarily having spent their careers delivering programmes themselves.
It is not written primarily for delivery professionals. Project managers, PMO leads, programme controls specialists — there are excellent technical handbooks for that audience already. This book sits one level up: it is about how the organisation prepares to be the customer of major programme delivery, not how the delivery itself is done.
I have written it in the voice I would use in a meeting room. Direct, specific, willing to disagree with the room when the room is wrong, and with the calluses of a lot of actual experience visible in the language. If you are looking for a textbook, this isn’t one. If you are looking for the methodology I would actually use if you hired me — that’s what is here.
The shape of the methodology
The Owner’s Team Methodology has five stages. They form a cycle, not a straight line.
Diagnose. Before any decision about who delivers the programme, you need an honest picture of where the organisation stands today. Not the board’s self-assessment. An independent, evidence-based diagnosis of capability, intent, and risk across five domains. This is Chapter 1.
Decide. Once you can see your readiness honestly, you make the Build / Buy / Hybrid decision — does the organisation build its delivery capability internally, buy it from the market, or combine the two? This is the choice everyone wants to skip to first. It is also the one that is wrong far more often than people realise. Chapter 2.
Design. A decision is not a model. Between deciding to “go hybrid” and being able to actually mobilise a hybrid programme sits a Design stage — the operating model, the role specifications, the contractual architecture, the governance design — all written down, controlled, and approved before anyone is hired or any contract is signed. Chapter 3.
Mobilise. The first 180 days. The period in which the function moves from designed-on-paper to operating-in-fact. The behaviours and habits established here become the function’s character for years afterwards. Chapter 4.
Sustain. What happens after the function is operating, for as long as it exists. Capability maintenance, scheduled reassessment, function evolution, and the discipline that prevents a function established in year one from quietly drifting into something else by year five. Chapter 5.
The cycle closes when Sustain feeds back into Diagnose — when conditions change enough, or time has passed enough, to merit a fresh look at where the organisation stands. The methodology assumes the function exists not just to deliver one programme but to keep the organisation capable of delivering the next one, and the one after that.
How to read this book
It is short. Deliberately. There are longer methodology documents in existence, including the ones from which this book is drawn, and I have written some of them. This is the executive version — a couple of hours’ read, designed to fit between meetings, giving you the methodology in full but not in exhaustive detail.
You can read it linearly, cover to cover. That is how I would recommend it if the methodology is new to you. The chapters build on each other and the bridges between them carry the argument forward.
You can also read it by jumping in at the chapter that matches where you are. If you are mid-procurement and trying to remember what an intelligent client function actually requires — skip to Chapter 3. If you have just inherited a struggling programme that someone else mobilised — read Chapter 4 and ask yourself which of the failure modes apply.
Each chapter ends with what I think of as the practitioner’s note — the single thing that, in my experience, is most consistently underestimated at that stage. Read those if nothing else.
A note on what is missing
I have written this for owner organisations facing major programmes — call it £50m and upwards, sometimes much larger. Most of what I say applies above that threshold. Some of it applies below it. I have not tried to write a universal book about all project work at all scales. The reader’s judgement on what scales and what doesn’t is necessary.
I have also kept the worked examples deliberately anonymous. The patterns I describe are real and recurring, but the specific organisations are not named. Anyone who has worked in this industry will recognise the patterns; no one should try to identify the cases.
Last — and this matters: nothing in this book is a substitute for an independent diagnostic of your own organisation. The whole point of the methodology is that self-assessment is unreliable. If, after reading this book, you find yourself thinking “we don’t have these problems” — that is, in my experience, the strongest possible indication that you should ask someone independent to check.
Let’s begin.