DCMA 14-Point Assessment explained · with a worked P6 example

Most large programmes do not drift because anyone lies. They drift because the schedule quietly stops being a model of the work and becomes a document written to protect dates. Logic gets deleted, constraints multiply, and float evaporates into a handful of activities nobody looks at. The DCMA 14-point assessment exists to catch this, structurally, and early.

Developed by the U.S. Defense Contract Management Agency, it is fourteen mechanical tests of schedule quality, not of whether the dates are achievable, but of whether the network is built well enough to be trusted. Run monthly rather than only at claim time, it turns schedule integrity from an argument into a measurement.

What are the 14 DCMA checks, and how do they group?

Network logic (checks 1 to 5)

• Logic, activities missing predecessors or successors (target: <5%). Dangling activities are the single most common defect.
• Leads, negative lag. Target: zero. A lead usually hides missing logic.
• Lags, excessive positive lag used instead of real activities (target: <5%).
• Relationship types, the network should be at least 90% Finish-to-Start. Too many SS/FF relationships obscure the true critical path.
• Hard constraints, date constraints that override logic (target: <5%). Each one is a place where the schedule stops calculating and starts asserting.

Float & realism (checks 6 to 10)

• High float, activities with total float > 44 working days often signal broken or missing logic.
• Negative float, target: zero. Negative float means the schedule already knows it is late.
• High duration, activities longer than 44 days should be decomposed.
• Invalid dates, forecast dates in the past or actuals in the future (target: zero).
• Resources, resourced activities should carry cost or hours.

Executability (checks 11 to 14)

• Missed tasks, activities slipping behind baseline (target: <5%).
• Critical path test, deliberately push an activity and confirm the critical path reacts. A path that does not move is not really critical.
• CPLI (Critical Path Length Index), critical path length plus total float, divided by critical path length. Below 0.95 means the programme is losing efficiency against its finish.
• BEI (Baseline Execution Index), tasks actually completed divided by tasks that should have completed by the data date. Below 0.95 means the team is falling behind the plan.

How do you run the DCMA 14-point assessment in Primavera P6?

The assessment is only as good as the file and the population it is run on. This is the sequence we use on a native P6 file.

1. Take the native file, not a PDF. Export the current update as XER (or XML) together with the baseline it is measured against. BEI and the missed-task check are meaningless without the right baseline assigned in P6.
2. Set the population. Most checks count incomplete normal activities. Exclude level-of-effort activities, WBS summaries and milestones from the duration and float counts, and state the exclusions in the report so the result can be reproduced.
3. Logic, leads, lags and relationship types (checks 1 to 4). Work from the relationships export: open ends, negative lags, positive lags and the share of Finish-to-Start links. Treat the project start and finish milestones as the only legitimate open ends.
4. Hard constraints (check 5). In P6 these are Mandatory Start and Mandatory Finish, Start On, Finish On, and the On or Before constraints. Each one should have a documented reason, such as a contractual access date.
5. Float, duration and dates (checks 6 to 10). Read total float and remaining duration in working days against the 44-day thresholds, and look for forecast dates before the data date or actuals after it.
6. The critical path test (check 12). Add a large duration to one activity on the longest path, reschedule, and confirm the project finish moves by the same amount. If it does not, the path is broken somewhere and the reported critical path cannot be relied on.
7. CPLI and BEI (checks 13 and 14). Calculate both at the data date and track them month by month. A single reading says little; the trend says a great deal.

Built-in schedule checks and add-on tools will report most of these numbers in seconds. The judgement is in the population, the exclusions and the critical path test, which is where an automated score most often flatters a weak programme.

What does a failing DCMA result look like in practice?

Take a 1,200-activity civils programme. On paper it shows completion on the contract date. The DCMA run tells a different story: 11% of activities have no predecessor logic, there are 38 hard constraints, and the BEI is 0.82. Read together, those three numbers say the schedule has been pinned to the contract date with constraints while the work itself is running roughly 18% behind. The "on-time" finish is an artefact of the constraints, not of the logic.

Any month where the critical path changes without a corresponding change event is a month that gets a forensic look. It costs a day. The alternative costs an arbitration.

That is the value of the assessment: it makes the problem visible while it is still a management problem, months before it becomes a dispute. Planners tidy the logic they know will be tested; boards ask questions while the answers can still change the outcome.

When do we run the DCMA 14-point assessment on a P6 file?

We run all 14 DCMA tests, plus the GAO and NASA checks and a full critical-path register, against the native Primavera P6 file as the first step of every programme review. For live mandates we pair it with independent forensic delay analysis so the numbers are read the way a tribunal will read them.