What the DCMA 14-point assessment is
The DCMA 14-point assessment is a set of fourteen checks on the structure and execution of a critical path method schedule. It comes from the US Defense Contract Management Agency's schedule analysis for earned value management systems. Checks 1 to 9 and 11 count tasks or relationships against a threshold. Check 10 is a coverage test with no percentage. Checks 12 to 14 test whether the critical path responds to delay and whether delivery is keeping to the baseline.
This page is the reference for the definitions and thresholds. The table lists all fourteen with what is counted and against what. The companion guide, Reading a DCMA 14 result properly, covers interpretation, which metrics mislead and how to write the review. This page does not repeat that.
The honest UK position
DCMA 14 is a US Department of Defense origin check. It is widely used in UK practice, by contractors, clients and assurance teams, as a way to screen schedule quality. It is not mandated by National Highways, Network Rail or HS2, and it is not a contractual requirement under NEC4 or any standard UK form. A client can require it, but only by writing it into the Scope or its own procedures.
Say "widely used", not "adopted" or "required", and check what your own client documents actually say before quoting a threshold as a contractual test.
The fourteen checks
Checks 1 to 9 test the network. Check 1 finds open ends: tasks missing a predecessor or a successor. Check 2 finds leads, negative lags that let a successor start before its predecessor has finished. Check 3 counts lags of any type. Some lags are legitimate, such as a concrete cure time or a statutory notice period. Lags used to hold a date, or to hide work that should be an activity, are the problem. Check 4 expects at least 90% finish-to-start relationships, because heavy use of start-to-start, finish-to-finish and start-to-finish logic makes a schedule hard to read and hard to update.
Check 5 counts hard constraints: Must Start On, Must Finish On, Start No Later Than and Finish No Later Than. These fix or cap a date regardless of what drives the task. Start No Earlier Than and Finish No Earlier Than are soft and not counted. Where a date must be controlled, use a soft constraint or a deadline date, and check how your tool treats it. Check 6 counts tasks with more than 44 working days of total float, usually a symptom of missing logic. Check 7 counts tasks with negative float. Negative float is the schedule forecasting a miss against a constraint or deadline. It is not by itself evidence that the baseline was never reset. Check 8 counts tasks with a baseline duration above 44 working days. Long tasks are hard to progress and hard to earn value against. Check 9 counts dates that cannot be true: forecast dates before the status date on work not yet done, and actual dates after it.
Check 10 looks at resources and cost. Resource-loading is not a prerequisite under DCMA 14. If the schedule is loaded, every task with a duration above zero should carry a resource or cost. Report coverage rather than pass or fail it, and set a numerical threshold only where the client's procedures do. Check 11 compares the baseline with actual delivery: of the tasks baselined to finish by the status date, how many did not finish by their baseline finish. Check 12 is a test delay. Add a very large delay to a task on the critical path and confirm the project finish moves by the same amount. If it does not, something downstream is breaking the logic, often a constraint, a lag or an open end. Check 13, CPLI, is (critical path length + total float) / critical path length, where critical path length is the working days from the status date to the project finish. Below 1.0 the path is longer than the time available; below 0.95 the check fails. Check 14, BEI, is tasks completed to date divided by tasks baselined to be complete by the status date. Below 0.95 the baseline is not being met. CPLI looks forward and BEI looks back.
Running it: scope, calendars and tools
The result is reproducible only if the scope and calendar settings are declared. DCMA checks apply to incomplete detail tasks. Exclude completed tasks, summary tasks and level-of-effort tasks, and state how you treated milestones and hammocks. The 44-day tests depend on the calendar. At 8 hours per working day, 44 days is 352 hours, and a P6 float or duration shown in hours must be converted using the calendar in use. State the status date, the calendar and the exclusions with every result.
Tools that run the checks: Deltek Acumen Fuse and Steelray Project Analyzer run them as standard metrics. Recent releases of Oracle Primavera P6 Professional include a Check Schedule report that covers most of the checks, including the BEI, with its own default thresholds that should be set to match the ones above. The critical path test and the CPLI need a spreadsheet calculation or a tool. Microsoft Project needs an export to a tool or spreadsheet. @RISK is a Monte Carlo add-in and does not run DCMA 14. Whatever the tool, use the same method every month so the trend means something.
Worked example
A schedule has 400 incomplete detail tasks and 1,200 relationships. At the status date, 44 tasks were baselined to finish and 38 have finished. Critical path length is 120 working days and the critical path carries 10 days of negative float. The test delay moves the finish by the full amount.
Logic: 28 tasks with an open end, 28 / 400 = 7.0%, fail. Leads: 3 relationships, fail. Lags: 42 / 1,200 = 3.5%, pass. Relationship types: 1,044 finish-to-start / 1,200 = 87.0%, fail. Hard constraints: 12 / 400 = 3.0%, pass. High float: 31 / 400 = 7.8%, fail. Negative float: 9 tasks, fail. High duration: 14 / 400 = 3.5%, pass. Invalid dates: 0, pass. Resources: schedule not loaded, not applicable. Missed tasks: 6 of 44 not finished by baseline finish, 13.6%, fail. Critical path test: pass. CPLI: (120 - 10) / 120 = 0.92, fail. BEI: 38 / 44 = 0.86, fail.
That is eight fails. Count matters less than which checks fail. The open ends, leads and negative float mean the schedule cannot yet be trusted to forecast. The fix is to repair the logic first, then re-run. The CPLI and BEI results say delivery is behind the baseline and should be reported as such. For how to read each fail and write it up, see the companion guide.
Using it under NEC4
Under NEC4 ECC the Contractor is accountable for the programme. The Project Manager accepts it. The Accepted Programme is defined in clause 11.2. Clause 31.2 sets what the first programme must contain, including float and time risk allowances. Clause 31.3 requires the Project Manager to reply within two weeks, and lists the reasons for non-acceptance. Clause 32 covers revised programmes, submitted at the intervals in the Contract Data, when instructed and when the Contractor chooses.
A DCMA fail is not itself a ground for non-acceptance. The Project Manager can rely on it only if the Scope or Contract Data sets a schedule-quality requirement, and the reasons in clause 31.3 should be checked against the form in use. If your client wants DCMA 14 applied, put the checks, thresholds, scope filters and calendar into the Scope so everyone runs the same test. Whoever assesses it should not be the planner who built the schedule.
Why it matters for QSRA
A schedule that fails DCMA 14 gives unreliable QSRA results. Open ends show false float, so risks on those tasks appear to have no schedule effect. Hard constraints can truncate the effect of a risk by holding a finish date. Heavy non-finish-to-start logic and lags can distort which paths drive the finish and so distort the sensitivity ranking. Leads hide the true sequence. Negative float tells you the model starts from a forecast miss.
On a QSRA we run a schedule health check before building the model and agree repairs with the planner. The DCMA 14 result is an input to that decision, not a pass mark. See QSRA readiness before the Monte Carlo.