DCMA 14-point assessment

Last reviewed 9 September 20263,691 words17 min read

All fourteen checks, and when failing one is still correct

🟩 In one line Fourteen mechanical tests that tell you whether a schedule is built properly — linked, unconstrained, updateable. They say nothing about whether it's achievable. Pass all fourteen and you might still have a fantasy. Fail three and you might have the best schedule on the project. Know what each test is actually measuring before you quote it.

👤 Who this is for Every planner, because every Gulf client now runs these. Junior planners who've been told "make it pass DCMA" and don't know what that means. Mid-level planners deciding which failures to fix and which to defend. Reviewers who need to write comments that are more useful than "Metric 6: fail."

e / c

First, let's be honest about why this page exists

The DCMA 14-point assessment was written by the US Defense Contract Management Agency around 2005, for reviewing contractor schedules on defence programmes. It was never meant to be a global construction standard. It became one anyway — because it's simple, it's countable, and it lets a reviewer with a spreadsheet and no site knowledge say something concrete about a schedule.

That's both its strength and its problem. The tests are useful. They catch real defects, fast. But they've acquired a status they don't deserve: schedules get rejected for failing a threshold that the DCMA itself describes as a trip-wire for further investigation, not a pass/fail. And planners, under pressure, learn to game them — chopping durations to duck the 44-day test, deleting constraints that were contractual, linking everything to the finish milestone to zero the open-end count.

So this page does two things. It explains each metric properly — what it measures, why the threshold is what it is, how to run it in P6. And for each one, it says when failing is right, and what to write when you do.

🟨 The standard — the fourteen at a glance

Thresholds as published. Most are expressed as a share of incomplete activities — completed work is excluded from the count.

#	Metric	Threshold	What it catches
1	Logic	≤ 5% missing predecessor or successor	Open ends
2	Leads	0	Negative lags
3	Lags	≤ 5% of relationships	Work hidden in relationships
4	Relationship types	≥ 90% FS	Over-reliance on SS/FF
5	Hard constraints	≤ 5%	Dates fixed regardless of logic
6	High float	≤ 5% with total float > 44 days	Missing logic, usually
7	Negative float	0	Plan can't meet its constraints
8	High duration	≤ 5% with remaining duration > 44 days	Activities too coarse to status
9	Invalid dates	0	Actuals after data date; forecasts before it
10	Resources	0 activities with duration but no resource or cost	Unloaded work
11	Missed tasks	≤ 5% finished later than baseline	Slippage against plan
12	Critical path test	Pass	Finish moves when a critical activity does
13	CPLI	≥ 0.95	Realism of the critical path
14	BEI	≥ 0.95	Throughput of completed work vs plan

Metrics 1–10 are about how the schedule is built. Metrics 11–14 are about how it's performing. You can run 1–10 on a baseline. 11–14 only mean anything once there's progress.

Who requires it:

Gulf client specs — ADNOC, Aramco, Qatar's public authorities, most large developers. Usually the thresholds verbatim, sometimes tightened (open ends: zero; hard constraints: zero except contractual).
UK — less formally, but NEC and FIDIC project managers increasingly use it as a review framework, and the GAO Schedule Assessment Guide covers the same ground with more nuance.
Software — Acumen Fuse, Schedule Analyzer, P6's own Check Schedule (in later versions) all run it automatically. The numbers they produce are only as good as their filters, and different tools count differently at the margins.

How it actually works — each metric properly

For each: what it measures, how to check it in P6, and the honest exceptions.

1 — Logic

Measures: incomplete activities with no predecessor, no successor, or both. Open ends. P6: schedule log, Activities without predecessors / without successors. Or filter: Predecessors = blank and Successors = blank on incomplete activities. Threshold: ≤ 5%. Reviewers apply zero, except the start and finish milestones. Failing correctly: the two terminal milestones. Nothing else. If someone argues LOE activities should be exempt, tie them to the milestones anyway and end the argument. Full page: open-ends.

