DCMA 14-point assessment for NEC programmes: what each check means for acceptance
By Roman Bazelchuk | NEC Accredited Project Manager | APMG Project Planning and Control
Founder, NEC Planning Solutions Ltd
Many programmes now reach a Project Manager with a scorecard attached, or come back with one in the reply: missing logic at 7%, hard constraints at 9%, the critical path test failed. The fourteen checks have become a widely used schedule health check well beyond defence, in many industries and scheduling tools. They are quick and objective. They are also not part of an NEC contract.
The DCMA 14-point assessment is a set of fourteen tests of how a programme is built and how it is performing, published by the US Defense Contract Management Agency. Under NEC4, a failed check is not in itself a clause 31.3 reason for refusing acceptance, unless the Scope makes it one. It matters when it shows one.
The gap between the score and the contract is where the trouble starts. Clause 31.3 gives four reasons for not accepting a programme and a DCMA score is not one of them. A Project Manager who withholds acceptance on the score alone, where the Scope sets no threshold, has withheld it for a reason the contract does not state. Under clause 60.1(9) that is a compensation event. A contractor who shrugs off the score has the opposite problem, because the score is often the first evidence that a programme does not represent its plans realistically, which is one of the four.
This guide reads each of the fourteen checks against those four reasons. The review itself is set out in what the project manager checks when reviewing your NEC programme, the acceptance mechanics in the clause 31 programme acceptance guide and what to do once a programme has been refused in the clause 31.3 response playbook. If you would rather have the checks run for you, our NEC programme compliance review covers all fourteen before the programme goes in. Reviews start from £950 + VAT.
What the DCMA 14-point assessment is
The assessment comes from the US Defense Contract Management Agency. A 2005 Defense Department memo on earned value management required an integrated master schedule on cost or incentive contracts worth $20 million or more. The agency developed the fourteen checks to review those schedules. They first appeared in a DCMA online course in late 2007. The last published version is in section 4 of the agency's Earned Value Management System Program Analysis Pamphlet, DCMA-EA PAM 200.1, issued in October 2012. In 2017 DCMA said the pamphlet was due to be withdrawn, though it is still on the agency's website. Planners far outside defence took it up because it asks questions most reviewers ask and answers them with numbers.
Most checks count the activities, or the links between them, that break one rule of schedule construction and compare the count with a threshold, usually a share of the incomplete activities. The first ten test how the programme is built: logic, leads, lags, relationship types, hard constraints, high float, negative float, high duration, invalid dates and resources. The critical path test checks that the logic actually drives the finish. The remaining three measure performance against the plan.
Two of those performance measures carry names worth defining. The critical path length index, or CPLI, compares the time left on the critical path plus its total float with the time left on the critical path. Below 1.0, the end date needs time the programme does not have. The baseline execution index, or BEI, divides the tasks finished by the tasks that should have finished by the status date.
The agency's own guidance is clear about what a flag means: a metric outside its threshold is not in itself a failure, but an indicator to dig deeper. Under NEC that sentence carries more weight than anywhere else, because the contract has its own test for a programme and the thresholds are not in it.
The fourteen checks against the four clause 31.3 reasons
Clause 31.3 gives the Project Manager four reasons for not accepting a programme: the Contractor's plans which it shows are not practicable, it does not show the information the contract requires, it does not represent the Contractor's plans realistically, or it does not comply with the Scope. The table reads each DCMA check against them. The wording in the last column is deliberate: a failed check can show a reason, but it is not the reason itself unless the Scope makes the threshold a requirement.
DCMA check | Threshold | What a failure tells you | The clause 31.3 reason it can show |
1. Logic | 5% or fewer missing a predecessor or successor | The network cannot set the order and timing of the work | Missing information (order and timing, 31.2), or not realistic |
2. Leads | None | Overlaps hidden inside the links | Not realistic |
3. Lags | 5% or fewer | Waiting time hidden inside the links | A question to ask, rarely a reason alone |
4. Relationship types | 90% or more finish-to-start | Links that may not model the work | A question to ask, rarely a reason alone |
5. Hard constraints | 5% or fewer | Dates imposed instead of calculated | Not realistic, or float the programme fails to show |
6. High float | 5% or fewer over 44 working days | Usually a missing successor | Points back to check 1 |
7. Negative float | None. Any found needs an explanation and a corrective plan | A date the plan does not meet | Read with care: see below |
8. High duration | 5% or fewer over 44 working days | Activities too long to progress or to assess | Not realistic, or a Scope failure if the Scope sets a limit |
9. Invalid dates | None | Forecasts in the past, actual dates in the future | Missing information (actual progress, 32.1), or not realistic |
10. Resources | Reported rather than scored | Tasks with a duration but no resources shown | Read with care: see below |
11. Missed tasks | 5% or fewer | Work finishing later than planned | Not realistic, if the remaining plan assumes rates the job has not achieved |
12. Critical path test | Pass: planned Completion moves with the added delay | A critical path that does not move with delay | Not realistic, as it cannot carry a compensation event |
13. CPLI | 0.95 or more | Too little float left to finish on time | A question about planned Completion, not a reason alone |
14. BEI | 0.95 or more | Fewer tasks finished than planned | As check 11 |
Two patterns stand out. Most failures land on realism, because a programme whose logic, constraints or dates do not work cannot represent anyone's plans realistically. And four checks rarely show a reason on their own: lags, relationship types, high float and CPLI are usually questions to ask, not reasons to refuse. The fourth reason, compliance with the Scope, applies only where the client has written a requirement in, which is the subject of a later section.
Why a failed check is not, by itself, a reason for non-acceptance
Clause 13.4 requires a Project Manager who does not accept a submission to give reasons in enough detail for the Contractor to correct the matter. A bare percentage rarely meets that test. "Missing logic: 7%" tells the Contractor that something is wrong without saying what, or why it matters to the plans.
Clause 13.8 allows the Project Manager to withhold acceptance. Withholding it for a reason the contract states is not a compensation event. NEC's own guidance on categorising reasons for non-acceptance sets out the other side: the Project Manager is not limited to the reasons in clause 31.3, but withholding acceptance for a reason not contained in the contract is a compensation event under clause 60.1(9).
So the question for the Project Manager is not whether the programme passed. It is which of the four reasons the failed checks prove. Twenty-one activities with no successor, each a piece of work that will never drive planned Completion, are evidence that the programme does not represent the Contractor's plans realistically. Written that way, with the activities listed, the reply gives a reason the contract states and gives the Contractor what clause 13.4 requires: enough to correct the matter.
Time matters as well. The Project Manager has two weeks to accept a programme or give reasons. Under NEC4, if the reply is late, the Contractor may notify the failure and a further week of silence is treated as acceptance. A fortnight spent producing a scorecard rather than reasons risks a reply that arrives late, or arrives on time and proves nothing.
For the Contractor, the same logic runs the other way. Where the Scope sets no threshold, a refusal that cites only a score rests on a reason the contract does not state and it can be notified as a compensation event. The faster route is usually to answer the evidence: fix the flags that show a real fault, explain the ones that do not and resubmit.
How the Scope makes the checks contractual
The fourth reason in clause 31.3 is the one that can turn a check into a contract requirement: the programme does not comply with the Scope. Clause 31.2 already requires a programme submitted for acceptance to show any other information the Scope requires. NEC4 added a requirement that the programme is in the form the Scope states, such as a native file in a named version of the scheduling software.
A client who wants the checks to count writes them into the Scope: which checks apply, the threshold for each, how a flag may be explained instead of fixed, the report that goes with each submission and the file format. A programme that then misses a threshold without an explanation does not comply with the Scope, so refusing it rests on a reason the contract states.
Two cautions apply. Thresholds designed for large defence schedules do not always suit a two-hundred-activity civils job, so the Scope should say which checks apply and how each is counted. And anything beyond the programme's own content needs its procedure written in too. Practitioners writing on the NEC website make the same point about method statements: a client who wants more than clause 31.2's statement of how the work will be done must put it in the Scope, with how it is submitted and accepted.
Four checks that read differently under NEC4
Most of the fourteen checks mean the same under any contract. Four do not, because NEC4 changes what the programme is for.
Negative float and a late planned Completion
DCMA's target for negative float is none and where it exists the agency expects an explanation and a corrective plan. An NEC4 programme shows planned Completion as the Contractor forecasts it and that can be later than the Completion Date. Where the Completion Date is set in the programme as a constraint, a programme that honestly forecasts a late finish fails the check, yet a late planned Completion is not one of the four reasons in clause 31.3. What clause 32.1 does require is that each revised programme shows how the Contractor plans to deal with any delays. Under NEC the question is not whether negative float exists, but whether the programme shows the plan for it.
Resources: a statement, not a loaded schedule
DCMA's check reports incomplete tasks that have a duration but no hours or cost assigned. The agency's own pamphlet notes that the US defence schedule specification does not require contractors to load resources, so the check only counts where they have. Clause 31.2 asks for something different: for each operation, a statement of how the Contractor plans to do the work, identifying the principal Equipment and other resources. A programme with no resource loading can meet clause 31.2 in full. If the client wants a resource-loaded programme, the Scope has to say so and the check then becomes a test of compliance with the Scope.
Missed tasks and BEI: measured against the Accepted Programme
Both checks compare progress with a baseline and NEC has no frozen one. Under clause 11.2(1), the Accepted Programme is the programme identified in the Contract Data or, once one has been accepted, the latest programme the Project Manager has accepted, so each accepted revision replaces the last. A BEI calculated against the tender programme measures how far the job has moved from a plan the contract no longer recognises. Calculated against the Accepted Programme current at the status date, it measures what the contract cares about: whether the plan everyone accepted is being delivered. How that reads in a monthly report is covered in why monthly progress reports arrive too late.
The checks that decide compensation events
Some checks matter for acceptance. Three matter for money. Under clause 63.5, delay from a compensation event is assessed against the Accepted Programme current at the dividing date: the event goes into that programme and the movement in planned Completion is measured. On the January 2019 wording, the assessment also takes account of events between that programme's date and the dividing date. That only works if the logic carries the event through to Completion. Missing logic, hard constraints and a failed critical path test are the three checks that say it will not.
This is the third question of the Accepted Programme Test: would it survive an event built on it. The checks answer it with numbers before an event arrives, instead of in the middle of a quotation, when the Project Manager's first challenge is that the baseline cannot show the effect. How the quotation itself is put together is set out in how to structure a time impact assessment under NEC4.
The critical path test is the one most worth running before every submission. It adds a delay to an activity on the critical path and checks that planned Completion moves by the same amount. A programme that fails it produces compensation event assessments that are hard to defend, whichever side prepares them. Logic pays for itself over a whole job. On one FIDIC contract, a logic-linked programme built from first principles carried the design changes through delivery. Each change was measured on the programme and the time lost was recovered.
Running the DCMA 14-point assessment in Primavera P6
Since release 22.12, P6 Professional has its own schedule health check: the Check Schedule report, under the Tools menu. P6 EPPM has had a similar check for longer, under the Actions menu. Both run DCMA-style checks against targets the planner can adjust and report each one with what it found and its share of the total. Oracle's help up to version 26 lists no critical path test and no CPLI. Its Late Activities check is not DCMA's missed tasks count either. Run those three by hand.
Two settings decide whether the result means anything on an NEC job. Set the current Accepted Programme as the project baseline before running the report, so that BEI and missed tasks measure against the plan the contract recognises rather than the tender programme. And run it on the programme exactly as it will be submitted, with its data date set, because invalid dates and negative float only mean something against the status date the Project Manager will see. The settings that make most checks pass by design, from calendars to constraint types, are in Primavera P6 for NEC programmes.
Running the checks on every submission
Run the checks on the first programme under clause 31 and on every clause 32 revision, not once at the start. A programme that passes in month one can fail by month nine without anyone touching its logic on purpose, as five signs a programme has lost its integrity describes.
Report the result with the submission, flag by flag. A failed check with an explanation is a different document from a failed check with nothing beside it: a long activity that is a fabrication lead time, a lag that is a concrete cure, a constraint that is a Key Date. DCMA's own position, that a flag is a reason to look closer rather than a failure, is the right one to put in front of a Project Manager.
What the checks cannot do is judge the plan. They cannot tell whether the sequence is buildable, whether the durations match the gangs and the plant, or whether the programme shows everything the contract requires. That remains the reviewer's job. The checks clear the ground for it.
The author's view
I read DCMA scorecards from both sides of the table and the most expensive habit I see is treating the score as the verdict. On the client side, a Project Manager under pressure sends back "failed DCMA" and, a few weeks later, is looking at a compensation event for withholding acceptance for a reason the contract does not state. On the contractor side, a planner who has learned to hit the thresholds produces a programme that scores well and still cannot carry an event, because the flags were cleared by deleting awkward logic rather than fixing it.
My position is simple. Agree the checks at tender, write them into the Scope with the explanations allowed and then argue about the programme rather than the score.
Download the DCMA 14-point checklist for NEC programmes
The checklist sets out the fourteen checks in five groups on two pages, each with its NEC4 reading and what to state with the submission. It ends with the clause 31.3 test. Use it before every clause 31 submission and clause 32 revision. It is also in the resources library, with the other checklists and sample documents.
Frequently asked questions
What is the DCMA 14-point assessment?
The DCMA 14-point assessment is a set of fourteen checks on how a schedule is built and how it is performing, published by the US Defense Contract Management Agency and last issued in its October 2012 analysis pamphlet. It covers logic, leads, lags, relationship types, hard constraints, high float, negative float, high duration, invalid dates, resources, missed tasks, the critical path test, CPLI and BEI.
Can you run the DCMA 14-point assessment in Primavera P6?
Mostly. Since release 22.12, P6 Professional has a Check Schedule report under the Tools menu. P6 EPPM has had one for longer. It runs DCMA-style checks against targets you can adjust, but it has no critical path test or CPLI and does not count missed tasks the DCMA way, so run those three separately. On an NEC job, set the current Accepted Programme as the project baseline before running it.
Can a Project Manager reject an NEC4 programme for failing DCMA checks?
Not on the score alone. Clause 31.3 gives four reasons for not accepting a programme and a DCMA threshold is not one of them unless the Scope makes it so. The Project Manager can still withhold acceptance, but NEC's guidance is that withholding it for a reason the contract does not state is a compensation event under clause 60.1(9). Tie each failed check to a clause 31.3 reason instead.
Is negative float a reason to reject an NEC4 programme?
Not by itself. An NEC4 programme shows planned Completion as the Contractor forecasts it and that can be later than the Completion Date. A late planned Completion is not one of the four reasons in clause 31.3. What clause 32.1 requires is that each revised programme shows how the Contractor plans to deal with delays, so negative float with no plan behind it is the real problem.
How do you make DCMA checks a contract requirement under NEC4?
Write them into the Scope. Clause 31.2 already requires a programme to show other information the Scope requires and to be in the form the Scope states. Clause 31.3 lets the Project Manager refuse a programme that does not comply with the Scope. Name the checks that apply, the thresholds, how a flag may be explained, the report and the file format.
About the author
Roman Bazelchuk is the Founder of NEC Planning Solutions Ltd, a UK project planning and controls consultancy supporting contractors with NEC programme compliance, compensation event assessments and live project controls. He is an NEC Accredited Project Manager and holds the APMG Project Planning and Control qualification, with a BEng in Mechanical Engineering and postgraduate training in Planning and Control.
NEC Planning Solutions provides contract-aware planning support through a QA-governed delivery model, helping project teams keep programmes accepted, current and commercially useful from tender through to live delivery.
Will your next programme survive the checks?
NEC Planning Solutions runs a programme compliance review before a programme goes in: the fourteen checks, every flag tied to the clause 31.3 reason it could support and the faults to fix separated from the flags to explain. Reviews start from £950 + VAT.
You don't need to send anything first. We reply to every enquiry within one working day. The scope and a fixed fee follow in writing within 48 hours of the first call.
