Learning Center
The Complete DCMA 14-Point Assessment Explained
Fourteen checks, each with its own pass/fail threshold, that together answer one question: is this schedule structurally sound enough to trust for forecasting and delay analysis? Below is every check, plus a worked example of one schedule failing four of them.
Why the Assessment Exists
Every delay conclusion drawn from a schedule -- a critical path, a float value, a delay claim -- is only as trustworthy as the schedule it came from. The Defense Contract Management Agency built this 14-point check as a standardized way to catch the structural problems that quietly undermine that trust: missing logic, artificial compression through negative lag, constraints that override the network instead of driving it, and float values that don’t reflect real slack. A schedule can fail a few of these checks and still be broadly usable -- what matters is whether the failures cluster around the specific activities or period a conclusion depends on.
All 14 Checks
Checks 6 and 8 use a threshold in days -- 44 calendar days is the commonly used default for both, but it’s a configurable parameter, not a fixed rule. CPLI and BEI (13 and 14) don’t have an official pass/fail line the way the other twelve do; they’re reported as health indicators against a commonly cited 0.95 floor instead.
1. Logic
< 5% of incomplete activity-links missing a predecessor or successor
Every incomplete task should have at least one predecessor and one successor. Activities floating with no logic tying them to the rest of the network can't have a real early/late date calculated for them at all.
2. Leads (Negative Lag)
0 relationships
A negative lag lets a successor start before its predecessor actually finishes -- often used to artificially compress a schedule without changing the underlying logic or durations.
3. Lags (Positive Lag)
0 relationships
Positive lag isn't inherently wrong (real waiting time -- concrete cure, inspection turnaround -- is a legitimate reason for it), but DCMA's target is zero because lag is easy to abuse as a hidden duration that doesn't show up on the activity it's attached to.
4. Relationship Types
FS ≥ 90%, SS + FF < 10%, SF = 0
Finish-to-Start is the only relationship type that behaves the way most people intuitively read a schedule. A schedule leaning heavily on Start-to-Start or Finish-to-Finish logic is harder to verify and easier to manipulate; Start-to-Finish is almost never legitimate.
5. Hard Constraints
< 5% of incomplete activities
A Mandatory Start or Mandatory Finish constraint overrides the network logic entirely -- the activity will show that date no matter what its predecessors actually do, which can silently mask real delay.
6. High Float
< 5% of activities over the threshold (44 calendar days is the commonly used default)
Float above roughly a month and a half is often a symptom of missing logic, not real scheduling flexibility -- an activity nothing else depends on can show enormous float that doesn't reflect any genuine slack in the actual work.
7. Negative Float
0 activities
Total float should never go below zero on a schedule that's forecasting realistically. Negative float means the network's own logic and durations already show the project finishing later than a required or contractual date.
8. High Duration
< 5% of incomplete activities over the threshold (44 calendar days is the commonly used default)
An activity planned to run longer than about six weeks is hard to track progress on meaningfully -- DCMA's guidance is to break it into smaller, more manageable pieces instead.
9. Invalid Dates
0 activities
Four sub-checks against the schedule's data date: an actual start or finish recorded in the future, or a forecast start/finish left sitting in the past. Any of these means the schedule wasn't actually updated to reflect real progress.
10. Missing Resources or Costs
< 5% of incomplete activities
Incomplete work with no resource or cost assignment can't be tracked for productivity or earned value -- if the schedule tracks resources at all, every real activity should carry one.
11. Missed Tasks
0 activities
Activities whose baseline finish date has already passed, and whose actual or forecast finish is later than that baseline date -- a direct count of tasks that are already behind plan as of the current data date.
12. Critical Path Test
The driving path forms one connected chain
The activities the schedule itself marks as driving the finish date should form a single continuous chain from start to finish, not scattered, disconnected islands -- a broken driving path usually means missing logic on the critical chain itself.
13. Critical Path Length Index (CPLI)
≥ 0.95 is a commonly cited healthy floor (not an official pass/fail line)
CPLI = (Critical Path Length + Total Float) ÷ Critical Path Length, where Critical Path Length is the calendar-day span from the baseline's data date to its finish. A value below about 0.95 suggests the critical path is stretching out relative to the original plan.
14. Baseline Execution Index (BEI)
≥ 0.95 is a commonly cited healthy floor
BEI = (activities actually finished) ÷ (activities the baseline expected to be finished by today's data date). Below 1.0 means completions are falling behind the rate the baseline assumed -- a raw execution-rate measure, not a float-based one.
Worked Example: A Schedule Failing Four Checks
Here’s a simplified seven-activity sequence for a utility-relocation-and-foundation package, as of a data date partway through construction. Four separate problems show up in the total float column alone.
| Code | Activity | Duration | Total Float | DCMA Flag |
|---|---|---|---|---|
| A | Mobilization | 5 d | 0 d | — |
| B | Site utilities relocation | 55 d | 0 d | High duration |
| C | Excavation | 8 d | 62 d | High float |
| D | Drilled pier foundations | 18 d | -6 d | Negative float |
| E | Structural steel erection | 25 d | 0 d | — |
| F | MEP rough-in | 20 d | 4 d | — |
| G | Substantial completion | 0 d | 0 d | — |
What’s wrong, and how each gets fixed
- B — High Duration (Check 8)
- 55 days for a single utility-relocation activity is too coarse to track meaningfully. Fix: break it into discrete segments (e.g. by manhole run or utility type) so progress and delay can be attributed to a specific piece of work, not one giant multi-month line item.
- C — High Float (Check 6)
- 62 days of float on an excavation activity this early in the sequence is a red flag for missing logic, not genuine schedule slack. Fix: check whether excavation should actually be tied as a predecessor to more of the downstream foundation work than it currently is.
- D — Negative Float (Check 7)
- Negative float means the network already shows this finishing later than a downstream constraint or contract date allows. Fix: this is the one flag that isn’t a schedule-quality issue to clean up -- it’s a real, current problem that needs a recovery plan or an accepted schedule slip, not a logic correction.
Running all 14 checks by hand on a real, multi-thousand-activity schedule isn’t practical. Claims Digger runs the full DCMA 14-point assessment automatically against an uploaded schedule, reporting pass/fail for every check with the specific activities driving each failure -- including CPLI and BEI trended against a baseline you set once. See how it works.
Frequently Asked Questions
- Is the DCMA 14-Point Assessment mandatory?
- It originated as a Defense Contract Management Agency requirement for certain federal contracts, but it's now used far more broadly -- by owners, contractors, and forensic analysts on private projects -- as a general-purpose schedule quality check, whether or not a contract specifically requires it.
- Does failing a check mean the schedule is unusable?
- No. Failing one or two checks on a large, complex schedule is common and not automatically disqualifying. What matters is whether the failures cluster in a way that undermines a specific conclusion -- for example, heavy use of constraints and high float sitting right on the activities driving a disputed delay claim.
- What's the difference between CPLI and BEI?
- CPLI is float-based -- it asks whether the critical path itself is stretching out relative to baseline. BEI is a raw completion-rate measure -- it asks what fraction of the work the baseline expected to be done by now is actually done, independent of float or the critical path.
- Why do high float and high duration both use 44 days by default?
- 44 calendar days (roughly six weeks) is simply a commonly used default threshold in DCMA guidance for both checks -- it isn't a coincidence that they match, but the two checks measure different things: one flags activities with too much slack, the other flags activities planned to take too long to track meaningfully.
Part of the Claims Digger Learning Center. Related reading: Every check, one by one · CPLI · BEI · Full glossary