2 — Leads

Measures: relationships with negative lag. P6: Enterprise → Activity Relationships view (or export relationships), filter lag < 0. Threshold: zero. Failing correctly: essentially never. Every lead can be rewritten as SS+lag or by splitting the predecessor. The one argument sometimes made — "the client's own template uses them" — is a reason to raise it with the client, not to keep them. Full page: leads-and-lags.

3 — Lags

Measures: relationships with positive lag, as a share of all relationships. P6: same relationship export, lag > 0. Threshold: ≤ 5%. Failing correctly: heavy-civils and structures jobs with hundreds of pours can legitimately run 8–12% because of cure lags. State it in the basis memo: "Lags on concrete relationships represent curing to Spec clause, calculated on a 24-hour calendar." A reviewer who reads that usually accepts it. What they won't accept is 15-day FF lags on finishes with no explanation — those are activities. Full page: leads-and-lags.

4 — Relationship types

Measures: share of relationships that are finish-to-start. P6: relationship export, count by type. Threshold: ≥ 90% FS. SF should be zero. Failing correctly: linear works (pipelines, roads, tunnels) and repetitive fit-out genuinely run more SS/FF — crews follow each other through chainages or floors. 80–85% FS can be defensible if every SS is paired with an FF and lags are short. Document the pairing. SF is not defensible. Full page: relationship-types-explained.

5 — Hard constraints

Measures: incomplete activities with a constraint that overrides logic — Mandatory Start, Mandatory Finish, and depending on the reviewer, Start On, Finish On, and Must Finish By at project level. P6: filter Primary Constraint is not blank; group by constraint type. Threshold: ≤ 5% for the hard types. Soft constraints (Start On or After, Finish On or Before, As Late As Possible) are usually reported but not counted. Failing correctly: contractual milestones with Finish On or Before; access dates with Start On or After; a supplier-fixed delivery with Start On. Each one listed in the basis memo with its source — contract clause, PO number, access schedule. Mandatory constraints: almost never. They break the float calculation on both sides and there's nearly always a softer constraint that does the job. Full page: p6-constraint-types.

6 — High float

Measures: incomplete activities with total float greater than 44 working days. P6: filter Total Float > 44d, incomplete only. Threshold: ≤ 5%. Why 44: roughly two months on a 5-day calendar. The DCMA's view was that activities genuinely two months from mattering are unusual on a well-linked schedule, so high float usually means missing logic. On a 6-day Gulf calendar, 44 working days is closer to seven weeks. Failing correctly: early-phase activities on a long job (a three-year programme in month two will have lots of legitimate float on year-three work); parallel scopes that genuinely finish well before their handover; procurement of non-critical items ordered early for commercial reasons. Explain by grouping: "High float concentrated in Phase 3 external works, which are not required until Date." What won't wash is high float scattered randomly through the main construction sequence — that's open ends or missing links. Full page: total-float; open-ends.

7 — Negative float

Measures: any incomplete activity with total float below zero. P6: filter Total Float < 0. Threshold: zero. Failing correctly: in a baseline, never — if the logic doesn't fit the contract period, that conversation happens before approval, not by hiding it. In an update, negative float is frequently the honest result and should be reported, not removed. The requirement then is a recovery narrative, not a clean column. Reviewers who reject an update for having negative float, rather than for leaving it unexplained, are misreading the metric. Full page: negative-float.

8 — High duration

Measures: incomplete activities with remaining duration greater than 44 working days. P6: filter Remaining Duration > 44d. Threshold: ≤ 5%. Why: an activity longer than two months can't be meaningfully statused — "30% done" on a 90-day activity tells you nothing about which 30%. It should be split. Failing correctly: procurement and fabrication activities — a 120-day transformer manufacture is one activity, and splitting it into "manufacture part 1 / part 2" is fiction. Level of Effort activities. Long-duration client review or approval periods. Note them by type in the basis memo. Construction activities over 44 days are almost always a decomposition problem. Full page: activity-duration-limits.

