Your day one is their year three

Somebody in a progress meeting asks how long the project has been running.

The planner says fourteen months, counting from the date the Engineer told them to start. The client's project manager says four years, counting from the board paper. The design consultant, who has been in the room the whole time, says three, counting from the day their firm decided to bid for the design.

All three are right, and none of them is talking about the same thing. This isn't a misunderstanding that gets cleared up. It is a structural feature of how projects are bought, and it decides which numbers you will be asked to explain later.

Three parties, three first days

The PMI construction extension puts this plainly by drawing the same project three times, once per party. From the owner's position the life cycle opens when they formally decide to undertake the work. From the designer's, it opens when they decide to submit a proposal. From the contractor's, it opens when they decide to bid — and moves into design, procurement or construction only if the contract is awarded.

Read that last clause again, because it is the one that matters. For the contractor the project is conditional until award. Everything before it is pursuit cost, and pursuit is a different activity from delivery with different records, different people and a different definition of success.

So the delivery team doesn't join a project late. It joins a different project, which happens to share a site and a name with the one the owner has been running.

ONE PROJECT, THREE OPENING DATESOwnerboard decisionDesignerdecision to proposeContractordecision to bidYouCommencement DateEach party’s life cycle opens at its own decision. Only the last one has a programme.
Figure 1 — Drawn from the construction extension’s treatment of life cycle perspectives. The delivery team’s first day is the fourth event on this line.

The contract already holds four dates before you hold one

This isn't only an organisational observation. It is written into the standard forms, and it can be read off them in order.

The Base Date comes first: under the FIDIC forms it is fixed at 28 days before the last date for submitting the tender. It exists because changes in law and in cost have to be measured from somewhere, and that somewhere is before anybody has been appointed to anything.

Then the Letter of Acceptance. Then the Commencement Date, which the Engineer must notify at least 14 days in advance and which falls within 42 days of the Letter of Acceptance unless the contract says otherwise. And only then the Time for Completion, which runs from the Commencement Date and is the thing the contractor is actually judged against.

Four dates, in sequence, and the one your programme starts on is the last.

FOUR CONTRACT DATES, IN ORDERBase Date28 days before tenderLetter ofAcceptanceCommencementnotified in advanceTime forCompletionThe clock the contractor is judged against starts at the fourth date.
Figure 2 — Every date to the left of the red box exists before the contractor has a programme, and each one is a record somebody else produced.

Contract Week 20 reads the whole calendar of obligations that hangs off these; what matters here is the ordering, because it is the ordering that produces the failure.

The variance that was accrued before your programme existed

The owner sanctioned the project against a date. Not the Time for Completion — a production date, or an opening date, or a date a lease begins. That date came out of a business case, and the business case is what the money was released against.

Between sanction and Commencement, the front end ran. Studies took longer than the study plan. A permit came back with conditions. The tender was re-issued because two bidders qualified their prices. None of that is unusual and none of it is anybody's misconduct, but all of it consumed time out of the same total.

Now the contractor mobilises, produces a programme from the Commencement Date, and shows completion inside the Time for Completion. The programme is correct. It is also incapable of showing the months already spent, because those months aren't in it and can't be.

Which is how a board sees an overrun that the delivery programme has no line for, and how a delivery team gets asked to recover time it never lost.

TWO TOTALS, ONE END DATEfront end — consumed before awardyour programmeOwner’s total, from sanction to target dateCommencement DateThe board is looking at the whole bar. The programme can only draw the green part.
Figure 3 — Nothing in the programme is wrong. It starts where the contract tells it to start, which is the point after the overrun has already happened.

Float that was spent by somebody you never met

Schedule Week 13 established that float belongs to the network rather than to a party, and Claims Week 11 established who gets to use it when two events compete for it. Both of those arguments start at the Commencement Date, because that is where the network starts.

The gap between sanction and Commencement is float in the owner's life cycle and it is invisible in yours. It was consumed by people who had no schedule showing what it was worth, against a fixed end date they may not have been told was fixed.

So the contractor tenders a Time for Completion that was set by subtraction — end date minus whatever the front end had left — and prices it as though it were an estimate of the work.

Why the phases overlap, and who decided they would

The same source makes a second point that the rest of this track leans on. Engineering is iterative by nature: a data sheet is issued in a basis-of-design version and then again in an as-purchased version, and the difference between them reaches procurement and foundations. Construction isn't iterative. It is deterministic, and it is affected by how far the phases have been allowed to overlap.

