Two projects, the same three words.

The two axes everybody teaches

Contract type is taught along two lines, and both are taught well.

Contract Week 4 covers how the money works: lump sum, remeasurement, cost-plus, target cost. That decides who carries a quantity being wrong, and it decides what a variation is worth.

Contract Week 16 covers who did the design, which is what separates the Red, Yellow and Silver books, and with it who carries the risk of the design being inadequate.

Between them those two answer most questions about a single contract. They answer nothing at all about how many there are.

The third axis

Count the contracts the employer holds directly. Not subcontracts — those sit under somebody else's obligation and are their problem. Contracts where the employer is one of the two parties.

One is the case six tracks assumed. Everything below it is a subcontract, so every interface between packages sits inside a single contractor's obligation. If two trades clash, that is their problem to resolve, and the employer is entitled to a finished works regardless.

Four or five changes that completely. Each contractor owes the employer their own scope and owes the others nothing. The space between the packages belongs to whoever the employer put there to coordinate — and, as last week set out, that coordinator often has no contract with any of them.

The number isn't a detail of the procurement strategy. It is the thing that decides where the joins live.

What the employer is buying

Neither answer is better. They are a trade, and knowing which trade was made explains most of what follows.

One contract buys simplicity of recourse. There is a single party responsible for the whole, one programme to approve, one place to send a notice. The employer pays for that in price — the contractor is carrying the integration risk and has priced it — and in flexibility, because changing anything means changing one large contract.

Several contracts buy control and, usually, time. Packages can be let as the design for each is ready rather than waiting for all of it, specialists can be appointed directly, and the integration margin isn't paid to anybody. What the employer takes back in exchange is the integration risk itself, and that risk doesn't disappear because nobody priced it.

That last point is the one worth holding on to. On a single-contract job the risk of two packages not fitting together is inside a price. On a multi-contract job it is inside nobody's price, and it lands wherever it lands.

What changes for a planner

Four things, and they are the reason this isn't a procurement lesson.

The programme stops being one document. Each contractor produces their own to their own contract, at their own level of detail. Something has to hold them together, and on most forms that is a deliverable nobody owes.

Float belongs to somebody. Under one contract, float in the network is a shared resource the contractor manages. Across contracts it sits inside one party's programme and is consumed by another party's delay, with no clause governing the transfer.

Access becomes a supply. One contractor finishing late doesn't just delay themselves; it withholds the workface from the next. That is an obligation somebody owes, and on a multi-contract job it runs from the employer rather than from the contractor who caused the delay.

Completion stops being a date. With several contracts there are several completions, and the works aren't finished when the last one is done — they are finished when everything that had to be integrated has been.

The word doesn't tell you

Which brings this back to the two tender documents.

EPC describes what one contract contains: engineering, procurement and construction under one obligation. It says nothing about how many such contracts exist. Design-build says who designed it. Turnkey says what condition it is handed over in. All three are properties of a contract, and a project isn't a contract.

So the phrase in the tender isn't the answer to the question. The answer is a count, and the count appears in no document that describes the project. It has to be assembled by asking who the employer has signed with, which is why the contract map from last week is the first document on this track and not a formality.

System design

The contract map from week 1, extended with the four things the count decides. None of it needs a system; all of it needs to exist somewhere other than in one person’s head.

Record	Produced by	Required quality	Verified against	Feeds
Contract count	Project controls	Contracts the employer signed, not subcontracts	The employer’s register	Everything on this track
Interface list	Project controls with each party	One line per pair of contracts that touch	Drawings and scope documents	Risk register · constraint log
Who owes whom	Contracts	Stated per interface, including “neither”	The contracts themselves	Delay events · entitlement
Access obligations	Contracts	Which party owes a workface to which, and by when	Each contract’s access clause	Programme · look-ahead
Completion dates	Contracts	One per contract, plus the date integration finishes	Each contract’s completion clause	Milestones · LD exposure

The third row is the one that surprises people. On a multi-contract job the honest entry against an interface will often read that neither party owes the other anything, and the obligation runs through the employer. Writing that down isn't pessimism — it is the difference between chasing the right party in week two and the wrong one for a month.

Practical insight

Count them on your own project, from the employer's side rather than yours.

If the answer is one, the next fifteen weeks describe other people's jobs, and the useful thing you can take is knowing what your main contractor is absorbing on your behalf and what it is costing them.

If the answer is more than one, ask a second question about each interface between two of those contracts: which party owes the other anything at all? Where neither owes the other anything, the obligation runs through the employer or through nobody, and that is the answer more often than the site behaves as though it is. That list is the shape of the rest of this track, and it is specific to the job you are on.

Key takeaways

• Contract type answers how the money works and who designed it. Neither answers how many contracts exist.
• Count the contracts the employer holds directly. Subcontracts don't count; they sit inside somebody's obligation.
• One contract puts every interface inside a single obligation. Several put them between obligations.
• One contract buys simple recourse and pays for it in price and flexibility.
• Several buy control and time, and take back the integration risk, which nobody has priced.
• The programme stops being one document, float sits in somebody's network, access becomes an obligation, and completion becomes several dates.
• EPC, design-build and turnkey are properties of a contract. A project isn't a contract.
• The count is rarely written down. It has to be assembled from who the employer signed with.

Records born here. The contract count and its date · the interface list between every pair of contracts · the note of who owes whom at each one.

What is coming next

If the employer holds five contracts and none of the five owes the others anything, somebody still has to run the site. Whoever fills that role ends up with an uncomfortable property: authority over everybody and a contract with nobody.

Next week: instructing people you have no contract with.