9 — Invalid dates

Measures: two things — actual dates after the data date, and forecast (early) dates before it. P6: schedule log, both listed. Or filters: Actual Start / Actual Finish > data date; Early Start < data date AND Remaining Duration > 0. Threshold: zero. Failing correctly: never. This is purely mechanical. If it fails, either an actual date is wrong or the data date is. Fix it and reschedule. It's also the single most common reason updates get bounced, and the easiest to prevent. Full page: data-date.

10 — Resources

Measures: incomplete activities with duration ≥ 1 day that have no resource assignment (or, in the cost-based variant, no budgeted cost). P6: filter Budgeted Labor Units = 0 AND Budgeted Total Cost = 0, incomplete, duration > 0. Threshold: zero. Failing correctly: this is the metric most often waived, because many contracts don't require a resource-loaded schedule at all. If the spec calls for cost or manhour loading, the threshold stands. If it doesn't, the metric doesn't apply — say so in the basis memo rather than leaving the reviewer to guess. Milestones and LOEs are excluded by definition. Full page: resource-loading.

11 — Missed tasks

Measures: of the activities that were baselined to finish by the data date, how many finished (or are forecast to finish) later than their baseline finish. P6: filter Baseline Finish ≤ data date, then count those with Finish > Baseline Finish. Needs the correct project baseline assigned. Threshold: ≤ 5%. Failing correctly: on a project that's genuinely behind, this metric should fail — it's reporting reality. The response is the recovery plan, not a fix to the schedule. Also fails spuriously if the wrong baseline is assigned, or if the baseline was never re-set after an approved revision. Check the baseline before panicking. Full page: slippage-and-trend-analysis.

12 — Critical path test

Measures: whether the critical path is real. Method: add a large duration (the DCMA suggests 600 days) to an activity on the critical path, reschedule, and check that the project finish moves by the same amount. If it doesn't, something — a constraint, an open end, a broken chain — is disconnecting the critical path from the finish. P6: do it in a copy or a Reflection, never the live file. Pick the driving activity, add 600 to remaining duration, F9, compare finish dates, close without saving. Threshold: pass or fail. Failing correctly: never, on a properly built network. A fail means the path P6 is calling critical isn't actually driving completion, and the whole float picture is suspect. Fix the structure. The most common cause is a Mandatory or Finish On constraint downstream that's absorbing the push. Full page: critical-path-vs-longest-path.

13 — CPLI (Critical Path Length Index)

Measures: (critical path length + total float on the critical path) ÷ critical path length. Where "critical path length" is working days from the data date to the finish along the longest path, and total float is the float on that path (positive if finishing early, negative if late). Threshold: ≥ 0.95. A CPLI of 1.0 means the path is exactly meeting its target. Below 0.95 means the plan needs to recover more than 5% of the remaining duration — the DCMA's view is that this is rarely achieved. Failing correctly: when the project is genuinely late and the remaining duration is short. A job with 100 days left and −10 days float has a CPLI of 0.90. That's an accurate description of trouble, not a schedule defect. Report it, explain it, attach the recovery options. Full page: cpli-and-bei.

14 — BEI (Baseline Execution Index)

Measures: activities actually completed ÷ activities baselined to be complete by the data date. Threshold: ≥ 0.95. A BEI of 0.80 means you're completing 80% of the work you planned to — you're falling behind at a measurable rate. Failing correctly: same as Metric 11 — if the project is behind, BEI will say so. It's also distorted by activity count: completing lots of small activities early and missing a few large ones gives a flattering BEI; the reverse gives a harsh one. Read it alongside earned value, never alone. Full page: cpli-and-bei.

