The DCMA 14-point schedule assessment, check by check

What the DCMA 14-point assessment is and where it came from

The Defense Contract Management Agency (DCMA) administers US Department of Defense contracts. On programmes that require Earned Value Management, the contractor’s Integrated Master Schedule is the basis of every forecast, so the agency needed a repeatable way to judge whether a submitted schedule was built well enough to be trusted. The fourteen checks are that test, set out in the agency’s Earned Value Management System Program Analysis Pamphlet and applied in its compliance reviews since.

They spread beyond defence because they measure things any critical-path schedule has to get right: activities tied into a network, few hard constraints and lags, plausible float, dates on the correct side of the progress date, and completions that track the baseline. Owners, PMOs and lenders on infrastructure, resources, energy and building programmes now write the fourteen checks, or a subset of them, into their scheduling specifications, and planners run them before every submission.

Three things frame the list. The assessment grades hygiene, not realism: a schedule can pass all fourteen and still be the wrong plan. Most checks count incomplete activities only, because completed work can no longer move the forecast. And the thresholds are conventions: the standard values are below, and many owners set their own.

The fourteen checks at a glance

Checks 1 to 10 grade construction and can be run on any file. Checks 11 and 14 need a baseline. Checks 6, 7, 12 and 13 need total float, so the schedule must have been calculated before it is assessed. The two 44-working-day cutoffs are roughly two months on a five-day calendar.

Logic and relationships: checks 1 to 5

1. Logic

Counts incomplete activities with no predecessor, no successor, or neither, against all incomplete activities; threshold 5 per cent. The start milestone is exempt on its predecessor side and the finish milestone on its successor side. Every other open end is a place where a delay stops propagating, which is why this is the first check and the one most schedules fail after an import. Add the missing links: tie an activity with no genuine driver to the start milestone, and every dangling finish to the completion milestone or to the work it enables.

2. Leads

A lead is a negative lag: a Finish-to-Start with a three-day lead lets the successor start three days before the predecessor finishes. The standard allows none, because the forecast then rests on an assumption about when the predecessor’s work becomes usable rather than on its finish. Only relationships with an incomplete successor count. Split the predecessor where the successor can begin and use a Finish-to-Start, or use a Start-to-Start with a positive lag.

3. Lags

Counts relationships with positive lag against all relationships with an incomplete successor; threshold 5 per cent. A lag is time nobody is working and nobody can see: a seven-day curing lag has no name, calendar or status, and reads as float in a review. Replace long lags with activities (curing, approvals, lead times) and keep short ones only where they represent a genuine wait.

4. Relationship types

The share of relationships that are Finish-to-Start; threshold 90 per cent or more. Start-to-Start and Finish-to-Finish are legitimate for overlapping work, but a network dominated by them hides open ends: an activity with only a Start-to-Start predecessor has nothing driving its finish. Start-to-Finish should almost never appear. Where overlap is real, pair a Start-to-Start with a Finish-to-Finish so both ends of the successor are driven.

5. Hard constraints

Counts incomplete activities carrying Must Start On, Must Finish On, Start No Later Than or Finish No Later Than; threshold 5 per cent. These four override the logic and can hold a date the network cannot support, producing negative float and a critical path that is no longer the longest path. Start No Earlier Than and Finish No Earlier Than are soft (they can delay but never pull forward) and are not counted. Primavera P6 allows a primary and a secondary constraint, and a hard one in either slot counts. Replace them with the logic that justifies the date; where a contract date must stay visible, carry it on one completion milestone and let the negative-float check report whether the plan supports it.

Float and duration: checks 6 to 8

6. High float

Counts incomplete activities with total float above 44 working days, against the incomplete activities that carry a float value; threshold 5 per cent. Large float usually means missing logic rather than slack: an activity showing 120 days of float is often one whose successor was never linked. Trace its successors in the network view; float that survives a complete set of links is real and belongs in the narrative, not hidden.

7. Negative float

