Schedule Quality
The DCMA 14-point check, one check at a time
Published 6 August 2026 · 12 minute read
The 14-point assessment came out of the US Defense Contract Management Agency as a way to screen contractor schedules for structural integrity before anyone argued about dates. Two decades later it is the closest thing schedule QA has to a shared language: boards ask for it, clients write it into contracts, and every serious review starts somewhere near it. This article walks through each check the way a reviewer actually uses it: what it measures, the standard threshold, why the check exists, and where the threshold deserves an argument rather than obedience.
One framing note before the list. The 14 points test whether a schedule is structurally able to be trusted, not whether it is a good plan. A schedule can pass all 14 and still describe a project that cannot be built. Passing earns the right to have the harder conversation, nothing more.
1. Logic: fewer than 5% of tasks missing a predecessor or successor
Every incomplete task should have at least one predecessor and one successor, with the obvious exceptions of the project start and finish. A task with no predecessor starts whenever the scheduler typed it. A task with no successor can slip forever without moving anything. Either way, the network is not doing its job and the critical path that falls out of it is fiction.
Where it deserves an argument: level-of-effort and hammock activities legitimately dangle, and summary-heavy schedules imported between tools often report false misses. The 5% allowance exists to absorb these. If your misses are structural tasks on the driving path, 4.9% is not a pass in any sense that matters.
2. Leads: zero relationships with negative lag
A lead (negative lag) says the successor starts before the predecessor finishes, which is a claim about overlap the network cannot verify. Leads hide logic: the honest version is almost always to split the predecessor and tie the successor to the real intermediate point. DCMA's guidance is zero because leads also make float and the critical path harder to interpret, and because they behave differently between scheduling tools.
Where it deserves an argument: rarely. This is one of the checks where the purist position is also the practical one. If you have leads, you have a modelling shortcut someone will eventually misread.
3. Lags: fewer than 5% of relationships carry positive lag
Lag is invisible duration. It consumes time on the path but has no name, no owner and no progress, and it cannot be statused. Concrete cure time is the classic defensible lag. "The client usually takes three weeks to approve" is not a lag, it is an approval task that somebody decided not to model. The 5% threshold tolerates the former without licensing the latter.
Where it deserves an argument: process-driven industries with real physical waits carry higher lag counts for defensible reasons. In review, the useful question is not the percentage. It is whether each large lag would survive being renamed as a task.
4. Relationship types: at least 90% Finish-to-Start
FS links are the ones everyone can read: this finishes, that starts. SS and FF pairs model real overlap but each one carries assumptions about production rates that live in the scheduler's head. A network dominated by SS/FF plus lags is a network only its author can drive, and float readings through those chains get strange in both P6 and Microsoft Project.
Where it deserves an argument: linear and fast-tracked work (pipelines, rail corridors, fitout floors) legitimately runs heavy SS/FF. If that is your world, hold the spirit of the check: every non-FS link should be explainable in one sentence.
5. Hard constraints: fewer than 5% of tasks
Must-Finish-On, Must-Start-On, Start-No-Later-Than and their relatives override logic. Enough of them and the schedule stops calculating and starts asserting: dates hold still while the network strains against them, and float goes negative in places that make no sense. Soft constraints (As-Late-As-Possible aside) at least let the network keep working.
Where it deserves an argument: contract dates and external interfaces earn constraints; convenience does not. A useful review habit is to ask for the constraint register: if nobody can produce one, the constraints are not decisions, they are residue.
6. High float: fewer than 5% of tasks with total float above 44 working days
Two months of float on a task usually means the logic connecting it to the rest of the project is missing or wrong, not that the task is genuinely relaxed. Large float pockets are where missing links from check 1 go to hide: the task has a successor, it is just not the one that matters.
Where it deserves an argument: long procurement tails and staged handover programmes carry legitimate high float. Read this check together with check 1. High float with clean logic is a plan with room; high float with thin logic is an unfinished network.
7. Negative float: zero tasks
Negative float means the schedule, as modelled, does not achieve its own commitments. That is not always a scandal, mid-project it is often just the truth, but it is never something to leave sitting in a submitted programme without a recovery narrative. Unexplained negative float in a baseline submission is the fastest credibility destroyer there is.
Where it deserves an argument: an update cycle can legitimately show negative float the day it is statused. The check's real demand is that negative float always arrives accompanied by its explanation and its recovery plan.
8. High duration: fewer than 5% of tasks longer than 44 working days
A two-month task cannot be statused with any precision: percent complete on it is a mood, not a measurement. Long tasks also hide internal logic, the real sequence lives inside them where the network cannot see it. Breaking them down is what makes progress claims auditable.
Where it deserves an argument: far-future planning packages are allowed to be long; that is what rolling-wave planning is. The check should bite on work inside the detailed planning window, not on next year's placeholders.
9. Invalid dates: zero
No forecast dates in the past, no actual dates in the future. A forecast start behind the data date is work the schedule claims is coming but which should already have happened; an actual ahead of the data date is a record of something that has not occurred. Both mean the statusing process, not just the schedule, needs attention.
Where it deserves an argument: nowhere. This is the one check with no defensible exceptions. It is also the first thing a forensic analyst will look for if the schedule ever ends up in a dispute.
10. Resources: tasks carry resources or costs
The DCMA formulation asks that discrete tasks of a day or more carry resource or cost loading, because an unresourced schedule cannot be checked against capacity and cannot support earned value. Whether a schedule should be resource-loaded at all is a contract question, which is why this is the most commonly waived of the 14.
Where it deserves an argument: constantly. If your contract does not require resource loading, treat this check as "not applicable" and say so, rather than pretending a fail means something.
11. Missed tasks: fewer than 5% finished late against baseline
Of the tasks that should have finished by the data date, how many actually did, or are forecast to finish late? This is the first of the three checks that measure performance rather than structure. A rising missed-task count is the early, task-level version of the slip that will eventually reach the completion date.
Where it deserves an argument: only about the baseline it measures against. Against a re-baselined programme the check flatters; against the original contract baseline it tells the truth. Know which one you are looking at.
12. Critical path test: break it and watch
The DCMA version: add 600 working days to a task on the critical path, recalculate, and check the project finish moved by roughly the same amount. If the finish date holds still, something is absorbing the slip: a constraint, a severed chain of logic, an unlinked milestone. It is a blunt experiment, and effectively an integration test for the network.
Where it deserves an argument: none about the principle. The debate is only about practice, since running it by hand on a live file is risky enough that many schedulers skip it. Run it on a copy, or let a tool do the equivalent analysis without touching the file.
13. Critical Path Length Index: at least 0.95
CPLI is (critical path length + total float) divided by critical path length, measured to the contractual finish. At 1.0 the remaining path exactly meets its commitment. Below 1.0 the path is carrying negative float, meaning the plan already depends on running faster than its own logic allows, and below 0.95 DCMA treats that recovery assumption as unrealistic.
Where it deserves an argument: CPLI is coarse, one number for a whole network, and it says nothing about which path is doing the damage. Treat it as a trend indicator across updates rather than a single-cycle verdict.
14. Baseline Execution Index: at least 0.95
BEI is the ratio of tasks actually completed to tasks the baseline said would be complete by now. It is the schedule-world sibling of SPI: a running score of whether the programme executes at the rate it promised. Like check 11 it is meaningless without a baseline, which is why a schedule with no baseline set should fail this check outright rather than skip it.
Where it deserves an argument: BEI counts tasks, not importance, so a programme can hold 0.95 by finishing easy tasks while the driving path stalls. Read it alongside checks 11 and 13, never alone.
Using the 14 points well
Three habits separate reviewers who use this framework from reviewers who are used by it. First, thresholds are screening levels, not grades: 4.9% missing logic on the driving path is worse than 7% on a fringe of non-critical scope. Second, the checks interact, high float explains missing logic, constraints explain negative float, and reading them in isolation misses the story. Third, the structural checks (1 to 10) earn trust and the performance checks (11 to 14) spend it. A schedule that passes structure and fails performance is telling you the truth about being behind, which is a far better position than the reverse.
PathProof runs all 14 checks on a Microsoft Project or Primavera P6 file in seconds, with per-task findings behind every number and every threshold configurable, because the best-documented criticism of the 14-point check is precisely that one size does not fit all projects. The beta is free while we refine it with working schedulers.