🟢 The pattern to notice: Metrics 2, 9 and 12 have no legitimate exceptions — fix them, always. Metrics 1, 5 have exceptions you can count on one hand. Metrics 3, 4, 6, 8, 10 have exceptions that depend on the type of project and should be declared in advance. Metrics 7, 11, 13, 14 are performance indicators dressed as quality checks — failing them may simply mean the schedule is telling the truth.

🟥 Where people go wrong

1. Treating the thresholds as pass/fail. The DCMA guidance itself calls them "trip wires" — a signal to look closer, not a verdict. A reviewer who writes "Metric 6: 7% — FAIL — resubmit" has skipped the part where they look at which activities have high float and whether it makes sense.

2. Gaming the metrics instead of fixing the schedule. Splitting a 60-day activity into two 30-day halves with no meaningful boundary between them. Linking 40 open ends to the finish milestone. Deleting a contractual Finish On or Before because it counted against Metric 5. Each of these improves the score and damages the schedule. Experienced reviewers can tell — the splits have identical names, the links to the finish milestone come from nowhere sensible, the contractual milestone now has 200 days float.

3. Running it on the wrong population. Most metrics are "incomplete activities only." Running the high-float or high-duration check on the whole schedule including completed work gives a different — usually more flattering — percentage. Different tools default differently. Know what your tool is counting, and say so.

4. Running it without the right baseline assigned. Metrics 11 and 14 are meaningless if the project baseline is a what-if from three months ago. Check Project → Assign Baselines first. This is on the monthly checklist for exactly this reason.

5. Forgetting the 6-day calendar. The 44-day thresholds were written for a 5-day week. On a Gulf 6-day calendar, 44 working days is a shorter elapsed period. Some clients adjust to 50 or 55; most don't. Worth raising at the basis-memo stage rather than in month eight.

6. Letting the software do the thinking. Acumen Fuse produces a percentage score. Some clients set a minimum ("schedule must score ≥ 85%"). A schedule can hit 90% by passing the mechanical metrics and failing the ones that matter — no open ends, no leads, beautifully FS, and a CPLI of 0.82 because it's three months late. The score is a summary; the metrics are the information.

7. Running it once. DCMA is a monthly check, not a baseline gate. Metrics 1, 5, 7, 9 drift every update as activities are added, constraints slip in, and actuals get mistyped. Ten minutes a month keeps it clean. Three hours before a submission, when the client has already found the problems, doesn't.

⚖️ When you're challenged

"The schedule fails five of fourteen. Resubmit." Ask which five, and take them one at a time. "Metrics 2 and 9 — agreed, fixed, no argument. Metric 3 — lags at 8%, all concrete cure, basis attached, calendar stated; I'd ask you to accept that or tell me you'd prefer curing as activities. Metric 6 — high float is 6%, all in Phase 3 externals which aren't needed till Q4; grouped list attached. Metric 8 — the 47 activities over 44 days are procurement and fabrication; splitting a transformer manufacture doesn't make it more accurate." Two fixes, three explanations, one resubmission.

"Your CPLI is 0.91. That's a fail." "Yes — because we're 12 days behind with 130 days to go, and CPLI is telling you that accurately. The schedule isn't defective; the project is late. The recovery plan in Section 4 of the narrative brings it back to 0.98 if the two-shift option is approved. That's the decision this month."

"Why does the baseline have any constraints at all?" "Three. Taking Over — Finish On or Before, Cl. 8.2. Site access to the east plot — Start On or After, per Appendix D of the contract. Main switchgear delivery — Start On, per PO 0412's confirmed ship date. All in Section 6 of the basis memo. Everything else is logic."

"Just get it to pass. I don't care how." "I can get it to pass in an hour. It'll involve deleting the three contractual constraints, splitting the fabrication activities into meaningless halves, and linking the procurement open ends straight to completion. The client's planner will see all of that in the comparison and we'll have a harder conversation than the one about the metrics. I'd rather fix the two genuine problems and defend the rest."

📄 Related pages