Counts activities with total float below zero. The standard allows none. Negative float means a constraint or deadline cannot be met by the logic as built: the late dates have fallen behind the early dates, and the schedule is no longer a plan the project can execute. Recover the time (re-sequence, add resources, shorten durations with evidence) or move the constrained date and record the change. Never clear negative float by deleting the constraint that exposed it.

8. High duration

Counts incomplete activities with remaining duration above 44 working days, against incomplete activities with a duration; threshold 5 per cent. Long activities hide what is happening inside them: a 90-day activity at 40 per cent complete says nothing about which work is late. Where no remaining duration is recorded, the original duration stands in. Break long activities where progress can be measured; procurement and long-lead items are the accepted exceptions when they are named as such.

Dates, resources and the baseline: checks 9 to 11

9. Invalid dates

Everything in a progressed schedule is relative to the progress date (the data date in P6, the status date in Microsoft Project). Four conditions are invalid: a forecast start before the progress date on an activity with no actual start, a forecast finish before it on an incomplete activity, and an actual start or actual finish after it. The standard allows none. Forecast dates in the past mean the schedule was not statused and rescheduled; actuals in the future are data-entry errors. Record the actuals, then reschedule so every remaining activity moves past the progress date.

10. Resources

Counts incomplete activities with a duration greater than zero and no resource assignment; threshold 5 per cent. Every piece of work should carry labour, equipment or cost so the schedule can be checked for feasibility and used for earned value. Milestones have no duration and are excluded. Assign at least a crew, a role or a cost line; the aim is to make unresourced work visible.

11. Missed tasks

Needs a baseline. The population is the activities whose baseline finish is on or before the progress date; an activity is missed when its actual finish, or its forecast finish if unfinished, is later than its baseline finish. Threshold 5 per cent. This is the first check that measures execution rather than construction, and there is no editing fix: the response is a recovery plan, and check 14 shows whether it worked.

The critical path tests: checks 12 to 14

12. Critical path test

In the DCMA method this is a manual test: add a large duration, conventionally 600 days, to a critical activity, recalculate, and confirm the project finish moves by the same amount. If it does not, something other than logic is driving the finish: a hard constraint, an open end or a lag. The result is pass or fail. An automated tool cannot insert 600 days into a live schedule without changing it, so most apply a consistency test instead: every activity flagged critical should carry float at or near zero. GETSEVEN uses that form, listing critical activities whose total float exceeds one day and passing when there are none. Do the insertion test by hand on a copy before an important submission.

13. CPLI, the Critical Path Length Index

CPLI = (CPL + project total float) / CPL

CPL is the critical path length: the working time from the progress date to the project finish along the longest remaining path. Project total float is the float at the end of that path: zero when the path lands exactly on the required finish, negative when it overruns, positive when there is room. A CPLI of 1.00 means the remaining work arrives exactly on time; below 1.00 the project is behind; above it, ahead. The threshold is 0.95 or more, which tolerates a remaining critical path up to 5 per cent too long.

Worked example. The longest remaining path is 180 working days and the project total float is minus 27 days. CPLI is (180 − 27) ÷ 180 = 153 ÷ 180 = 0.85, a fail: the remaining critical path would have to be compressed by 15 per cent to recover the finish. The same path with 9 days of positive float gives (180 + 9) ÷ 180 = 1.05, a pass with room to spare.

GETSEVEN measures CPL with a longest-path pass over the incomplete activities, in working days, and takes the lowest total float among critical activities as the project float: the conservative reading, which cannot produce a pass from a long non-driving activity that happens to end the path. If the remaining network has no traversable logic (no links, or a cycle) it falls back to calendar days from the progress date to the latest finish.

14. BEI, the Baseline Execution Index

BEI = activities completed / activities baselined to finish by the progress date

Needs a baseline. The denominator is every baselined activity whose baseline finish is on or before the progress date. The numerator is every baselined activity actually complete at the progress date, including those finished ahead of their baseline date, so BEI can exceed 1.00. The threshold is 0.95 or more. Missed tasks and BEI read the same story from opposite ends: one counts what is late, the other what got done.

