The DCMA 14-point assessment is a set of 14 standardized checks that measure whether a project schedule is built well enough to be trusted for forecasting and delay analysis. It grades network logic, constraints, float, durations, date integrity, and two forward-looking metrics (CPLI and BEI) against published thresholds. A schedule that passes is not necessarily correct, but one that fails is almost certainly hiding broken logic, wishful dates, or a critical path that does not behave the way it should.
Below is what each check measures, the threshold it is judged against, why it matters on a real construction programme, and how to act when a schedule fails.
What is the DCMA 14-point assessment?
The assessment originated with the US Defense Contract Management Agency (DCMA) as a way to sanity-check contractor schedules before relying on them. It is now the de facto quality baseline across construction, engineering, and infrastructure, defense contract or not. Owners, PMCs, and delay experts use it because it is objective, tool-agnostic, and repeatable: run the same 14 checks on any Primavera P6, Microsoft Project, or XER file and you get comparable numbers.
A key point that gets lost: the DCMA 14-point is a structural health check, not a strategy check. It will not tell you your sequencing is wrong, your durations are optimistic, or your procurement is late. It tells you whether the schedule is mechanically sound enough for those judgments to be reliable in the first place. It is the pre-flight checklist, not the flight plan.
The 14 checks at a glance
| # | Check | What it flags | Common threshold |
|---|---|---|---|
| 1 | Logic | Incomplete tasks missing a predecessor and/or successor | ≤ 5% |
| 2 | Leads | Negative lag on relationships | 0 (none allowed) |
| 3 | Lags | Relationships carrying positive lag | ≤ 5% |
| 4 | Relationship Types | Share of links that are Finish-to-Start | ≥ 90% FS |
| 5 | Hard Constraints | Incomplete tasks with date-locking constraints | ≤ 5% |
| 6 | High Float | Incomplete tasks with total float > 44 working days | ≤ 5% |
| 7 | Negative Float | Tasks with total float below zero | 0 (none allowed) |
| 8 | High Duration | Incomplete tasks longer than 44 working days | ≤ 5% |
| 9 | Invalid Dates | Forecast dates before, or actuals after, the data date | 0 (none allowed) |
| 10 | Resources | Tasks with duration but no cost or resource assigned | 0 (if resource-loaded) |
| 11 | Missed Tasks | Tasks that slipped past their baseline finish | ≤ 5% |
| 12 | Critical Path Test | Whether an injected delay flows to project completion | Pass/Fail |
| 13 | CPLI | Efficiency of meeting the finish date | ≥ 0.95 |
| 14 | BEI | Baseline throughput (tasks completed vs planned) | ≥ 0.95 |
The 44-working-day figure in checks 6 and 8 is simply two months of work, the line between a normal activity and a suspiciously large one.
Network logic checks (1–5)
These five decide whether your schedule is a genuine network or just a list of dates.
1. Logic — missing predecessors and successors. Every activity except the true start and finish should have at least one predecessor and one successor. An open end means an activity is not driven by anything, or is driving nothing, so it floats free and corrupts the critical path calculation. The threshold allows up to 5% of incomplete tasks to have a missing link, but you are really aiming for zero real open ends (milestones aside).
2. Leads (negative lag). A lead is a negative lag — telling the engine a successor can start before its predecessor finishes. DCMA allows none. Leads distort float and often mask sequencing the planner did not want to model honestly. If Activity B can genuinely start partway through Activity A, split A into two activities and link them properly.
3. Lags. Positive lag (a deliberate wait between two linked activities) is not banned, but no more than 5% of relationships should carry it. A 10-day lag for "concrete cure" is really an activity that deserves its own bar, duration, and calendar. Excessive lag makes a schedule hard to audit and impossible to resource properly.
4. Relationship types. At least 90% of links should be Finish-to-Start (FS). Start-to-Start (SS) and Finish-to-Finish (FF) are legitimate for overlapping work, but heavy use of them (and any Start-to-Finish, SF) usually signals a planner forcing the network to produce a desired date rather than modeling real dependencies.
5. Hard constraints. No more than 5% of incomplete tasks should carry a hard, date-locking constraint (Must Finish On, Mandatory Start/Finish, and similar). Hard constraints override logic: the activity sits on its date no matter what happens upstream, which is exactly what breaks a dynamic schedule. Prefer soft constraints (Start On or Later), or model the real driver with logic.
Float and duration checks (6–8)
6. High float. No more than 5% of incomplete tasks should have total float above 44 working days. Very high float almost always means missing successor logic: the activity has nothing downstream pulling on it, so the engine gives it enormous slack. It is really check #1 showing up as a symptom.
7. Negative float. No activity should have negative total float. Negative float means the schedule mathematically cannot meet a deadline given its current logic and constraints — work is forecast to finish after a date it is required to hit. It demands either a recovery plan or a constraint that no longer reflects reality.
8. High duration. No more than 5% of incomplete tasks should be longer than 44 working days. Long activities hide progress: a single 120-day bar tells you nothing about whether it is on track. Break them into shorter, measurable pieces so earned progress is meaningful.
Data integrity checks (9–11)
9. Invalid dates. No forecast (remaining) work should be dated before the data date, and no actual dates should fall after it. An actual start in the future or remaining work in the past is a scheduling impossibility that usually points to a statusing error or a data date that was not advanced. The threshold is zero.
10. Resources. On a resource- or cost-loaded schedule, every activity with a duration should have hours, cost, or resources assigned. An activity that consumes time but no resources is miscoded or missing its loading. This check is conditional — it applies only if the schedule is meant to be resource-loaded — so a purely time-based programme shows it as not applicable.
11. Missed tasks. No more than 5% of tasks should have slipped past their baseline finish date without completing. This is the assessment's slippage gauge: a rising missed-task percentage warns that the programme is falling behind its own plan, activity by activity, before the summary dates move.
Schedule realism metrics (12–14)
The final three are not simple counts; they test whether the schedule behaves correctly and is keeping up.
12. Critical path test. This verifies the logic is continuous end to end. The classic method: inject a large delay (600 days is common) into an activity on the critical path and recalculate. If project completion moves by roughly the same amount, the critical path is intact. If it barely moves, the logic is broken somewhere — an open end, a constraint, or a broken chain is absorbing the delay. A schedule that fails this test cannot be trusted for any forecast, because its critical path is not real.
13. CPLI (Critical Path Length Index). CPLI measures how efficiently you can hit the finish date. It is calculated as (critical path length + total float) ÷ critical path length. A CPLI of 1.00 means you are exactly on plan; the threshold is 0.95, meaning you have less than about 5% slack against the deadline. Below 0.95 signals the schedule is tightening and recovery is getting harder.
14. BEI (Baseline Execution Index). BEI measures throughput: tasks actually completed divided by the number that should have been completed by now per the baseline. A BEI of 1.00 means you are finishing work as fast as planned; the threshold is 0.95. A BEI of 0.80 means you are completing only 80% of the planned volume of work, a clear productivity problem regardless of what the summary dates say. CPLI is about the deadline, BEI about the pace — a programme can look fine on dates while BEI reveals it is falling behind.
How do you run a DCMA 14-point check?
Manually, a planner exports activity, relationship, constraint, and float data and works through each check with filters and formulas in Primavera P6, Microsoft Project, or a spreadsheet. It is doable, but slow, error-prone, and has to be repeated every update cycle, which is why most teams automate it.
For a fast, no-sign-up read on a file, the free DCMA-14 quality checker scores an XER, P6, or MPP schedule in the browser and shows each check pass or fail with the offending activities. For teams that live in their schedules, Kazinex Planner runs the full DCMA 14-point plus 30+ additional quality checks alongside the interactive Gantt, editor, and AI copilot — so you can find a failing check, fix the underlying logic in the same place, and re-run instantly.
How to act on failures
Do not chase the percentages for their own sake: a schedule tuned only to pass DCMA is easy to build and useless. Work in this order:
- Fix logic first (checks 1, 2, 4, 12). Open ends and broken chains cause the most downstream damage, and they inflate high float (6) as a side effect. Fixing logic often clears several checks at once.
- Justify or remove constraints (5, 7). Every hard constraint and every negative-float activity needs an owner and a reason. Replace with logic where you can; where a constraint is real, document it.
- Decompose the big items (3, 8). Turn lags and 44-day-plus activities into properly modeled, statusable work.
- Treat CPLI/BEI (13, 14) as management signals, not fields to fix. You do not "correct" a low BEI in the file — you address the reality behind it.
Run the assessment every update cycle and track the trend. A single snapshot tells you the schedule's structural quality today; the trend across months tells you whether the programme is drifting.
Frequently asked questions
What is a passing score on the DCMA 14-point assessment? There is no single pass/fail grade: each of the 14 checks has its own threshold (most sit at 5%, several at 0), and a healthy schedule meets all of them, with checks 12–14 given the most weight because they test whether the network actually works.
Does the DCMA 14-point check apply to Microsoft Project as well as Primavera P6? Yes. The 14 checks are logic-and-metric based, so they apply to any CPM schedule (P6, Microsoft Project, or an XER/MPP export) regardless of the tool that produced it.
What is the difference between CPLI and BEI? CPLI measures how efficiently you can still meet the finish date (deadline pressure), while BEI measures how much planned work you are actually completing (execution pace); both use a 0.95 threshold and are strongest read together.
Can a schedule pass all 14 checks and still be bad? Absolutely — the assessment checks structure, not strategy, so a schedule can be mechanically clean while having wrong sequencing, unrealistic durations, or missing scope. The DCMA 14-point is a starting point for review, not a substitute for it.