What a DCMA 14-point assessment actually catches

The Defense Contract Management Agency published a set of fourteen quantitative schedule health metrics that has quietly become the closest thing the industry has to a common language for whether a schedule is structurally sound. It takes about a minute to run and it is remarkably good at finding the specific defects that make a network produce confident, wrong answers.

It is worth knowing what it checks, and equally worth knowing what it cannot see.

The fourteen checks

They divide reasonably neatly into four groups.

Is the network actually connected

• Logic. Activities missing a predecessor or a successor. Target is under five percent. A dangling activity is floating free of the calculation and its dates mean nothing.
• Relationship types. Finish to start should be at least ninety percent. Heavy use of start to start and finish to finish usually signals a network held together by overlaps rather than by real sequence.
• Leads. Negative lags, which pull a successor forward. Target is zero. A negative lag is a modeling shortcut that breaks the logic it appears to express.
• Lags. Positive lags on more than five percent of relationships. Often a cure time or a submittal turnaround that would be better modeled as its own activity, where it can be progressed and seen.

Is anything overriding the calculation

• Hard constraints. Under five percent. Every mandatory date is a place where the software has been told to stop calculating and obey an instruction instead.
• High float. Activities with more than forty-four working days of total float, under five percent. Almost always a symptom of missing successors rather than genuine slack.
• Negative float. Target zero. Anything else means the network cannot reach a date it has been told to reach.
• Invalid dates. Actual dates in the future or forecast dates in the past. Both indicate the update was not progressed properly.

Is it granular enough to manage

• High duration. Remaining durations over forty-four working days, under five percent. A ninety day activity cannot be meaningfully progressed and hides its own slippage until it is far too late.
• Resources. Whether activities carry resource or cost loading, where the contract requires it.
• Missed tasks. Activities that finished later than their baseline finish. Under five percent.

Does it behave correctly

• Critical path test. Deliberately add a large delay to a critical activity and confirm the completion date moves by the same amount. If it does not, the network is broken somewhere upstream, and this single test finds problems the other thirteen checks miss.
• Critical path length index. Whether the remaining critical path can realistically be achieved. Below one means efficiency has to improve for the date to hold.
• Baseline execution index. The proportion of baseline activities completed against those that should have been. A blunt but honest measure of whether the plan is being followed.

What it catches

In practice the assessment reliably surfaces four failure patterns. Networks that are not really networks, held together by constraints rather than logic. Schedules with enormous activities that cannot be progressed honestly. Updates that were typed rather than progressed, which invalid dates expose immediately. And schedules whose critical path does not drive the completion date at all, which is more common than most people would guess and which the critical path test finds in seconds.

Any one of those makes every date in the file unreliable. Finding them takes a minute.

What it does not catch

This is the part that gets skipped, and it matters more than the checks themselves. The assessment is entirely structural. It has no opinion whatsoever about whether the schedule is true.

• Durations. A schedule that allows six days for a concrete pour that will take sixteen passes every one of the fourteen checks.
• Sequence. Logic that is well formed and physically impossible scores perfectly. The software cannot see that the crane has to come down before that wall goes up.
• Completeness. Work that is missing from the network entirely is invisible to a test that only examines what is present.
• Resource reality. Without leveling, nothing here notices that the plan needs four tower cranes on a site with two.

So a schedule can score fourteen out of fourteen and still be fiction. We have seen it. The assessment is a necessary filter, not a sufficient one, and treating a clean scorecard as approval is a mistake owners make regularly.

How to use it

Run it every period, not just at baseline acceptance, and trend the results. A schedule whose constraint count climbs steadily over six months is telling you something important about how it is being maintained.

Report exceptions with explanations rather than as a pass or fail score. Some are legitimate. A genuinely contract-mandated milestone date is a hard constraint and should be. What matters is that every exception is deliberate, identified and defensible, rather than accidental and unexamined.

Then, and only then, have somebody who has actually built the work read the schedule and say whether the durations and the sequence make sense. That review is not automatable, it is where the real errors live, and no metric will ever replace it.