The leverage peaked before you arrived.

What a gate is actually deciding

A gate isn't a decision to build. It is a decision to spend the next tranche of study money, and it has four possible outcomes rather than two.

The deliverable passes. Or it is returned for correction. Or the project is killed. Or it is recycled — sent back for further definition, further feasibility work, further elaboration of what was being asked for in the first place.

Those last two are the ones that shape what reaches you, and neither leaves a mark on anything you will be shown. A killed project produces no contract. A recycled one produces the same contract, later, with the delay absorbed into a start date nobody explains.

The deliverable list, and why the class is a consequence

Each gate carries a list of what has to exist before it can be passed, and the lists are cumulative. Early on it is performance objectives and an assessment of the technology options. Then conceptual and basic engineering, feasibility studies, a milestone schedule, and the first identification of long-lead items. By the last gate it is front-end engineering design proper — process and instrumentation diagrams, data sheets — a scope of work, a resource-loaded schedule.

An estimate sits on every one of those lists, and its accuracy tightens as the gates pass. Wide at the start; by the final gate a definite estimate in the region of ten percent.

Cost & Cash Week 3 takes apart what a class is a statement about, and the answer there is the one that matters: it is a statement about how well the scope is defined, not about how much work the estimator did. What this week adds is where the definition came from. The class isn't chosen. It is a consequence of which items on that list actually exist, and the list was completed by people who finished their work and left.

Both curves cross, and you arrive after the crossing

Draw influence falling and the cost of change rising, and they cross somewhere in detailed design. Every project controls function in this industry operates entirely to the right of that crossing.

This explains something that otherwise looks like organisational stupidity. A team of six people, working for months, produces a number and a layout. A team of six hundred then spends years and a great deal of money delivering against them, and has almost no ability to change the parts that matter most.

It isn't stupidity. It is the correct shape, given that somebody has to decide before everything is known. What goes wrong isn't the shape but the silence about it: nothing in the process tells the second team which of its inherited constraints were tested and which were adopted, which is last week's problem arriving in a different costume.

The ratchet

A passed gate isn't formally frozen. In practice it functions as though it were, because reopening one means reopening everything downstream of it and re-running the approval that released the money.

So the gates behave as a ratchet. Each one narrows what is still open and none of them widens it. By award, the questions that remain are questions about how, and the questions about whether and which were closed years before, in rooms that produced a paragraph of minutes.

Which is why a good technical objection raised during construction can go nowhere while being entirely right. The objection is to a decision three gates upstream, and no mechanism reaches back that far. Understanding this early saves a great deal of energy, and it redirects it towards the objections that can still land.

Recycle, and the float nobody attributes

Recycling has a cost and the cost is time, drawn from the same total week 2 described — the owner's bar, running from sanction to a target date that didn't move because a gate sent something back.

The front end's own justification is that time spent early is repaid later, and the literature is explicit that the additions are small against the cost of changing things afterwards. That holds when the front end runs to plan. When it recycles twice, the study phase has consumed the very float it existed to protect, and the compression lands on the phase that has the least ability to absorb it, which is yours.

Nothing in the tender documents records this. The Time for Completion arrives as a requirement, and where it came from isn't a field in any document you will be given.

What actually reaches your desk

A budget, without the range that was attached to it at the gate that produced it.

That is the whole inheritance, and it is why a variance can open in month three that nobody on the job caused. The estimate was competent for the definition available. The definition then improved, as it was always going to, and the improvement moved the number. What is being reported as a performance variance is in part the resolution of an uncertainty that was declared and then discarded on the way down.

The difference between a team that can say that and a team that can't is one sentence in a handover document, and the sentence costs nothing to write at the time.

System design

The third row is the one this week turns on, and the required quality is a single discipline: the accuracy travels in the same document as the number. Split them across two documents and the range is lost at the first copy, because the number is the part people need and the range is the part they summarise away.

Record	Produced by	Required quality	Verified against	Feeds
Gate deliverable list	The owner’s governance process	States what had to exist, so a gap is visible as a gap	The stage it closes	What the next stage may assume
Gate decision	The approving authority	Records which of the four outcomes it was, and the date	The deliverables submitted	The owner’s elapsed time · the start date
Estimate and its class	Cost engineering, at each gate	The accuracy travels with the number, in the same document	The scope definition behind it	Sanction · the budget · every later variance
Scope of work at the final gate	Front-end engineering	Distinguishes what is fixed from what is still to be developed	The design that supports it	Tender documents · the contract
Long-lead identification	The same stage, earlier than feels natural	Named items with the lead time that drove the naming	Market enquiry, not assumption	Procurement sequence · the programme

The second row is the cheapest and the rarest. Recording which of the four outcomes a gate produced costs a word, and it is the only record that explains why the elapsed time between sanction and award is what it is.

Practical insight

Find out which gate your budget came from, and write the answer where your successor will find it.

There is one thing to look for: the last estimate produced before the tender, and the accuracy stated on it. Ask the client counterpart which estimate class the sanction was approved against. It is a normal question, it is answerable, and the answer is the single most useful number about your job that isn't in the contract.

If it came from a definite estimate at the final gate, the scope behind your budget is solid and a variance in month three is a real signal. If it came from a class two gates earlier — and it does happen, where a client tenders early to hold a market position — then part of what you will report as variance is definition arriving, and you need to say so in your first month rather than your ninth.

Write it in the front of the cost report as one line: the estimate this budget derives from, and the accuracy it carried. It will still be true in three years, and by then everybody who knew it will have gone.

Key takeaways

• The front end rests on one premise: influence over design is high early and the cost of change is low, and both invert later.
• The decisions with most leverage were taken by the fewest people with the least information, and that is the structure working, not failing.
• A gate decides whether to release the next tranche of study money, not whether to build.
• It has four outcomes — pass, correct, kill, recycle — and two of them leave no mark on anything the delivery team is shown.
• Each gate carries a cumulative deliverable list, and the estimate class is a consequence of which items exist rather than a choice anybody made.
• Every project controls function operates to the right of the crossing point, where influence is low and the cost of change is high.
• Gates behave as a ratchet: each narrows what is open and none widens it, so an objection three gates upstream has no mechanism to reach.
• A recycled gate consumes owner float against a target date that didn't move, and the compression lands on delivery.
• The budget arrives without the range that was attached to it, so resolving uncertainty later reads as a performance variance.
• The estimate class behind your budget is answerable by one question and is the most useful number about the job that isn't in the contract.

Records born here. The gate deliverable list · the gate decision and which of the four outcomes it was · the estimate and the accuracy stated on it · the scope of work fixed at the final gate · the first identification of long-lead items · the resource-loaded schedule the sanction rested on.

What is coming next

The final gate produced a scope of work and a schedule. It didn't produce a way of buying any of it.

Somebody still had to decide whether one contractor takes the whole thing or six take a piece each, whether the design is finished before anybody prices it, and who carries the ground, the interfaces and the currency. Those choices set what your contract can and can't ask for, and they were made in a paper you will never read by people optimising for something that wasn't your delivery.