The DCMA 14-Point Schedule Check, Explained

Quick answer: The DCMA 14-point check is a set of fourteen metrics, originally developed by the Defense Contract Management Agency, used to assess the structural health of a CPM schedule — covering logic, constraints, lags, float, duration, dates, resources, and critical path integrity — independent of whatever the schedule claims about progress.

What the DCMA 14-Point Check Is

The DCMA 14-point assessment is a schedule quality review originally developed by the US Defense Contract Management Agency to evaluate whether a contractor's integrated master schedule is logically sound enough to be relied upon. It does not assess whether a project is on time — it assesses whether the schedule itself is built well enough that its float, critical path, and forecast dates mean anything. A schedule can show a project finishing on time and still fail most of these checks, which is exactly the scenario the assessment is designed to catch.

Although it originated in a defense-acquisition context, the same fourteen metrics are now widely used well beyond that setting, including by public agencies and private owners reviewing construction schedules, because they test fundamentals that apply to any CPM network regardless of industry.

The Fourteen Metrics, Explained

1. Logic. Checks for missing predecessor or successor relationships — activities that are "open-ended." A schedule with a meaningful number of open ends cannot reliably calculate float or the critical path.
2. Leads. Checks for negative lag (a successor allowed to start before its predecessor finishes). Leads are generally discouraged because they distort logic in ways that are hard to audit and can be used to artificially compress the schedule.
3. Lags. Checks for excessive use of lag time on relationships. A commonly cited guideline treats lag used on more than a small percentage of relationships (often cited around 5%) as worth scrutinizing, since lag is sometimes used to substitute for an activity that should be modeled explicitly.
4. Relationship types. Checks the proportion of relationship types used — finish-to-start relationships are the industry norm, and a schedule relying heavily on start-to-start or finish-to-finish logic without justification is flagged for review.
5. Hard constraints. Checks for the use of Must-Start-On, Must-Finish-On, and similar constraints that override calculated dates. Hard constraints on activities other than contract milestones restrict float artificially and are a central focus of the review.
6. High float. Checks for activities carrying an unusually large amount of total float, which can indicate a missing logic tie rather than genuinely low-priority work.
7. Negative float. Checks for activities with negative total float, meaning the schedule is already calculating that the project will miss a required date based on current logic and constraints.
8. High duration. Checks for activities with unusually long durations relative to the rest of the schedule. Long, undifferentiated activities obscure what is actually happening on the critical path and make progress harder to verify.
9. Invalid dates. Checks for actual start or finish dates that fall after the schedule's data date, which would mean progress is being reported ahead of when it could have actually occurred.
10. Resources. Checks whether resources are assigned to activities, since a schedule with little or no resource assignment cannot support meaningful resource-loaded analysis or earned value reporting.
11. Missed tasks (missed activities). Checks how many activities finished later than their baseline finish date, as a measure of how well the contractor is executing against its own plan.
12. Critical path test. Checks whether a deliberate delay inserted into a single activity on the stated critical path actually pushes the project completion date, confirming the critical path calculation is behaving as it should.
13. Critical path length index (CPLI). Compares the length of the critical path to the critical path plus total float remaining to project completion, as a measure of how efficiently the schedule is using its available time.
14. Baseline execution index (BEI). Compares the number of activities actually completed to the number that should have been completed by now according to the baseline, as a measure of overall execution pace against the original plan.

Where a specific metric is tied to a commonly cited numeric guideline — such as the lag threshold above — that figure is a general industry convention rather than a universal legal or contractual standard, and the controlling specification for a given contract always takes precedence.

How to Use the Check Yourself

1. Run the fourteen metrics against your own schedule before submission, rather than waiting for a reviewer to flag them.
2. Treat results holistically — a single metric slightly out of range rarely sinks a schedule, but several metrics failing together signals a schedule that was not built or maintained carefully.
3. Investigate the underlying cause of each flagged item rather than adjusting the schedule just enough to pass the metric. A hard constraint removed without fixing the logic underneath it will usually surface as a different problem on the next check.
4. Re-run the check after every major update, not only at baseline, since logic degrades over time as updates are applied under schedule pressure.

Many of these same fundamentals are what owner and agency reviewers check when deciding whether to accept a Primavera P6 baseline — see how to get a Primavera P6 baseline schedule accepted and the most common Primavera P6 schedule errors for the practical side of the same issues.

Keep reading