How to Read a DCMA 14-Point Report

You just received a DCMA 14-Point Schedule Health Assessment on your construction project. It's got percentages, pass/fail grades, something called a Baseline Execution Index, and a compliance score that doesn't look great. Your scheduler says it's fine. Your owner says it's not. And you need to figure out who's right before tomorrow's OAC meeting.

This guide breaks down what each metric in a DCMA 14-point report actually means, what the scores tell you about your project's real risk, and what to do when your schedule fails.

What Is a DCMA 14-Point Assessment?

The 14-point metrics grew out of the March 2005 U.S. Department of Defense policy that first required an Integrated Master Schedule (data item DI-MGMT-81650) on contracts of $20 million or more (USD(AT&L) memorandum, 7 March 2005). They were last published by the Defense Contract Management Agency in DCMA-EA PAM 200.1, EVMS Program Analysis Pamphlet (October 2012), which is the source cited throughout this article. The 14 criteria check whether a CPM schedule is logically sound, realistically sequenced, and reliable enough to use for management decisions.

Since then, the construction industry has adopted it as the standard schedule quality benchmark, not just for defense projects, but for commercial, institutional, and infrastructure work across North America. If your owner, CM, or legal team is asking for a "schedule health check," this is what they mean.

The 14 Criteria — What Each One Checks

Before any of these percentages mean anything, you have to know which activities are in the population being counted. PAM 200.1 section 4.0 directs that the analysis “should exclude Completed tasks, LOE tasks, Subprojects (called Summary tasks in MS Project), and Milestones.” Two reports on the same file can disagree badly just because one of them left completed work, level-of-effort tasks or milestones in the denominator. If you are comparing two assessments, check the population before you argue about the numbers.

Logic Checks (Criteria 1–4)

C1 – Logic measures the percentage of activities with incomplete logic, meaning a missing predecessor or a missing successor, so they are not properly connected to the rest of the network. The DCMA threshold is 5%. If your report shows 12% incomplete logic, roughly 1 in 8 activities is floating free with nothing driving its start date. Those dates are essentially arbitrary. Missing predecessors and missing successors are both counted under this one check, not as two separate criteria.

C2 – Leads checks for negative lag, where a successor is pulled forward to start before its predecessor finishes. The threshold is 0%: there should be none. A lead compresses the network in a way that is invisible on a bar chart and it distorts the critical path, so it is treated as a defect rather than a tolerance.

C3 – Lags counts every logic link that carries a lag, not just the ones that look excessive. Section 4.3 measures all lagged relationships against a 5% ceiling. Lags often hide real work that should be broken out as separate activities, like saying "wait 14 days" instead of explicitly scheduling submittal review and approval as trackable tasks.

C4 – Relationship Types checks whether the schedule predominantly uses Finish-to-Start (FS) relationships. The threshold is 90% FS. Heavy use of Start-to-Start or Finish-to-Finish relationships often indicates shortcuts in the logic rather than genuine concurrent work.

Schedule Integrity (Criteria 5–8)

C5 – Hard Constraints measures how many activities carry a hard constraint that overrides the schedule's calculated logic. Section 4.5 lists four types, not two: Must-Finish-On, Must-Start-On, Start-No-Later-Than and Finish-No-Later-Than. Threshold: 5%. Hard constraints tell P6 to ignore the math and use a fixed date instead, which means those activities won't shift when upstream work slips.

C6 – High Float checks for activities with total float exceeding 44 working days, against a 5% threshold. Section 4.6 treats high float as a sign that the activity may be missing predecessors or successors, so it is a prompt to go and look rather than a finding on its own. If an activity has 200 days of float, it's essentially saying "this could happen anytime in the next 10 months", which isn't a schedule, it's a wish list.

C7 – Negative Float identifies activities that are already calculated as late before they even start. Any negative float means the schedule's own math says the project can't meet its current dates without changes.

C8 – High Duration flags activities whose baseline duration exceeds 44 working days and whose baseline start falls inside the detail planning period or rolling wave. Both conditions have to be met, and the threshold is 5%. Long durations typically mask multiple work packages that should be broken down for proper tracking and control.

Status & Progress (Criteria 9–12)

C9 – Invalid Dates catches activities where actual dates are in the future or forecast dates are in the past. These indicate the schedule hasn't been properly updated: the data doesn't match reality.

