2026-10-14 · 5 min read

The DCMA 14-Point Schedule Assessment Explained in Plain English

If you have had a programme reviewed by a client, a project controls team or a claims consultant, there is a good chance someone ran a DCMA 14-point check on it. The checks come from the US Defense Contract Management Agency, which developed them to assess the quality of contractor schedules on defence programmes. They have since spread well beyond defence and are now a common baseline for schedule health on large construction projects.

The checks are useful, but they are often treated as a pass/fail exam. They are better used as a list of questions. Below I go through each of the 14 points in plain English, give the commonly quoted threshold, and say what I actually look for when one fails.

A note on thresholds: the figures below are the ones widely used in practice and built into most schedule analysis tools. Your client or contract may set different limits, so check what you are being measured against.

1. Logic

What it checks: the percentage of incomplete activities missing a predecessor, a successor, or both. Common threshold: under 5%.

Every activity, apart from the project start and finish, should be linked into the network on both sides. Missing logic is the single biggest cause of unreliable float and critical paths. When this fails, I fix it first, because most of the other checks will not mean much until it is fixed.

2. Leads

What it checks: relationships with a negative lag. Common threshold: zero.

A lead says "start this before that one finishes, by X days". It is hard to understand and hard to progress. If work genuinely overlaps, a start-to-start link with a positive lag, or splitting the activity, is usually clearer.

3. Lags

What it checks: the percentage of relationships with a positive lag. Common threshold: under 5%.

Lags are not wrong, but they hide information. A 10-day lag might be curing time, a design review or a delivery. If it represents something real that can slip, it is usually better as an activity.

4. Relationship types

What it checks: the percentage of finish-to-start relationships. Common threshold: at least 90% finish-to-start.

Finish-to-start logic is the easiest to read and to progress. Heavy use of start-to-start and finish-to-finish links is not automatically wrong, but it tends to make the critical path harder to follow. Start-to-finish links are rare and usually a sign that something has gone wrong.

5. Hard constraints

What it checks: the percentage of activities with constraints that stop the schedule from moving with its logic, such as mandatory start, mandatory finish, start on or finish on. Common threshold: under 5%.

Hard constraints override the network. Used on genuine fixed dates, such as a utility connection window, they are fine. Used to make a programme "look right", they hide real slippage.

6. High float

What it checks: the percentage of incomplete activities with total float greater than 44 working days. Common threshold: under 5%.

Forty-four working days is roughly two months. Lots of activities with more float than that usually means missing successors, not genuine flexibility. I sort by total float and look at the top of the list. The cause is usually obvious within a few minutes.

7. Negative float

What it checks: activities with total float below zero. Common threshold: zero.

Negative float means the schedule, as built, cannot meet a constrained date. It is not a fault in the schedule. It is information. The test fails to make sure someone has looked at it and has a recovery plan or an explanation.

8. High duration

What it checks: the percentage of incomplete activities with a remaining duration over 44 working days. Common threshold: under 5%.

Long activities are hard to progress and hide the detail of what is happening. Level-of-effort activities, procurement lead times and some summary-style tasks can reasonably be long. Construction work activities usually should not be.

9. Invalid dates

What it checks: forecast dates before the data date, or actual dates after the data date. Common threshold: zero.

A forecast start in the past means the activity should have started but has not been progressed or rescheduled. An actual date in the future is impossible. Both usually come from incomplete updating.

10. Resources

What it checks: the percentage of activities with duration that have no resources or cost assigned. Common threshold: this depends on the contract, and many construction programmes are not resource loaded at all.

If the contract requires a resource-loaded or cost-loaded schedule, this matters. If it does not, many reviewers simply note it and move on.

11. Missed tasks

What it checks: the percentage of activities that should have finished by the data date, according to the baseline, but did not. Common threshold: under 5%.

This measures performance, not structure. A high figure means the project is not delivering to its baseline. It points you to where the plan and reality diverged.

12. Critical path test

What it checks: whether the schedule responds correctly when you add a large delay to a critical activity. The project finish should move by the same amount.

If it does not move, something is breaking the critical path: a constraint, an open end or a calendar problem. This is one of the most useful checks on the list because it tests whether the network actually works.

13. Critical Path Length Index (CPLI)

What it checks: a ratio of the remaining critical path length plus total float to the remaining critical path length. Common threshold: 0.95 or higher.

A CPLI of 1.0 means the project is exactly on track to meet its target finish. Below 1.0 means the remaining work needs to go faster than planned. It is a quick read on how realistic the end date is.

14. Baseline Execution Index (BEI)

What it checks: the number of tasks actually completed divided by the number of tasks that should have been completed by the data date according to the baseline. Common threshold: 0.95 or higher.

BEI is a simple measure of throughput against the plan. A BEI drifting down update after update is an early warning that the end date is at risk, even if the critical path has not moved yet.

How to use the checks sensibly

Fix structure before performance. Checks 1 to 9 and 12 are about how the schedule is built. Checks 11, 13 and 14 are about how the project is performing. There is no point analysing performance on a schedule with broken logic.

Read the failures, not just the score. A schedule with 6% lags might be perfectly sound. A schedule with 2% open ends might have every one of them on the critical path. The percentage is a prompt to look, not a verdict.

Watch the trend. Running the checks at every update and comparing them is more valuable than any single result. Logic quality usually degrades over the life of a project as people add activities in a hurry.

Explain the exceptions. If you have a good reason for a hard constraint or a long activity, write it down in the schedule narrative. Reviewers are usually reasonable when they can see the reasoning.

Tools

You can run most of these checks yourself with filters and a spreadsheet. Dedicated schedule analysis tools automate them and add trend reporting. Whatever you use, it is worth understanding what each check is doing, so you can explain a result when you are asked about it.

I am putting together a one-page schedule health checklist based on these points, written for construction programmes rather than defence projects. Newsletter subscribers will get it first.