Ten checks to run before a monthly programme leaves your office. Most of them take ten minutes with a saved filter. All of them are cheaper than having the submission rejected, and considerably cheaper than discovering the problem in a delay claim two years later.
This is written for a construction programme in Primavera P6 or Microsoft Project, statused monthly and submitted to a principal contractor, superintendent or client representative. It assumes you are the person who has to defend it.
The sequence matters more than it looks. Checks 1 to 8 are about whether the network can calculate anything at all; checks 9 and 10 are about whether what it calculates is true. Statusing a schedule whose logic is open wastes the statusing, because the dates it produces will move again the moment the logic is fixed.
A programme that fails these checks is not a bad document. It is a document that cannot answer the question it was written to answer — when will this finish, and what changes that?
On programmes that reach formal submission, the failures cluster. Checks 2 and 8 — relationships and the critical path — are the ones I see fail most often, and they fail together, because a network with immature logic cannot produce a meaningful driving chain.
Two more that rarely get counted as quality problems at all: float is almost never allocated toward the riskiest work, and there are few mitigations in place to keep the schedule healthy as it degrades. A programme can pass a structural audit and still have all its slack sitting against the safe tasks.
That is why check 8 asks the second question — whether the critical path runs through work that is genuinely driving the job. A technically valid network aimed at the wrong chain is the most common way a submitted programme is quietly useless.
Before anything technical. Three things go wrong here more often than any logic error:
A programme submitted against the wrong baseline is usually accepted, because nobody checks. It then becomes the record — and every variance argument for the rest of the job runs off a comparison you cannot defend.
Every activity except the first and the last needs both a predecessor and a successor. Filter for missing ones; it is a saved query you build once.
Then look for the subtler failure: danglers. An activity linked only start-to-start has a predecessor on paper, but nothing controls its finish, so it can run over indefinitely without pushing anything. It passes an open-ends filter and still breaks the forecast.
DCMA threshold: no more than 5% of activities with missing logic.Delay does not flow. An activity slips four weeks, nothing downstream moves, and the completion date holds — so the schedule reports on programme while the job is not. This is the single most common reason a programme cannot forecast.
Count every Must Finish On, Must Start On and Mandatory constraint. Each one is a place where the schedule has stopped calculating and started asserting.
Soft constraints — Start On or Later for a site access date, for instance — are usually legitimate and reflect a real external commitment. Hard ones override the logic entirely and will happily hold a date that the network says is impossible.
DCMA threshold: no more than 5% of activities constrained.Slip stops appearing. A hard constraint on a completion milestone absorbs delay silently, and the first anyone knows is when the constraint is finally removed and three months of accumulated slip land at once.
A lead — negative lag — lets a successor start before its predecessor finishes. It is almost always a shortcut around sequencing that should have been modelled as separate activities, and it makes the critical path genuinely difficult to read.
Lags are legitimate in moderation: concrete cure times, approval periods, procurement lead times. A programme where a fifth of the relationships carry a lag is usually one where durations have been hidden inside the links rather than shown as work.
DCMA thresholds: leads 0%. Lags no more than 5% of relationships.Leads make delay analysis contestable. When an expert has to explain why work started before its predecessor finished, your own programme becomes the other side's exhibit.
Negative float is not a warning about the future. It is a statement that the schedule is already impossible — the remaining work does not fit between the data date and a date the programme is required to meet.
There are only two honest responses, and choosing neither is the mistake. Either fix the logic or constraint producing it, or state the delay and its cause explicitly in the narrative before someone else does.
Submitting negative float without explanation hands the client a choice between rejecting the programme and treating it as your admission that the contract date is gone. Neither is a conversation you want to have by accident.
Total float above roughly 44 working days on a construction programme is nearly always missing logic wearing a disguise. An activity with no successor reports enormous float because nothing depends on it — not because it can genuinely sit idle for two months.
Treat high float as a symptom and go back to check 2. And before you rely on float anywhere near a claim, check what the contract says about who owns it — that is a commercial question, not a scheduling one, and the answer varies.
You believe you have slack you do not have. Work gets deferred against float that was an artefact, and the deferral turns out to be on the critical path after all.
An activity of 90 working days cannot be statused meaningfully. "Forty per cent complete" on a bar that long is an opinion, and it is an opinion that is impossible to challenge and impossible to verify.
Break long activities down to something you can walk out and confirm. The exception worth defending is genuine level-of-effort work — supervision, site establishment running for the duration — which should be flagged as such rather than left to look like production work.
DCMA threshold: no more than 5% of incomplete activities longer than 44 working days.Progress becomes unfalsifiable. A long activity reports steady percentage gains for months and then fails to finish, and there was never a point at which the data would have shown you why.
Two questions, and the second is the one that gets skipped.
Is it continuous? The critical path should run unbroken from the data date to project completion. A break means the chain driving the end date does not actually reach the end date.
Does it run through work that is genuinely driving the job? If your critical path threads through approvals, procurement placeholders and administrative milestones while the actual construction sequence sits at ten days of float, the network is not modelling how the project gets built. It is technically valid and practically fiction.
Every management decision you make from the schedule — where to accelerate, what to resource, which delay to argue — is aimed at the wrong chain of work.
Four things to look for, all of which are common and none of which are subtle once you filter for them:
The forecast is computed from remaining duration. If that number is a reverse-engineered percentage rather than a considered estimate, the completion date is arithmetic performed on a guess.
The last check has nothing to do with the file. Open the monthly report you are about to submit alongside it and confirm they say the same thing.
If the schedule forecasts completion in March and the report says the project is tracking to January, one of them is wrong — and from the moment both are submitted, both are evidence. Contemporaneous records are what extension-of-time claims are built on, and a contradiction between your own two documents is the first thing an opposing expert will look for.
Check the contract milestone dates too, one by one, against what the schedule now forecasts. That is the comparison the client will make first.
Credibility, and it does not come back. A superintendent who finds one contradiction reads everything you submit afterwards looking for the next.
Checks 2, 3, 4, 5, 6, 7 and part of 8 are measurable from the file itself, which is exactly what the DCMA 14-Point Assessment does. Our free DCMA 14-point checker runs them in the browser on a P6 .xer or MS Project XML export — nothing is uploaded, and it tells you plainly which checks it cannot assess rather than passing them by default.
If you want the reasoning behind each threshold rather than the score, the 14 checks explained takes them one at a time, with the failure mode and the fix in P6 or MS Project.
What no automated check can do is checks 1, 9 and 10 — the right file, honest statusing, and agreement with your own report. Those need the person who knows the job.
About an hour once it is a habit, and most of that is statusing. The structural checks are saved filters you build once and re-run in under ten minutes. The judgement calls — whether the critical path is real, whether the schedule and the report agree — are the part worth your time.
Because the checks measure structure, not truth. Closed logic, no constraints and healthy float mean the network is capable of forecasting. They say nothing about whether durations are realistic or the sequence matches how the site will be built. That is why checks 9 and 10 exist.
Usually the opposite. Above about 44 days it is nearly always missing logic rather than genuine slack — and check the contract for who owns float before relying on it.
Then say so in the narrative, with the cause. Negative float you have explained is a delay event on the record. Negative float you have quietly left in is an admission nobody will read charitably later.
The contractual question is whether anyone will check. The practical question is whether your own forecast is worth anything. These checks exist for the second one.
A schedule that passes these checks can finally answer the question it was built for. Aegis reads the same P6 or MS Project export each month and does the reading — earned value, float erosion, milestone slip, and a written assessment of what changed since last period.
Start your 14-day trial →