What should an owner check before accepting a monthly programme?
Whether the logic holds, whether dates are calculated or pinned by constraints, what moved since last month and what moved since the baseline, where the float went, and whether the claimed progress is credible against the rest of the record. And then say something — because a programme nobody objected to is the programme the delay claim against you will be built on.
Silence is an answer, and it is the wrong one
The submission arrives, it is dense, reviewing it properly would take a planner a week, and so it is filed. Nobody approves it. Nobody rejects it. That feels like neutrality and it is not.
When the delay claim comes, the programme nobody challenged is the agreed picture of how the job was going to run — its sequence, its float, its assumptions about how fast you would return approvals. You had the chance to object. The cheapest moment to challenge a programme is the month it is submitted, and there is no second-cheapest moment.
The mechanical half — what a filter can catch
Some of the review is arithmetic, and it should be done the cheap way. The DCMA 14-point check is the standard instrument for it, and the questions it asks are the right ones to ask first:
- Logic — are activities dangling outside the network? An activity with no predecessor or successor cannot drive the finish date and cannot be delayed by anything. It is invisible to the critical path.
- Constraints — are the dates calculated, or pinned? A heavily constrained programme has stopped responding to reality, which is often exactly the intent.
- Negative float — if it is there, the programme is already telling you it cannot be delivered as sequenced.
- Activity duration — a 60-day activity is 60 days of “in progress” with no way to tell whether it is late.
- The critical path test — add a large delay to a critical activity and see whether the finish date moves. If it does not, the path is broken, and every delay analysis built on it is fiction.
The judgement half — what no filter can catch
Then the part that matters. Where did the float go? A contractor who absorbed their own delay by eating the project’s float has not moved the end date — yet — so nothing shows in the milestone table. But the buffer that would have absorbed your next design change is gone, and the person who finds out is the next person who needs it.
Is the claimed progress credible? An activity sitting at 90% for two months was never 90% complete, and that number is what payment applications get built on.
And has the sequence quietly changed in a way that shifts risk onto you — a longer approval window assumed, a free-issue date brought forward, a work front now depending on something you owe them?
References
- module: /modules/schedule-control/ — the owner’s monthly programme review
Zepth is the construction project delivery platform — it runs construction, procurement and asset management on one record, and does the work: reading the drawings, reviewing the submittals, matching the invoices and flagging the risks, with a human sign-off on anything consequential.
Related questions
See Zepth on your project.
A short, tailored walkthrough on your real workflow — no generic demo.
Book a meeting