Every check, one at a time: the threshold, why it exists, what a failure actually tells you, and how to fix it in Primavera P6 or Microsoft Project. Written for the person who has to pass them, not the person who wrote them.
The DCMA 14-Point Schedule Assessment is fourteen quantitative tests published by the US Defense Contract Management Agency. It exists to answer one question before anyone argues about dates: is this schedule built well enough to be believed?
That framing matters, because the most common misreading of a DCMA result is treating it as a health check on the project. It isn't. A schedule can pass all fourteen and describe a job that is nine months late. A schedule can fail six and belong to a project that delivers early. The checks measure construction quality — whether the network is wired so that delay flows through it correctly — and nothing else.
What it buys you is the right to trust the output. If 22% of your activities have no successor, the completion date is decoration: there is no chain along which a delay could reach it. Fix that, and the forecast becomes an argument worth having.
It began in defence and spread because it is fast, numeric and hard to argue with. Principal contractors, government infrastructure clients and independent certifiers now routinely ask for it with each monthly programme.
The fourteen are not equal. Three decide whether the schedule can forecast anything at all, and failures there usually cause several of the others:
A marginal lag percentage is cosmetic beside any of those. Fix the structural three first and re-run; a surprising number of the remaining failures clear on their own.
What it measures: incomplete activities with no predecessor, no successor, or neither — as a percentage of all incomplete activities. The project's first and last activities are legitimately exempt.
Why it exists: an activity with no successor is a dead end. Delay it by a month and nothing downstream notices, because there is no path along which the delay could travel. An activity with no predecessor floats free of everything that must happen before it. Either way the network stops being a model of the job.
What a failure means: the schedule cannot be relied on to forecast. This is the check to fix first, always.
Filter for activities with no relationships and work through them. The usual offenders are the ones added late under pressure: procurement, approvals, "information required by" markers and client-supplied items. They get typed in to make the programme look complete and never get linked. Give every one a real predecessor and a real successor — and resist the temptation to hang them all off the start milestone, which passes the check while telling you nothing.
What it measures: relationships with a negative lag, allowing a successor to start before its predecessor finishes.
Why it exists: a lead compresses the schedule by assertion rather than by logic. It also corrupts the longest-path calculation, because the relationship no longer describes a real handover — and it hides the actual overlap from anyone reading the programme.
What a failure means: someone needed the schedule to fit and pulled a successor backwards instead of changing the plan.
Split the predecessor. If blockwork can start when the slab is 40% poured, model the pour as two activities and finish-to-start off the first. You end up with the same overlap, honestly stated, and progress against it becomes measurable instead of assumed.
What it measures: relationships carrying a positive lag, as a percentage of all relationships.
Why it exists: a lag is work or waiting time that has been hidden inside a line rather than shown as an activity. It cannot be progressed, resourced, costed or claimed against, and nobody reading the bar chart can see it.
What a failure means: real duration is buried where nobody will look for it — typically concrete cure, delivery lead time, approval periods and drying.
Promote each meaningful lag into its own zero-resource activity with a duration and a name. "Concrete cure — 7 days" on the bar chart is something a site team can plan around; a FS+7 on a relationship is not. Keep lags only where the waiting is genuinely not an activity.
What it measures: the share of relationships that are finish-to-start.
Why it exists: finish-to-start is the only relationship that reads unambiguously — this finishes, then that starts. Heavy use of start-to-start and finish-to-finish makes the driving path hard to trace, and an activity linked only SS at the front and FF at the back has effectively open logic at both ends despite appearing linked.
What a failure means: often a schedule built to hit a date rather than to describe a sequence. SS/FF pairs are the standard tool for compressing a programme on paper.
Convert what you can to FS by breaking activities down — the same fix as check 2. Where SS or FF genuinely reflects the work, keep it, but check that the activity also has proper logic at its other end. Treat every start-to-finish link as a defect until proven otherwise; in most schedules containing them, they were entered by mistake.
What it measures: incomplete activities carrying a constraint that overrides network logic — Must Start On, Must Finish On, Start No Later Than, Finish No Later Than, and P6's mandatory equivalents.
Why it exists: a hard constraint stops delay propagating. The date holds because it has been nailed down, not because the work supports it, and the slip that should have pushed the finish disappears into negative float instead.
What a failure means: the schedule is being held together by dates rather than logic — and every constrained activity is a place where a real delay will fail to show up in the forecast.
Replace constraints with logic wherever the date is a consequence rather than an obligation. Keep them only for genuine external commitments — a contractual access date, a possession window, a shutdown. Where you must constrain, put it on a milestone rather than on the work, so the constraint is visible as a commitment instead of silently distorting an activity's float.
What it measures: incomplete activities with total float above 44 working days — roughly two calendar months.
Why it exists: genuine slack of that size is rare on a well-linked programme. Very high float is nearly always a symptom of check 1: the activity has nothing meaningful downstream, so the calculation has nothing to push it against.
What a failure means: usually missing logic, not comfort. Treat a high-float list as a second pass at the logic check.
Sort by total float descending and inspect the top of the list. For each one ask what genuinely cannot happen until it is done. If the answer is "nothing", it either needs a successor or it does not belong in the schedule.
What it measures: incomplete activities with total float below zero.
Why it exists: negative float means the network cannot deliver a date it has been told to hit. It is the schedule stating plainly that the plan is already impossible.
What a failure means: one of two things, and they need opposite responses. Either the project is genuinely late against a real commitment — in which case you need a recovery plan or an extension of time — or somebody has applied a constraint the work never supported, and the negative float is an artefact rather than a fact.
Trace it to the constraint or milestone driving it before doing anything else. If the date is real, the answer is a recovery plan or a re-baseline, not a schedule edit. If the constraint is artificial, remove it — but note that this makes the number go green while changing nothing about the job, which is the single most common piece of DCMA theatre.
What it measures: incomplete activities with remaining duration over 44 working days.
Why it exists: nobody can say anything useful about the inside of a three-month bar. Percent complete becomes a guess, progress cannot be verified, and a slip is invisible until the finish date arrives.
What a failure means: the schedule is too coarse to manage at the level it is being reported at.
Break long activities into stages that finish at something you could photograph or sign off — by level, zone, grid line or system. Splitting a 90-day activity into three 30-day activities purely to pass the check, with no verifiable handover between them, passes the check and improves nothing.
What it measures: forecast work sitting in the past (before the data date), or actual dates recorded in the future.
Why it exists: both are impossible, and both mean the schedule has not been properly statused. Forecast work behind the data date is work that was supposed to happen and was never updated; actuals ahead of it are work recorded as done before it could have been.
What a failure means: the update was rushed. Every other number in the schedule is now suspect, because the calculation ran against a state that cannot exist.
Set the data date correctly, then status every activity behind it: actualise what finished, record actual starts and remaining durations on what is in progress, and push genuinely unstarted work forward. In MS Project, confirm the status date is set — Project → Project Information — because it defaults to today and quietly moves under you.
What it measures: incomplete activities with duration but no resource or cost assigned.
Why it exists: unresourced work cannot be levelled, cost-loaded or forecast. If the schedule is meant to drive earned value, an activity with no cost or hours contributes nothing to the measurement.
What a failure means: either genuinely unresourced work, or — far more often — a schedule that was never resource-loaded in the first place.
If the programme is not resource-loaded, this check does not apply and should be reported as not assessed rather than failed. If it is, the offenders are usually the same late-added activities that failed check 1. Cost-loading counts: a schedule can carry budget without named resources and still satisfy the intent.
What it measures: activities that finished — or are now forecast to finish — later than their baseline finish, as a percentage of baselined activities.
Why it exists: it is the first honest, unarguable measure of slippage. Not an index, not a forecast: a count of promises already broken.
What a failure means: the plan and the job have diverged. Above 5% and the baseline is beginning to describe a different project from the one being built.
There is no schedule edit that fixes this one honestly — it is a report on what happened, and the response is management rather than editing. What it should drive is a conversation about whether the baseline is still a fair yardstick. Re-baselining to clear it, without a change in scope or an approved extension, is how a project loses the ability to measure itself.
What it measures: inject a very large delay — conventionally 600 days — into an activity on the driving path, recalculate, and confirm the completion date moves by roughly the same amount.
Why it exists: it is the only check that tests the network as a working mechanism rather than counting its features. If the finish date does not move, something is absorbing the delay: a constraint, a broken chain, or a calendar doing something unexpected.
What a failure means: the completion date is not being driven by the work. Whatever the bar chart shows, the critical path is not connected to the end of the job.
Run it on a copy, then trace where the delay stopped. It is nearly always a hard constraint (check 5) or an open end (check 1) partway down the driving chain. This is also the check no read-only tool can perform for you — anything that only reads an exported file can test whether an unbroken chain of zero-float activities reaches the completion milestone, which catches most broken paths, but the injection itself has to be done in P6 or MS Project.
What it measures: (critical path length + total float to the completion milestone) ÷ critical path length, where the path length is the working days from the data date to the contract finish.
Why it exists: it expresses achievability as a single number. At 1.0 the plan finishes exactly on the required date. Below 1.0 you must outperform your own schedule to hit it; below 0.95 that gap is no longer a rounding error.
What a failure means: the required date and the planned date have parted company, and the difference is being carried as negative float. Expect check 7 to be failing too.
CPLI is an output, not an input — it moves when the plan changes. Genuine responses are re-sequencing, acceleration, or an approved extension of time. Note that the index is highly sensitive late in a project: with 20 days of path left, five days of negative float takes CPLI to 0.75, so read it alongside the absolute number of days rather than on its own.
What it measures: activities actually completed, divided by the number the baseline said should be complete by the data date.
Why it exists: it measures throughput against plan. Unlike SPI it counts activities rather than value, so it is not flattered by finishing a lot of cheap work early — and unlike check 11 it captures the rate rather than individual misses.
What a failure means: you are completing work more slowly than the baseline assumed. Sustained below 0.95, the end date is at risk regardless of what the current critical path says, because the whole plan is running at a slower tempo than it was drawn at.
Like check 11, this is a report rather than something to edit. Watch it as a trend rather than a snapshot — a single month below 0.95 is noise, three in a row is a rate problem, and a rate problem will not be solved by resequencing the critical path.
Delete the constraint and negative float becomes comfortable. Convert lags to zero-resource activities and the lag percentage collapses. Split long activities anywhere and the duration check clears. Hang orphan activities off the start milestone and the logic check passes.
None of it changes the job. A schedule that passes all fourteen after a week of tidying is often less honest than the one that failed, because the failures were telling you something and now they aren't.
The useful test to apply to any fix: would this change what somebody does on site? Breaking a 90-day activity into verifiable stages changes how progress is claimed and checked — that is a real improvement. Splitting it into three arbitrary thirds changes a number in a report and nothing else.
If a client demands fourteen green ticks, the defensible answer is a schedule that passes eleven with three explained failures, not one that passes fourteen and cannot forecast. Write the explanations into the submission; a named, reasoned exception survives scrutiny far better than a suspiciously clean scorecard.
There is no official overall pass mark — each check stands alone. In practice:
That last point is worth repeating because it is where DCMA results get misused most often in a monthly report. Fourteen green ticks on a project that is four months behind is a well-constructed record of being four months behind. To know how the project is going you need earned value, float trend and milestone slip — different instruments entirely.
Every reporting cycle, before submission rather than after rejection. Schedule quality degrades continuously and without anyone deciding to degrade it: activities get added under time pressure and not linked, constraints get applied to hold a date for a meeting, a status update gets done in a hurry the morning it is due.
Run monthly, it is maintenance — a handful of fixes each cycle. Run only when a client asks, it is a crisis, and the fixes get made under exactly the pressure that produces theatre rather than improvement.
Logic, negative float and the critical path test. Those three decide whether the schedule can forecast at all, and failures there often cause the others. A marginal lag percentage is cosmetic beside them.
Easily, and it makes the schedule worse. Deleting constraints, converting lags to token activities and splitting long bars arbitrarily all clear checks without changing the job. Ask whether a fix would change what anyone does on site.
Not by law. It came from the US Defense Contract Management Agency and spread because it is quick and hard to argue with. Many principal contractors and infrastructure clients now require it contractually with monthly programmes.
Both threshold at 0.95. BEI measures throughput — activities done versus activities due by now. CPLI measures achievability — whether the remaining path plus its float reaches the required date. Below 1.0 on either means you must outperform the plan.
Missed Tasks and BEI need baseline dates; the Resources check needs resource or cost loading. Without them those checks cannot be scored, and reporting them as passes would flatter a thin export.
Every reporting cycle, before the programme goes out. Monthly it is maintenance; annually it is a crisis.
Once the programme is sound, the monthly question changes from "can we trust this?" to "what is it telling us?" Aegis reads the same P6 or MS Project export each period and answers the second one — earned value, float erosion, milestone slip and a written assessment.
Start your 14-day trial →