The DCMA 14-point check, explained for subs and small GCs

The Defense Contract Management Agency developed this checklist to test whether a CPM schedule is mechanically sound enough to trust. It doesn't ask whether your plan is good, only whether the network behaves like one: activities tied together, logic driving the dates, float and a critical path that mean something. Government reviewers use it on federal submittals, and owners and their consultants increasingly run it on private work. Run it first and clear the flags before the review does.

Why a mechanical check decides real money

A schedule that fails the mechanics fails everything downstream. Missing logic means dates held up by guesses. Junk float hides which paths are exposed. A critical path that doesn't respond to a slip leaves your time extension request with nothing credible underneath. On federal work a baseline that trips the checks can bounce at review, and an unaccepted baseline holds up progress payments. On private work the same flags give the owner's reviewer easy reasons to reject your schedule, or later your delay analysis.

Each check, in plain terms

The first group tests whether the network is wired together:

• 1. Logic. Activities missing a predecessor or successor. Threshold: no more than 5 percent. An open end is a date floating free of the network.
• 2. Leads. Negative lags, where a successor starts before its predecessor relationship allows. Target: zero. Leads hide work behind the logic and distort the float.
• 3. Lags. Positive lags on relationships, no more than 5 percent. A lag is invisible, unstatusable waiting time. If something real happens in that gap, make it an activity.
• 4. Relationship types. At least 90 percent finish-to-start. FS logic is the easiest to read, status, and defend. Heavy SS and FF webs make sequences hard to verify.
• 5. Hard constraints. No more than 5 percent. Mandatory dates override logic, and a schedule steered by constraints cannot show what is driving completion.

The second group tests whether the dates and float are believable:

• 6. High float. Activities with total float above 44 working days, no more than 5 percent. Huge float usually means missing logic, not real slack.
• 7. Negative float. Target: zero. The network already cannot meet a constrained date, and the schedule is projecting a miss it has not explained.
• 8. High duration. Activities with remaining duration over 44 working days, no more than 5 percent. Long bars hide sequence and make progress unmeasurable.
• 9. Invalid dates. Target: zero. No actual dates in the future, no forecast dates in the past. Either means careless statusing, and it poisons trust in everything else.
• 10. Resources. Activities with durations should carry resources or costs where the contract requires loading. On cost-loaded federal schedules this check ties straight to the payment side.

The last group tests performance against the plan:

• 11. Missed tasks. Activities due by the data date that finished late or are still open, measured against those due. Target: no more than 5 percent. A rising miss rate is the early warning that plan and job are separating.
• 12. Critical path test. Push a critical activity and the completion date should move with it. If not, the path is broken, usually by constraints or open ends.
• 13. Critical path length index (CPLI). A ratio testing whether the remaining critical path, with the float it carries, can realistically make the finish date. Target: 0.95 or better.
• 14. Baseline execution index (BEI). Tasks completed versus tasks planned to be complete. Target: 0.95 or better. Below that, the job is falling behind the baseline no matter what the narrative says.

Run it before the owner does

Every check runs in minutes with the right setup, and almost every flag is fixable before submittal: close open ends, replace lags with real activities, strip stray constraints, break down long bars, clean the statusing. That cuts the avoidable comments that get a baseline returned and stall a pay application. On federal work we run all 14 points on every baseline and update before it goes to the government, because most reviewers will run it anyway. The same discipline is part of the health check in our subcontractor schedule protection scope, where a sub can check whether the GC's network deserves their trust.

Field notes the checklist will not give you

• Run check 12 by hand, not just the metric. Copy the schedule, add 600 days to a known critical activity, and recalculate. The finish should move about 600 working days, adjusted for calendars. If it moves 200, constraints, open ends or settings are absorbing the rest, and the float values need a hard look. Two minutes, and it tells you more than the other thirteen checks.
• Flags travel in packs. High float, missing logic, and a failed path test are usually one defect wearing three costumes: open ends. Fix the logic first, then rerun the checks to see which related flags remain.
• Keep a constraint register. One line per surviving constraint: what it is, the contract clause or milestone that justifies it, and why logic can't replace it. Attach it to the submittal. Reviewers who get answers before asking approve faster, and it carries to every update.
• Watch the out-of-sequence count on updates. The 14 points test the static file, but each update quietly re-answers check 12 through out-of-sequence handling. Retained logic versus progress override can put the critical path in two places on the same data date. Know which setting your spec expects, use it consistently, and state it in the narrative.
• Score trend beats score. A baseline at two flags that drifts to nine by update six is being maintained by force instead of logic. Chart the flag count month over month. Reviewers rarely do, which is why you should.

What the check does not tell you

This tool gets oversold, so two limits. First, passing all fourteen points doesn't make a schedule a good plan. The mechanics can be perfect while the sequence is wrong, durations fantasy or crew flow impossible. The check is a floor, not a finish line. Schedule development is the subject of AACE RP 91R-16, a bigger conversation than fourteen metrics.

Second, a flag is a question, not automatically a defect. A hard constraint on a contract milestone, a lag modeling real curing time or a long procurement activity can each be legitimate. Reviewers want few flags, each explained. What kills credibility is a schedule where nobody can say why the flags are there.

Frequently asked questions