The DCMA 14-point assessment, properly explained

The 14-point check has become the de facto quality standard for CPM schedules far beyond US defence contracting — and it is routinely misunderstood. Here is what each metric actually measures, where the thresholds come from, and which failures matter most.

Where the 14 points came from

The US Defense Contract Management Agency introduced the 14-point assessment as a triage tool: a way for government analysts to evaluate hundreds of contractor Integrated Master Schedules without reading every one of them activity by activity. The insight behind it was simple and slightly subversive — you can tell a great deal about whether a schedule is trustworthy without knowing anything about the project it describes.

A schedule with no missing logic, no leads, few lags, sensible constraints and a believable critical path might still be wrong about the project. But a schedule that fails those structural checks is almost certainly wrong, because the CPM engine cannot calculate honest dates through broken logic. That asymmetry is why the 14 points spread from US defence into oil and gas, rail, nuclear and construction worldwide: it is the cheapest reliable filter ever devised for schedule quality.

One caveat the original DCMA guidance is careful about and most users forget: the thresholds are tripwires, not pass/fail grades. Exceeding 5% missing logic does not prove the schedule is unusable; it tells the reviewer exactly where to start asking questions.

The 14 checks at a glance

The structure checks (1–5): can the engine be trusted?

1 · Logic — ≤ 5% missing predecessors or successors

An incomplete activity with no predecessor starts whenever the project starts. One with no successor can slip forever without moving the completion date. Either way, the float calculation around it is fiction. The 5% threshold excludes the obvious legitimate cases — the project start milestone needs no predecessor, the finish milestone no successor — but everything else should be wired in.

In our experience this is the single most commonly failed check on contractor schedules, and the most diagnostic. A programme with 20% open ends was built as a bar chart wearing a CPM costume.

2 · Leads — zero tolerance

A lead (negative lag) says a successor starts before its predecessor finishes — "start the plastering five days before the partitions are complete." Humans understand what that means; the CPM engine does not. Leads distort the critical path, produce float values that mislead, and make forensic reconstruction painful later. The DCMA position is blunt: zero. If two activities genuinely overlap, split the predecessor and tie the pieces with clean finish-to-start logic.

3 · Lags — ≤ 5% of relationships

Positive lags are tolerated, sparingly, because some have a real physical meaning: concrete genuinely needs days to cure. The trouble is that a lag is an invisible, unresourced, unowned duration — it never shows on a bar chart, no one updates it, and it silently moves dates. Our rule of thumb: a lag that represents a physical process deserves to be an activity with a name; a lag that represents "about how long we think the gap should be" deserves to be deleted.

4 · Relationship types — ≥ 90% finish-to-start

FS logic is unambiguous: this finishes, then that starts. Start-to-start and finish-to-finish pairs have legitimate uses for genuinely parallel work, but a schedule dominated by SS/FF relationships (very often SS with lags) is usually concealing a level of detail that should have been planned as discrete activities. SF relationships are almost never justified — most analysts treat any SF link as a modelling error to be explained.

5 · Hard constraints — ≤ 5%

Must-Finish-On, Must-Start-On, mandatory dates: every one of them overrides logic. Pin enough dates and the schedule stops being a model and becomes a drawing — the dates can no longer respond to change, which is the entire point of CPM. Soft constraints (start-no-earlier-than for a permit, say) are acceptable; hard ones need individual justification. A schedule that only achieves its completion date through a Must-Finish constraint plus hidden negative float is one of the oldest tricks in the book, and check 7 exists to catch it.

The realism checks (6–10): would anyone actually build this?

6 · High float — ≤ 5% above 44 working days

Two months of total float on an activity usually means it isn't really connected to the delivery strategy — its logic is missing or wrong. Pockets of enormous float are where scope quietly drifts, because nothing about the CPM dates creates any urgency around them.

7 · Negative float — zero

Negative float is the schedule telling you, arithmetically, that the plan as drawn cannot meet its committed dates. It is not a quality problem so much as an honesty problem: a schedule submitted with −23 days of float on its critical path is a delay notification wearing a progress update's clothing. We wrote a full article on float including what negative float really means contractually.

8 · High duration — ≤ 5% above 44 working days

An activity that lasts two months cannot be statused honestly — "40% complete" against a 60-day bar is a guess, not a measurement. Long durations are where progress hides. The fix is decomposition, and the discipline of doing it usually exposes logic that was missing too.

9 · Invalid dates — zero

No forecast work scheduled before the data date; no actual dates recorded after it. Sounds trivial; fails constantly. Invalid dates mean the schedule wasn't statused properly, and every downstream calculation inherits the error.

10 · Resources — every task costed or resourced

The most contested check, and the one most often excluded outside defence. If the contract doesn't require resource loading, failing this check tells you about the contract, not the schedule. Apply judgement.

The performance checks (11–14): is anyone telling the truth about progress?

11 · Missed tasks — ≤ 5%

What fraction of activities that should have finished by the data date actually finished on or before their baseline date? Above 5% and the baseline is no longer describing the project being executed.

12 · Critical path test — does the network respond?

Inject a large delay into a critical activity and check the completion date moves by the same amount. If it doesn't, logic is broken somewhere between that activity and completion — constraints or open ends are absorbing the delay. A schedule that fails this test cannot be used for delay analysis at all: it is structurally incapable of showing the effect of any event.

13 · CPLI — ≥ 0.95

The Critical Path Length Index compares the time remaining (critical path length plus total float) against the time needed (critical path length). A CPLI of 1.0 means exactly on track; below 0.95 means the remaining plan needs to over-perform to hit the date.

14 · BEI — ≥ 0.95

The Baseline Execution Index: tasks actually completed divided by tasks baselined to have completed. BEI is the throughput twin of check 11 — together they tell you whether early performance supports the forecast. A project completing 80 tasks for every 100 planned (BEI 0.80) is accumulating a backlog that the unchanged completion date pretends doesn't exist.

How to actually use the result

A 14-point report is a map of where to look, not a verdict. Three habits separate analysts who use it well from teams who just collect the score:

• Sequence the fixes. Structure first (1–5), then realism (6–10), then performance (11–14). Repairing logic changes float everywhere, so fixing high float before fixing open ends is wasted work.
• Read failures together, not separately. Hard constraints + negative float + a failed critical path test is not three problems — it is one problem (a date being forced) seen from three angles.
• Trend it. A single score tells you about the schedule; the score across five updates tells you about the team. Quality that decays update by update is the leading indicator of a programme heading for dispute. That trend view is exactly what our Time Machine was built for.