C10 – Resources asks for verification that every activity with a duration greater than zero carries dollars or hours. Zero-duration activities are outside the check. Without resources, you can't perform resource leveling, calculate earned value, or identify overallocation conflicts. Threshold: 0% unassigned. One condition that most reports leave out: the IMS data item description DI-MGMT-81650 does not require a contractor to resource-load the schedule at all, so this metric is only calculated where the contractor has in fact loaded resources.

C11 – Missed Tasks is a finish-only check. Section 4.11 counts activities with a baseline finish on or before the status date whose actual or forecast finish is later than that baseline finish. Starts are not part of it. The threshold is 5%, and the denominator excludes tasks that are missing a baseline start or finish date, which is not how the BEI denominator handles them (see below). A high count means your schedule is optimistic and not reflecting actual field progress.

C12 – Critical Path Test checks that the network responds correctly to delay. Section 4.12 requires only that when you introduce an intentional slip on a critical activity, assuming zero float, the completion date slips in direct proportion. If it doesn't, something in the logic is absorbing the delay and the critical path can't be trusted. The 600-day figure you often see quoted is a common industry test value, not a DCMA one: PAM 200.1 gives no duration for the test.

Performance Metrics (Criteria 13–14)

C13 – CPLI (Critical Path Length Index) compares the remaining critical path duration plus total float to the remaining project duration. Values below 1.0 indicate the schedule is running behind. Note the pinpoint: sections 4.13 and 4.14 carry CPLI and BEI inside the fourteen-check list, but each is a single line that refers the reader onward, so the definitions, formulas and thresholds sit in the metrics chapter at sections 3.1.2.3 and 3.1.2.4. The investigation flag in section 3.1.2.3 sits at below 0.95, not below 1.00, so a CPLI of 0.98 is behind but not yet flagged. This requires a baseline schedule to calculate.

C14 – BEI (Baseline Execution Index), defined at section 3.1.2.4, measures task throughput. The numerator is the cumulative count of tasks completed as of the reporting date; the denominator is drawn from the baseline, and the pamphlet gives two different versions of it, taken up in the next paragraph. What it does not measure is whether tasks finished on time: a task counts the same whether it landed early or late, as long as it was completed before time now. DCMA's on-time measure is a separate metric, Hit Task Percentage, and BEI is always read against it. Below 0.95 is a flag. Also requires a baseline.

PAM 200.1 is internally inconsistent about the BEI denominator, so do not quote any single clean BEI formula, ours included. The boxed formula in section 3.1.2.4 gives the denominator as “Total # of Tasks Completed Before Now + Total # of Tasks Missing Baseline Finish Date”. The eight-step procedure printed alongside it says to divide by the “Baseline Count”. Those are not the same number and the pamphlet does not reconcile them, so neither one can be presented as the formula. If a BEI figure is going into evidence, say which of the two your tool used and show the counts behind it.

Score Ranges: A CPP Reading, Not a DCMA Standard

Be clear about what follows. DCMA publishes no aggregate score, no letter grade and no red/amber/green band. PAM 200.1 reports the 14 metrics individually and stops there. The table below is how we at Critical Path Partners roll those metrics up into one reading for a client, and it is our convention, not part of the standard. It is the scale our Schedule Health Report applies, and the percentage in it is the share of scored criteria the schedule passes. If the other side's report shows a letter grade, ask whose scale it is.

The report also carries a green / yellow / red status band, and that band is computed on its own thresholds rather than off the letter: 85% and above is GREEN, 65% to 84% is YELLOW, below 65% is RED. The two scales do not line up one for one. A schedule passing 80% of criteria grades B but still sits in the YELLOW band, so quote the grade and the band together or neither.

Whatever scale is used, the pamphlet's own caution applies to every individual metric. Section 4.0 says a metric that comes up red “is not in and of itself synonymous with failure but rather an indicator or a catalyst to dig deeper.” A red band is where the conversation starts, not where it ends.

What to Do When Your Schedule Fails

A failed DCMA assessment doesn't mean your project is in trouble. It means your schedule is in trouble — and a bad schedule makes it impossible to see whether your project is in trouble or not.

Priority order for corrections:

1. Fix logic issues first (C1, C2) — everything else depends on the network being connected
2. Remove artificial constraints (C5) — let the schedule calculate dates based on logic
3. Update status (C9, C11) — make sure the schedule reflects reality
4. Break down long durations (C8) — improve tracking granularity
5. Verify critical path (C12) — confirm the math is working