A project can look ready long before it is.
A business case that closes, a budget, a programme, drawings advanced enough to reassure. The scheme reads well, the numbers reconcile, and it moves forward. But reading well is not the same as being ready. A project can carry every sign of readiness and still be months of work away from something a contractor could price with confidence, or a team could start to build.
The gap between the two is where cost and time quietly accumulate, not in dramatic failures, but in the interval between a decision to proceed and the discovery of everything that decision assumed. A project that reads well on paper is a document. A project that is ready to build is a state: one where the things that will govern its cost, its programme and its outcome have been tested rather than asserted, and where the question of whether it is worth doing has been answered as carefully as the question of whether it can be.
That second question is the one most readiness reviews skip.
Two kinds of ready
There are two kinds of readiness, and they are easy to confuse because a project needs both.
Delivery-readiness asks whether the project can be built: to a defined scope, within a credible programme, at a cost that holds, with risk in the right hands. Its horizon is bounded: it runs from now to handover, and then it closes.
Value-readiness asks the longer question: whether the project is worth doing at all. That question opens at the very outset, before the scope is drawn, before the business case is written, and it never fully closes, because value is what the asset goes on to deliver across decades of use. Nor is value only a matter of money: it is economic, but also social and environmental, at times political, and above all it is how the result is judged by the people who use it, operate it, and live alongside it.
Most of the effort in a readiness review goes to the first. The second is where the larger outcome is decided, because value is settled at the very front end, earlier than scope or cost, and it grows more expensive to change with every month that passes. By the time delivery is running, the value is largely fixed: the project is executing decisions, not making them. Readiness, properly understood, is a value question before it is a programme question.
Success follows from this. A project delivered on time, on budget and to scope has met the parameters of delivery. Whether it has succeeded is a different test: did it deliver the value it was justified by. The two can come apart, and when they do, it is rarely the schedule that gets remembered.
A project’s success, then, is a verdict on value, both whether it was worth doing and how much of that value it delivered, not on delivery performance alone.
What follows is a small set of checks that separate a project that reads well from one that is ready. The first two concern value; the remaining four, delivery. A project holds only when it holds on both.
They are simple to state, and none is simple to satisfy. Each is a doorway into a body of evidence — technical and commercial — that differs from one project to the next. A clean answer to any of them is not a confident assertion or a green status. It is one that has been tested, that is supported by evidence, and that is honest about what it still cannot say.
01 · ValueWhether it’s worth building
Before anything is measured, one thing should be settled: what success means for this project, expressed as the value it exists to create. Not the output (the building, the units, the piece of infrastructure) but the change that output is meant to produce, and for whom.
This sounds obvious and is routinely absent. Business cases state a cost and a timeframe and describe an asset; far fewer state, in terms that could later be checked, what the asset is supposed to achieve and how anyone would know it had. A school is not delivered to add classrooms; it is delivered so that a community can teach and learn well in them. Those are different specifications, and only one of them survives contact with the people who will use the building.
The test is whether the definition could later be proved wrong. If there is a result that would count as failure, named now, in the language of value, and agreed by the people who will live with the outcome, then success has been defined. If there is not, it has only been assumed.
02 · ValueHow you’d know it worked
A definition of value is only useful if it can be seen. The second check is whether the project carries concrete, owned and tracked measures that would tell you whether the value is being delivered, during the work and after it.
This is not the same as reporting. Most projects report diligently on time and cost, because those are easy to count. Value measures are harder: they concern outcomes that arrive slowly, sometimes years after the ribbon is cut, and they require someone to still be watching once the project team has moved on. A development can be handed over on programme and reveal only two winters later that it costs a fortune to run and heat. A measure named at the outset and tracked into operation would have caught it. A status report never would.
So the tell is simple: a year after handover, could anyone still say whether the value arrived, and is anyone tasked to find out? A handful of measures, each with an owner and a means of collection that outlasts the project team, is what separates value delivered from value assumed.
Set the two side by side and a simple picture emerges. A project can be strong on value and weak on delivery: a good idea not yet ready. It can be strong on delivery and weak on value: the buildable wrong thing, delivered well. Delivery-ready, in the full sense, is the corner where both hold. The four checks that follow are the delivery axis.
03 · DeliveryScope you can price, not just picture
Scope is where readiness is most often overstated. A scheme can be described in convincing detail, with massing and intent and a narrative of what it will be, and still not be defined to a level anyone could price or sequence. Description is not definition.
This is also where the delivery approach belongs. Not every project should be procured as though its scope were fixed. Where the work is genuinely uncertain, whether early-stage or dependent on things not yet known, a delivery model that assumes certainty will bake in a fiction, and the fiction surfaces later as a variation. Readiness here means an approach chosen deliberately to match how much is actually settled, rather than defaulted to because it is familiar.
The move is to test the scope before the market does. Give it to someone who must price it and ask for a number they would stand behind; give it to whoever must sequence it and ask them to order the work without guessing. Where either has to guess, the scope is still a picture, not a specification, and the guess comes back later as a variation.
04 · DeliveryA programme that’s met reality
A programme is not a bar chart. A bar chart assumes everything arrives when the plan says it will; a programme has been tested against the things that decide whether it does. Consents and approvals, long-lead items, the availability of the people and trades to do the work, and the dependencies between packages where one team cannot start until another finishes: these are the constraints a real programme is built around.
Consents deserve particular attention, because they are the constraint most often assumed rather than mapped. A programme that shows a consent granted on a tidy date, with no allowance for the pathway to reach it or the chance it returns with conditions, is not a programme. It is a hope with dates on it.
Ask the programme where it would break. Take the three dates most likely to slip (a consent, a long-lead order, a trade that cannot start until another finishes) and move each to when it might realistically land. Watch what absorbs the movement. If completion moves, the exposure is visible. If it holds, the programme should show the float, resequencing or mitigation that protects it. If neither is visible, it was drawn to a deadline and coloured in.
05 · DeliveryRisk sitting where it can be carried
Every project carries risk. The question readiness asks is not whether risk exists but where it sits, and whether it sits with the party best able to control and absorb it at an acceptable cost. Risk that has been identified but left unallocated has not been managed; it has simply not yet found the person who will end up holding it, usually at the worst moment and the highest price.
Read the risk against the contract, not the register. Take each significant risk and look for the clause that places it; where the register names an owner but the contract is silent, the risk is still unallocated, whatever the register says. A project is ready on this count when, for every risk that matters, there is a plain answer to who carries it and where the contract says so, settled before signing, not discovered later in the gap between what one side assumed and the other agreed.
06 · DeliveryDecisions with a name and a date
Projects are sunk more often by decisions that came late, or never came at all, than by decisions that were wrong. A project depends on a stream of choices, some foreseeable, some not, and each one that waits holds up the work behind it. Late decisions compound: the cost is rarely the decision itself, but everything that stalled while it was pending.
The readiness test here is literal. List the decisions the project depends on before it starts, and against each name who is empowered to make it (a person, or a body such as a board, an investment committee or a statutory authority), and the date by which it must be made. The owner need not be a single person; it does need to be assigned rather than assumed, and where the decision sits with a board or an approval authority, the route to it must be mapped and timed like anything else on the programme. A decision without a name waits for a meeting; a decision without a date waits for a crisis. A project that can produce that list moves, because the authority to decide has been placed and someone is accountable for keeping it moving. A project that cannot drifts on momentum until the momentum runs out.
Necessary, and not sufficient
Answer all six well and a project has cleared the questions that come first. That is worth having. It is not the whole of readiness.
A full readiness or gate review asks a great deal more: cost confidence and funding, technical maturity, site and consenting constraints, operational transition, contingency. The six do not stand in for that work, and they do not sit beneath it. They sit above it: they are the questions all of that evidence has to satisfy. A project that cannot answer them will not survive the detailed checks either, only later, and at greater cost.
And readiness to build is necessary, not sufficient, because a project can clear every delivery check and still disappoint the people it was built for. The school delivered on time whose rooms turn out not to suit the way teaching now works. The development handed over on budget that the community never wanted and cannot afford to run. The terminal that met every milestone and moves badly for the people walking through it. None of these is a delivery failure. Each is a value failure, and each was decided long before delivery began, which is exactly why the two value checks come first.
A project that is ready in the full sense has answered both questions: it can be built, and it is worth building. That is what an investment decision weighs: the two together, not in turn. A valuable outcome can still be pursued through the wrong intervention, or a disproportionately expensive one: whether the benefit justifies the spend is a question of value, and whether the money is secured and will arrive when the programme needs it is a question of delivery. A project should not pass the gate because the delivery team can show a credible cost and programme; it must also show that the intervention it commits to is still the best response to the need behind it. The six checks tell the two apart; the discipline is in refusing to treat the first as though it had settled the second.
Six questions, in order
If a scheme in front of you reads well, these are the questions to put to it first.
- Is success defined as the value the project exists to create, specifically enough to be wrong?
- Are there measures that would tell you whether that value is being delivered, owned and tracked into operation?
- Is the scope defined to a level that could be priced and sequenced, with a delivery approach that fits its real certainty?
- Has the programme been tested against consents, long-lead items and dependencies, and does it still hold?
- Do the significant risks sit with the party who can carry them, made real in the contract before it is signed?
- Are the decisions the project depends on anticipated, owned, and time-bound?
Answer all six cleanly and a project is worth taking forward: worth doing, and able to be built. The point of the six is not to pass them once, but to ask them early, while the answers can still shape the project rather than only explain how it went. They stay simple questions. What stands behind each of them does not.
Establishing that a project can answer these questions, before it is committed, is the work of the diagnose phase. It is where we usually start. See how we work →
A typeset edition on our letterhead, with the six checks set out as a one-page checklist to carry into a meeting.
This article is general commentary and reflects the view of the author. It is not advice for any specific project, and no project should be assessed on it alone; each turns on its own facts.