Approved against a number you never see.

What the case has to carry before anybody signs

The construction management literature is consistent about the shape. A need is recognised. Where the need is commercial it gets defined as a market question — is there demand, at what size, over what horizon, and does the plant have to be there before a competitor is. Site, labour, energy and shipping get considered at the same time, because they change the answer.

Then three things are put in front of the decision maker: a cost and benefit analysis, a drawing crude enough to be honest about how little is known, and an estimate built on the little that is known.

That third item is the one that reaches you, eventually, as a budget. Cost & Cash Week 3 takes estimate classes apart properly. What matters here is that the estimate was never the point of the exercise — it was one input to a comparison, and the comparison was about whether to spend the money at all.

It is a decision about an asset, not about a job

The total cost management framework is precise about this and it is worth borrowing the distinction. Understanding a business problem is one activity. Deciding what to build about it is a different one, and its goal is to optimise a solution rather than to define a piece of work.

So the output isn't a scope. It is a case — variously called the business case, the investment decision basis, or the justification — recording what was compared, what was assumed, and why this option won.

Everything you will be measured on is downstream of that. The contract defines the work. The case defines why the work is worth doing, and those two documents can both be satisfied while pointing in different directions.

The practical consequence is a vocabulary problem that costs real time. When a client says the project must not slip, they may mean the contract date, or they may mean the date the case was built on, and those are different dates held by different people. Asking which one is meant sounds naive and is the single most useful question available in the first month.

The document that was supposed to stay alive

Here's the part that turns this from background into a failure.

The current project management standard treats the business case as something to be assessed continuously during delivery — financial performance measured against it, so the organisation can tell whether the project is still viable and still going to return what it promised. Not signed and filed. Re-tested.

Now ask who performs that test. It needs the case, which sits with the sponsor. It needs current cost and schedule truth, which sits with project controls. Where those two sit in different organisations — one the client's, one yours — they are never in the same room. The delivery team hasn't read the document it is supposed to be measured against.

So the test either isn't done, or it is done by somebody working from a monthly report that was built to answer a different question. Reporting Week 20 showed one number told at four altitudes. This is the altitude above all four, and the site rarely reaches it.

Who is already committed

The second thing sanction produces is obligations that aren't in your contract and that set your dates anyway.

Land was bought or a lease was signed, and it's being paid for whether or not anything is built on it. Consents were obtained, and consents carry conditions and expiry. Where the money is borrowed there is a lender with a drawdown schedule and covenants, and drawdown is tied to progress somebody else defines. Where the project ties into something already running there is an outage window, negotiated long ago with people who plan their year around it.

None of these appear in the contract. All of them are why the Time for Completion is the number it is.

And they explain something that otherwise reads as irrationality: a client refusing a two-week extension that costs them nothing on paper. It costs them nothing on paper because the paper is the contract, and the thing it collides with is an outage window that moves by a year if it is missed.

Why on time and on budget isn't the same as worth doing

Two endings make the point.

A project finishes inside its Time for Completion and inside its budget, and the market it was built for has moved. The case isn't returned. Nothing in the delivery record shows a failure, because by every measure the delivery team owns, there wasn't one.

A project finishes late, pays its delay damages, and returns the case comfortably, because the benefit ran for twenty years and the lateness cost weeks of it. The delivery record shows a failure. The investment doesn't.

Neither ending is an argument for indifference to dates. Both are an argument that the measures the delivery team optimises are a proxy, and a proxy that nobody has checked against the thing it stands for is a proxy that has drifted.

That's also why a client will sometimes pay to accelerate work that isn't late. Nothing in the programme justifies it and nothing needs to, because the justification is in a document the programme has never seen. Reading that as a client being difficult wastes the only signal you get about what the case actually requires.

System design

Four of these five are produced by people the delivery team never meets, which was true last week too and is the shape of the whole phase. The difference is the fourth row: benefit measures are the only record here that is written before the project and read after it.

Record	Produced by	Required quality	Verified against	Feeds
Business case / investment decision basis	The sponsor’s organisation, before appointment	Records what was compared and what was assumed, not only what was chosen	The studies it was built on	Whether the project is still worth finishing
Sanction or appropriation	The board or funding committee	Dated, with the amount and the target date it approved	The case it approved	The owner’s total · the gap before Commencement
Charter naming the sponsor	The owner, on authorising the work	One named person who can answer for the case	The sanction	Escalation · every question about intent
Benefit measures	The case, carried forward	Expressed so they can be measured after handover, not only forecast before it	Operation, once running	Whether the case was returned
External commitment register	Project controls, from asking	Each obligation with the date it imposes and who holds it	The document or party it came from	The real constraint behind the programme

The last row is the one worth building, because it can be built from questions rather than from access. Nobody has to release a board paper to tell you when an outage window opens.

Practical insight

You will probably not be given the business case. Ask for it anyway, once, and ask the client counterpart rather than anybody inside your own organisation. Asked plainly in your first month it reads as diligence. Asked in your ninth, when it is wanted for a claim, it reads as something else and the answer will be no.

When the answer is no, there's a proxy that costs one conversation. Ask what happens if handover slips by a month. Then ask what happens if it slips by six. The shape of the two answers is the information.

A cost per week both times means delay damages are the whole story and the case has room in it. A shrug at one month and something severe at six means a fixed external date sits behind your programme — an outage, a season, a consent that expires, a contract with somebody nobody on site has met. That date, not your Time for Completion, is the real constraint on your job, and you have found it without seeing a confidential document.

Write down whatever comes back, with the name of the person who said it and the day they said it. It's the closest thing to the case you will hold, and it explains client behaviour that would otherwise look arbitrary to you for the next two years.

Key takeaways

• Money is released against a return, not against a scope. The comparison was between this project and the others competing for the same funds.
• The case carries a cost and benefit analysis, a crude drawing, and an estimate built on very little — and the estimate was an input, not the point.
• The output of the decision is a case, not a scope: what was compared, what was assumed, and why this option won.
• The contract defines the work. The case defines why the work is worth doing, and both can be satisfied while pointing different ways.
• The business case is meant to be re-tested against financial performance during delivery, not signed and filed.
• That test needs the case and it needs current cost and schedule truth, and those two are rarely held by the same people.
• Sanction creates commitments outside your contract — land, consents and their expiry, lender drawdown, an outage window — and they set your dates.
• A client refusing a costless extension is colliding with one of those, and the contract has no field in which to say so.
• A project can finish inside time and budget and not return its case, and it can finish late and return it comfortably.
• Delivery measures are a proxy for the investment. A proxy nobody checks against the thing it stands for has drifted.

Records born here. The business case or investment decision basis · the sanction or appropriation and its date · the charter naming the sponsor · the benefit measures the case promised · the register of external commitments and the dates they impose.

What is coming next

The case rested on studies, and the studies rested on assumptions. Somebody assumed a ground condition, a grid connection, a delivery route, a labour rate. Some of those were tested and some were carried forward because testing them cost more than accepting them.

Every one of them is still in the project. A few of them will arrive on your desk years later disguised as facts, and one of them will be wrong. What comes next is where they were made, which of them get written down, and how to tell an assumption from a measurement when the document has stopped saying which is which.