That overlap is a decision, not a fact about building. Somebody chose to let construction start before design finished, in exchange for an earlier end date, and the exchange rate was rework risk. The choice was made in the delivery strategy, which is a front-end document — so by the time you inherit an overlapping programme, the trade has already been priced and you are administering it rather than making it.

The asset outlives the project

There is one more frame, and it is the owner's real one. In the total cost management literature the project is a phase inside an asset's life cycle, not a thing in itself. The asset is conceived, delivered, operated for decades, and eventually decommissioned. Delivery is the short, expensive middle.

That is why the question from last week — whether a record carries its own provenance — isn't housekeeping. The project team's horizon ends at a final certificate. The asset's horizon doesn't, and the people who will hold it for thirty years were not in any of the three life cycles above.

System design

Four of these five records exist before the delivery team does, which makes the fifth the only one you can produce. It is also the cheapest row in this entire dictionary and the one most reliably missing.

RecordProduced byRequired qualityVerified againstFeeds
Sanction and its target dateThe owner’s board, before any appointmentThe date the money was released against, not the contract dateThe business case it approvedThe gap you are measured inside
Base DateFixed by the tender programmeStated, not inferred from the tender returnThe contract definitionChanges in law · cost adjustment
Letter of AcceptanceThe Employer, on awardDated, with what was and wasn't acceptedThe tender and its qualificationsThe Commencement Date window
Commencement Date noticeThe Engineer, in advanceA notice you received, not a date you assumedThe Letter of AcceptanceTime for Completion · the programme
Date registerProject controls, in week oneAll four dates on one line, with the owner’s target beside themThe documents each came fromEvery conversation about lateness

Read the Verified against column. Every date here is written in a document somebody sent, and every one of them gets quoted from memory in meetings. A date register is a defence against that and against nothing else, which is enough.

Practical insight

Find the two dates that aren't in your programme, and write them down.

The first is the date the owner sanctioned the work. It sits in a board paper or an appropriation nobody will hand over, and it can be had approximately by asking a client counterpart when funding was released. The second is the target date the business case was built on — the production date, the opening date, the date a contract with somebody else begins.

Put both on the same line as your Commencement Date and your Time for Completion, in a single note. Four dates, ten minutes, and it tells you two things nothing else will. It tells you how much of the owner's total was consumed before you arrived, which is the honest size of the pressure you are under. And it tells you whether the completion date and the target date are the same date, because where they aren't, somebody is carrying a gap and has not said so.

Do it in the first fortnight, while asking naive questions is still free.

Key takeaways

  • The question “when did the project start” has three correct answers, one per party, and they are years apart.
  • For the contractor the project is conditional until award, so pursuit and delivery are different activities with different records.
  • The delivery team doesn't join a project late. It joins a different project sharing a site and a name.
  • The contract carries four dates in order — Base Date, Letter of Acceptance, Commencement Date, Time for Completion — and yours is the last.
  • The Base Date sits before appointment because changes in law and cost have to be measured from somewhere.
  • The owner sanctioned against a production date, not against your completion date. The two aren't required to match.
  • Time consumed between sanction and Commencement is invisible in a programme that starts at Commencement, and can't be shown in it.
  • A Time for Completion set by subtraction isn't an estimate of the work, and it is priced as though it were.
  • Phase overlap is a delivery-strategy decision that trades rework risk for an earlier end date. You inherit the trade, you don't make it.
  • The project is a phase inside an asset life cycle. The people who hold the asset afterwards were in none of the three life cycles.

Records born here. The Base Date · the Letter of Acceptance · the Engineer's notice of the Commencement Date · the sanctioned target date in the business case · the date register reconciling all four.

What is coming next

Four dates, and the earliest of them is a consequence rather than a beginning. Something happened before the Base Date, and it is the thing that decided the job would exist at all.

Somebody built a case, somebody tested it, and somebody with signing authority released money against a number that carried an accuracy nobody outside the room ever sees. The next week is that decision: what a business case has to contain, what an investment decision commits, and which of the people who made it will still be reachable when you need to ask what an assumption meant.

Enjoyed this lesson?

Join with Google to get each new lesson the moment it's published — and help me see which topics matter most to you. No spam, one email a week, unsubscribe anytime.