How to review a schedule — where DCMA sits in a full review, and what it doesn't cover
Schedule quality vs schedule realism — passing all fourteen and still being wrong
Open ends — Metric 1
Leads and lags — Metrics 2, 3
Relationship types explained — Metric 4
P6 Constraint Types — Metric 5
total-float / negative-float — Metrics 6, 7
Activity Duration Limits — Metric 8
Data date — Metric 9
CPLI and BEI — Metrics 13, 14
Gao schedule assessment guide — the more nuanced alternative
Automated schedule checkers — Fuse, Analyzer, and what they get wrong
Template dcma check sheet — the table above, as a download

✏️ Worked example

A baseline submission for a 1,400-activity industrial building in KSA. 6-day calendar. First DCMA run, incomplete activities only.

#	Metric	Result	Threshold	Status	What it turned out to be
1	Logic	3.1% (43)	≤ 5%	Trip-wire	2 milestones legitimate; 41 genuine gaps, mostly submittals not linked to POs
2	Leads	4	0	Fail	Four FS−3 links on finishes. Converted to SS+lag.
3	Lags	9.2%	≤ 5%	Trip-wire	130 relationships. 112 are concrete cure (3d, 24-hr calendar). 18 are FF+10–15 on MEP — work, converted to activities. Revised: 7.6%, all cure, declared.
4	Relationship types	91% FS	≥ 90%	Pass	—
5	Hard constraints	0.9% (12)	≤ 5%	Trip-wire	3 contractual, declared. 9 were Finish On dates copied from tender milestones — removed.
6	High float	8.4% (118)	≤ 5%	Trip-wire	71 in external works, genuinely early. 47 were downstream of the 41 open ends. After Metric 1 fix: 5.1%, all externals. Declared.
7	Negative float	0	0	Pass	—
8	High duration	4.3% (60)	≤ 5%	Pass	All procurement / fabrication. Listed anyway.
9	Invalid dates	0	0	Pass	Baseline — no actuals.
10	Resources	n/a	—	Waived	Spec requires cost loading only at revised baseline stage. Noted.
11	Missed tasks	n/a	—	n/a	No progress yet.
12	Critical path test	Fail	Pass	Fail	Adding 600d to steel erection moved completion by 412d. A Finish On constraint on the substation energisation milestone was absorbing the rest. Removed (it was one of the 9 tender dates). Re-test: 600 → 600. Pass.
13	CPLI	1.00	≥ 0.95	Pass	—
14	BEI	n/a	—	n/a	No progress yet.

What this run actually found: 41 missing links, 4 leads, 18 lags hiding work, 9 non-contractual constraints — and one of those constraints was silently breaking the critical path. None of it was visible on the Gantt chart. All of it was fixable in a day and a half. Two metrics (3, 6) remained over threshold after the fixes and were declared with reasons; the client accepted both on first review.

The revised basis memo carried a one-page DCMA table like the one above — results, threshold, status, and a one-line reason for every trip-wire. That table went in every monthly narrative thereafter. It turned the DCMA review from a monthly argument into a monthly formality.

📖 References

Defense Contract Management Agency, 14-Point Schedule Assessment (2005, as revised); Earned Value Management System Program Analysis Pamphlet (DCMA-EA PAM 200.1), Chapter 3
US GAO, Schedule Assessment Guide (GAO-16-89G) — Appendix (mapping to DCMA metrics)
National Defense Industrial Association, Planning & Scheduling Excellence Guide (PASEG), v3 — Section 10
AACE International, RP 53R-06, Schedule Update Review
Oracle, P6 Professional User's Guide — Schedule Log; Check Schedule

From the field

Experience from working planners. Unreviewed — read it as experience, not guidance.

Add what you know about dcma 14-point assessment. What worked, what the consultant pushed back on, what you would do differently next time. A paragraph is plenty.

Contributors get their name and one link on the site — your own templates, course or consultancy. We take nothing and hold nothing.

Add your experience