Schedule Control

The acceptance trap

A programme is submitted. It is long, it is dense, it arrives as a PDF or a P6 file, and reviewing it properly would take a planner a week. So it is filed. Nobody says yes; nobody says no.

That silence is not neutral. When the delay claim arrives — and on a project of any size it arrives — the programme that nobody objected to is the programme the claim is built on. Its logic, its float, its sequence, its assumptions about your approvals: all of it becomes the agreed picture of how the job was going to run, because you had the opportunity to challenge it and did not.

This is the single most expensive thing an owner does by accident. The cost of not reviewing a programme is not the review you saved. It is the claim you can no longer answer.

Baseline and last-approved: two lenses, two questions

Every monthly submission has to be read twice, against two different things, because they answer different questions and a contractor would much rather you only asked one of them.

Against the BASELINE — the programme agreed at sanction — you are asking: how far has this project drifted from what was promised? That is the number the board wants, the number the contract is measured on, and the number that grows.

Against the LAST-APPROVED programme — last month’s submission — you are asking: what moved, and why? That is the number a project manager can act on, because it is small enough to have a cause you can still find.

Read only the second and a project that has slipped a year in twelve equal steps looks healthy every month it does it. Read only the first and every conversation is about a number so large that nobody can attribute it to anything. Zepth compares against both, on every submission, because the pair is the instrument. Either one alone is a way of not knowing.

The DCMA 14-point check, explained plainly

The most widely used screening instrument for schedule quality came from an unlikely place. In 2005 a US defence memo required an integrated master schedule on contracts above $20 million; the Defense Contract Management Agency was told to work out how to evaluate one, and produced fourteen mechanical checks. They were never ratified as a standard — the documentation is essentially an online training course — but the schedule tools implemented them, and now owners increasingly require a passing score before they will accept a programme.

They are worth knowing because they are cheap to run and they catch the things a contractor’s scheduler can hide in plain sight: logic that goes nowhere, dates pinned by constraints rather than driven by sequence, activities that no longer connect to the finish. Here they are, in full.

And why a passing score is not a good programme

We are publishing the fourteen checks because they are useful. We are also going to say the thing that vendors selling schedule analytics tend not to: a programme that passes all fourteen can still be a bad programme, and enforcing them mechanically can make your position worse.

The clearest example is float. Check 6 fails a schedule with too many high-float activities, so an owner who makes the check contractual is telling the contractor to reduce float — and the contractor reduces it by adding logic that ties activities together more tightly than the work requires. The schedule now looks disciplined. It is also more brittle, and every future disruption has less slack to absorb it. As the protocol’s own principal commentator puts it, an owner who requires a contractor to lower their float values is increasing their exposure to later delay claims. The 44-day cutoff itself is essentially arbitrary — it was chosen because it is roughly two months.

The checks were built to screen defence master schedules, not to adjudicate construction programmes, and they were never designed to be a contractual gate. Use them as what they are: a fast, mechanical filter that tells you where to look. The judgement is still yours, and it is still the expensive part.

Float belongs to the project

Total float belongs to the project, not to either party, and it is consumed on a first-come basis. That is the doctrine, it is what the SCL Protocol reflects, and it is the sentence that decides who pays when two delays meet.

It matters here because float is the thing a monthly submission quietly moves. A contractor who has absorbed their own delay by eating the project’s float has not delayed the project — yet — and so nothing appears in the milestone table. But the buffer that would have absorbed YOUR next design change has gone, and the first person to need it discovers it is not there.

So the float story is part of the monthly review, not an annex to it: not only did the end date move, but how much protection is left between the work and the end date. A programme whose finish date has not moved for six months while its float has halved is not a stable programme. It is a programme running out of room.

The 90% that stays 90%

Progress claimed against an activity is an assertion, and it is the softest number in construction. An activity at 90% for two consecutive months has not been 90% complete for two months — it was never 90% complete in the first place, and the report has been carrying an error forward while looking like it was carrying information.

The reason this matters beyond the programme is that progress claims are what payment applications are built on. An inflated percentage is not just an inaccurate schedule; it is money certified against work that is not there, and it is very hard to take back.

The defence is a measurement rule agreed before the work starts — what counts as complete, and who says so — rather than a monthly negotiation about a number somebody has already reported to their own management.

The programme is the EOT evidence

Every extension-of-time claim is an argument about the critical path: this event happened, it delayed this activity, that activity was driving the finish date, and therefore the finish date moved. The analysis is done on the programme.

Which means the delay analysis you can run is dictated by your records, not by which method is best. A contemporaneous set of monthly programmes — each one dated, each one compared, each one with its variance explained at the time — is what a windows analysis is made of. Without them, you are reconstructing a history after the fact, against an opponent who is doing the same thing and reaching a different conclusion.

This is the same argument the daily reports make, one level up. The daily report proves what happened on the ground; the programme sequence proves what it did to the end date. An owner who has kept both has an answer. An owner who has kept neither has a negotiation.

Where this sits, and where it does not

Zepth is not a scheduling tool and does not want to be one. Your contractor plans in Primavera P6 or Microsoft Project, they are good at it, and those programmes are theirs to author. Zepth imports what they produce and gives you the instrument to govern it: the register of submissions, the two comparisons, the milestone variance, the drift, the approval.

The pairing with Cost Control is the point. Cost is committed at decision moments and reported at invoice moments; time is committed at sequence decisions and reported at milestone dates. Both lag. Both are the owner’s exposure and neither is the owner’s document. One record, two levers.

How Zepth runs schedule control

Programmes are imported from P6 and Microsoft Project at full depth — thousands of activities, not a milestone summary — and each monthly submission enters a numbered register with its report date, who submitted it, and its approval status. The governance cycle is a record, not an email thread.

Every submission is compared against the latest baseline AND against the previous report, because those answer different questions. Forecast completion is tracked against the contract date with the variance stated, and against last month with the movement stated — so month-on-month drift is the first thing on the page rather than something you derive. Alongside it: planned-versus-actual S-curves, period and cumulative; activity status rolled up across the whole programme; original, elapsed, remaining and forecast duration; and a key-milestone table carrying each milestone’s baseline date, this month’s date, last month’s date and the variance in days, with its direction.