Worked example. The baseline had 160 activities due by the progress date and 148 are complete. BEI is 148 ÷ 160 = 0.925, below the 0.95 threshold. If six activities that were not yet due had also been finished early, they count: (148 + 6) ÷ 160 = 154 ÷ 160 = 0.9625, which passes. The index rewards finishing work, wherever it sits in the plan.

How to run the assessment and fix what fails

What to count

• Exclude the containers. The project row, WBS summaries, hammocks and level-of-effort activities are not schedulable work; leaving them in dilutes every percentage.
• Define complete. An activity is complete at 100 per cent or with an actual finish. Checks 1 to 6, 8 and 10 count incomplete activities only.
• Fix the progress date. Check 9, both baseline checks and CPLI are measured at it. A schedule with no data date is graded at today, which is rarely what the reviewer intends.
• Work in working days. Float, durations and both 44-day cutoffs are working days, and lags stored in hours convert on the working day, not the calendar day.
• Calculate first. Float and the critical flag come from the scheduling run; an uncalculated file reports the float checks as not applicable, or worse, as clean.
• Bring the baseline. Checks 11 and 14 match baseline finishes to current activities, normally by activity code.

The tooling is the scheduling tool’s own reports, a dedicated schedule-quality product, or a spreadsheet over an export. The export is where errors creep in: a Primavera XER carries durations and float in hours and lags on the predecessor’s calendar, and a lossy conversion changes the answer. The XER guide covers what the file holds.

Common failures and the order to fix them

1. Open ends first (1). Every missing link changes the float, the critical path and the CPLI, so nothing else can be judged until the logic is complete.
2. Then constraints and negative float (5, 7). Remove the hard constraints holding dates the logic cannot support, and resolve the negative float that appears when they go.
3. Then leads, lags and link types (2, 3, 4). Replace long lags with named activities and rebuild overlaps as paired Start-to-Start and Finish-to-Finish links.
4. Then durations and float (6, 8). Split long activities, and confirm that any large float left after the logic fix is genuine.
5. Then status and resources (9, 10). Record actuals, reschedule, and assign the unresourced work.

What the assessment does not tell you

It grades hygiene, not realism. A schedule can pass all fourteen with durations nobody believes, logic that is complete but wrong, and a resource plan that cannot be staffed. It does not check calendars or say whether the critical path is the right path, and because it looks at one schedule it says nothing about what changed since the last update: the re-sequencing, deleted scope and new constraints that absorb a slip without reporting one. Those questions need two schedules side by side, and the forensic questions behind a claim need a method of their own; see the delay analysis guide.

Running the fourteen checks in GETSEVEN

The DCMA Checks module runs all fourteen on the live schedule, on a stored project, or on an uploaded XER or MSPDI file without importing it. Each check is a card with its value, its target and a pass, warn, fail or not-applicable state, and a check that cannot run says why: no progress date, no baseline, or a schedule that was never calculated. Clicking a card lists every offending activity with its reason, and on the live schedule the offenders can be pushed to the Activities grid as the selection.

Every threshold is editable, including both 44-day cutoffs, with a reset to the DCMA default and a badge on any check you have overridden. Percentage checks pass at half the threshold, warn up to it and fail beyond it; the ratio checks warn within 0.05 of their minimum. Overrides live in the browser and apply to every schedule assessed there. Results are computed on demand and are not stored, so the printed report or the Excel workbook is the record of a run.

Choose a captured baseline or upload last month’s submission as the comparison, and the Trend view grades both at the same thresholds and names the activities newly flagged and fixed on each check. Alongside the fourteen, and deliberately kept out of them, eight baseline-relative analyses read the delta: earned schedule and SPI(t), float erosion, duration growth, critical path migration, logic churn, scope churn, constraint churn and missed starts, each reporting not-applicable with a reason when the baseline lacks the field it needs.

Questions