What DCMA 14 actually is
The Defense Contract Management Agency 14-point schedule assessment — DCMA 14 — originated in the United States Department of Defense. It was developed as a rapid, automated health check for contractor schedules submitted under major acquisition programmes. The intent was practical: give schedule reviewers a consistent, repeatable way to flag obvious structural problems in a schedule without spending days doing it manually.
That origin matters because it sets the boundaries of what DCMA 14 is and is not. It is a screening tool. It runs against the schedule data and produces pass/fail results against fourteen pre-defined thresholds. It is fast, it is reproducible, and it is widely understood — which is why it has migrated well beyond US defence procurement and is now used as a quick quality check on infrastructure, construction, and engineering programmes across the UK and internationally. UK MoD CADMID Demonstration and Manufacture-phase contracts routinely incorporate DCMA-style screening into the contract data requirements alongside the EVMS reporting clauses.
What it was never designed to do is replace proper schedule quality assurance. DCMA 14 does not assess whether the logic is sensible, whether the durations are realistic, whether the resources are credible, or whether the schedule reflects how the work will actually be built. A schedule can pass all fourteen metrics and still be fundamentally misleading. Conversely, a schedule can fail several metrics legitimately — because the project genuinely has characteristics that trigger the thresholds — without those failures indicating a problem that needs fixing.
This is the source of most of the frustration practitioners have with DCMA 14 reviews. A reviewer who treats every threshold breach as a non-compliance finding, without understanding what the metric is catching and whether that applies to this schedule, is not doing schedule assurance. They are generating a list. The skill is in knowing which list items matter and which do not.
UK guidance — including the APM Planning, Scheduling, Monitoring and Control Specific Interest Group guidance and HM Treasury's project control frameworks for major programmes — references DCMA-style checks as a useful first-pass tool. AACE International's recommended practice 17R-97 sets out similar thinking on schedule quality assessment. None of them treat automated metrics as a substitute for professional judgement.
The 14 metrics, in plain English
Logic: measures the percentage of tasks with at least one predecessor and one successor. The threshold is typically less than 5% of tasks missing logic. Missing logic means tasks can float freely in the schedule — they have no dependency connections that tie them to the rest of the plan. A high missing-logic figure almost always indicates a schedule that has been built carelessly, or where the planner has given up on sequencing a section of work and left it as a list of floating activities.
Leads: counts tasks with negative lag on their dependencies — effectively, start-before-finish relationships where work begins before its predecessor is complete. The threshold is zero. Leads are almost always a modelling shortcut that disguises a gap in the logic. If work genuinely can start before a predecessor finishes, that relationship should be modelled explicitly, not fudged with a negative lag value.
Lags: counts tasks with positive lag on their dependencies. The threshold is typically less than 5%. Lags represent a deliberate delay built into a dependency — for example, a curing time, a drying period, or a notice period before a handover. This is one of the metrics most routinely misapplied in reviews, which we will return to in the next section.
Relationship Types: checks the proportion of finish-to-start relationships versus other relationship types (start-to-start, finish-to-finish, start-to-finish). The threshold typically expects more than 90% finish-to-start. Overuse of other relationship types — especially when combined with lags — can make a schedule hard to follow and can mask float and near-critical path calculations.
Hard Constraints: counts tasks with imposed dates (must-start-on, must-finish-on, start-no-earlier-than beyond reasonable bounds). The threshold is less than 5%. Hard constraints override the schedule logic and prevent the network from calculating dates correctly. They can mask negative float, artificially shorten the critical path, and make what-if analysis unreliable.
High Float: counts tasks with total float above a defined threshold, typically 44 working days. High float indicates tasks that are not driving anything — they have large amounts of scheduling headroom. In moderation this is normal. In excess it usually means missing logic: the task is not connected to downstream milestones it should be driving.
Negative Float: counts tasks with total float below zero — meaning the current schedule calculates a completion date later than the imposed or target date. Negative float is the clearest signal in the entire DCMA 14 suite that the schedule is predicting a problem. It is almost always worth investigating.
High Duration: counts tasks with durations above a defined threshold, typically 44 working days. The concern is that long tasks are harder to track, provide less granular progress data, and may mask slippage until it is too late to recover. The threshold is less than 5% of tasks.
Invalid Dates: checks for actual dates that are in the future, or forecast dates that are in the past, relative to the data date. Invalid dates indicate a schedule that has not been properly updated — progress has not been recorded, or the data date has not been advanced. An invalid date in a schedule is a direct signal that the data cannot be relied upon.
Resources: checks whether tasks have resources assigned. The threshold varies but is typically more than 90% of tasks resourced. An unresourced schedule cannot be used for resource planning, cash-flow forecasting, or productivity tracking. On many programmes, resource-loading is done in a separate tool and the schedule is used purely for logic; in those cases the metric will fail but the failure may be intentional.
Missed Tasks: counts tasks with a forecast finish date earlier than the data date that have not been recorded as complete. Missed tasks are tasks the schedule says should have finished but haven't been marked as done. A high count indicates either that progress is not being tracked or that the schedule is already behind and nobody has acknowledged it.
Critical Path Test: verifies that the critical path runs continuously from the project start to the project end. If a schedule has no continuous critical path, it means there are gaps in the logic — the longest path through the network does not actually drive the end date. This is a serious structural problem.
Critical Path Length Index (CPLI): a ratio of the time available to complete the project to the time required. A CPLI below 0.95 typically indicates the schedule is under pressure — the critical path is longer than the time remaining. A CPLI above 1.0 indicates float on the critical path. CPLI is one of the more useful forward-looking metrics in the suite.
Baseline Execution Index (BEI): the ratio of completed tasks to tasks that should have been completed by the data date according to the baseline. A BEI below 1.0 means fewer tasks have been completed than the baseline predicted. Like CPLI, this is a useful productivity indicator, though it treats all tasks equally regardless of their size or criticality.
The metrics that mislead more than they help
Three metrics generate more unjustified findings than all the others combined: Lags, Hard Constraints, and High Duration. Each of them flags something that is genuinely problematic in some schedules and entirely appropriate in others. Treating a breach as a finding without understanding the context is the most reliable way to undermine your credibility as a reviewer.
Lags. On a construction or civil engineering schedule, lags are frequently legitimate and necessary. Concrete requires a curing period before formwork can be struck — you cannot accelerate it by improving logic. Rebar connections have specified set times. Paint systems require drying windows between coats. Commissioning protocols specify minimum hold periods before energisation. Modelling these as lags on a dependency is correct practice. The alternative — creating separate activities for every curing or drying period — produces a bloated schedule with hundreds of placeholder tasks that add no informational value. A reviewer who flags every lag as a non-compliance without asking what each one represents is not analysing the schedule; they are running a spell-checker and calling it a review.
Hard Constraints. In fixed-date contracts, imposed constraints are often unavoidable and contractually mandated. A project with a planning permission condition that specifies no works before a particular date, or a contract with a fixed handover date, or an interface with a third-party system that cannot be moved, will necessarily have hard constraints in those locations. The question is not whether hard constraints exist but whether they are documented, justified, and located where the contract or programme genuinely requires them. Constraints applied to activities buried in the middle of a work package with no obvious justification are a legitimate concern. Constraints on milestone activities tied to contractual completion dates are not.
High Duration. Long-duration activities are appropriate for long lead procurement items, plant fabrication, regulatory approval processes, and extended design stages. A turbine procurement activity that genuinely takes six months should appear as a six-month activity. Breaking it into weekly sub-tasks to satisfy a DCMA threshold produces artificial granularity that obscures rather than illuminates. The relevant question is whether the duration reflects the genuine scope of the activity and whether it will be tracked with appropriate interim milestones. If a six-month procurement task has no milestones or progress indicators, that is a concern. If it has a well-defined procurement tracker running alongside the schedule, the duration itself is not the problem.
The principle that applies across all three: context is everything. A reviewer who lists these as findings without providing the context for each one — and without asking the contractor to explain the rationale — is producing noise, not signal. The contractor will dismiss the review, the client will not learn anything useful, and the relationship will be more adversarial than it needs to be.
The metrics that actually catch real problems
Four metrics in the DCMA 14 suite almost always indicate a genuine problem when they fail: Missing Logic, Negative Float, Invalid Dates, and Critical Path Test failures. If a schedule fails any of these, the reviewer should pursue them until they understand exactly why.
Missing Logic is the clearest indicator of schedule construction quality. A planner who has not connected tasks to their predecessors and successors has either not thought through the sequencing, or has deliberately disconnected tasks to create artificial float. Either way, the schedule cannot be used reliably for forecasting. Logic gaps mean the schedule does not model the dependencies of the work. Every logic gap should be investigated: what is this activity? Why is it not connected? Is there a genuine reason it floats freely, or has it been disconnected to avoid a negative float calculation?
Negative Float tells you the schedule is already predicting a missed date. It does not tell you why, or how significant the miss is, or whether there is a recovery plan. But it is one of the hardest metrics to legitimately ignore. A schedule with negative float on the critical path is telling you, in plain arithmetic, that the current plan does not deliver the target completion date. The contractor needs to either explain why the negative float is an artefact of the modelling (for example, a constraint is set incorrectly) or present a credible recovery plan. Negative float that goes unacknowledged in a review report is a missed finding.
Invalid Dates are a data quality problem. A schedule with actual dates in the future or forecast dates in the past has not been maintained properly. This matters because every calculation the schedule produces — float, critical path, forecast completion — is based on the data date and the relationship between actual progress and forecast logic. If the data is wrong, everything downstream is wrong. Invalid dates are not a scheduling philosophy question; they are a factual error that needs to be corrected before the schedule can be used for anything.
Critical Path Test failures mean the schedule does not have a continuous path of logic from start to finish. Without a continuous critical path, the schedule cannot correctly identify which activities drive the end date. Float calculations will be unreliable. The critical path will appear broken or circular. This is a fundamental construction error that must be resolved before the schedule can be used as a planning or forecasting tool. It is not a threshold question — there is no legitimate reason for a schedule not to have a continuous critical path.
These four metrics, taken together, tell you the most important things you need to know from a DCMA 14 run: is the schedule logic complete, is the schedule predicting a problem, is the data current, and is the network structure sound? If all four pass, you have a schedule that is at least structurally credible. If any of them fail significantly, you have a schedule that cannot be relied upon without remediation.
What a credible review report looks like
A credible schedule review report is not a screenshot of the DCMA 14 dashboard. Every client with access to the same scheduling tool can produce that screenshot themselves. The value of a professional review is the interpretation: what does this mean for this project, which findings matter, what should the client do about it, and what further information is needed.
The structure that works: start with a three-line executive summary. Not a list of metrics — a statement of the reviewer's overall assessment. Something like: "The schedule passes nine of the fourteen DCMA 14 metrics. The two findings of concern are a continuous critical path failure affecting the civils package and negative float on the commissioning milestone. The remaining three failures reflect characteristics of this contract type and are not considered indicative of quality problems." That is the whole picture in three sentences. Everyone reading the report knows immediately whether there is a problem and what it is.
Then address the metrics that failed and why it matters in this specific schedule. Not a generic description of what negative float means — the client knows. An analysis of where the negative float is, which activities are affected, what it implies for the completion date, and what the contractor has or has not said about it. The analysis should be grounded in the schedule data, not the metric definition.
Then address the metrics that "failed" but are fine. This is the section most review reports omit entirely, and its absence is what makes contractors dismiss reviews as box-ticking. Explicitly acknowledging that the lag failures are legitimate curing times, and that the hard constraints are in the correct locations for this contract, demonstrates that the reviewer has actually read the schedule rather than run an automated tool and printed the results.
Recommended actions should be ranked by criticality. A critical path failure and negative float on a key milestone are priority-one actions that require contractor response before the next reporting period. A high-duration activity on a long-lead procurement item that is performing to programme is not an action at all — it is an observation, if it is even worth mentioning.
Finally, where metrics are ambiguous — where the reviewer cannot determine from the schedule data alone whether a finding is legitimate — the report should include a specific request for clarification. Not a general "the contractor should explain their approach to constraints" but "please provide the contractual or technical basis for the constraint applied to activity XYZ, ref. schedule ID 1047." Specific questions get specific answers. General observations get general deflection.
The conversation with the contractor
Schedule review is not an adversarial process, even when it produces uncomfortable findings. The goal is a schedule that accurately represents the project, that the contractor is committed to, and that the client can use to make decisions. A review process that generates defensiveness and dispute achieves none of those things.
The most important technique is to ask rather than assert. "Can you walk me through why this constraint is here" is a different conversation from "this constraint is non-compliant." The first invites the contractor to explain their thinking; you may learn that the constraint is entirely justified. The second puts the contractor immediately on the defensive and forecloses the possibility of a collaborative resolution. And if you are wrong — if the constraint is justified and you have flagged it as non-compliant without checking — you have damaged your credibility for the rest of the review.
The same applies to logic gaps and high float. "I can see activity 1047 has no successor — can you help me understand how it connects to the commissioning sequence" is more useful than "activity 1047 has missing logic." The contractor may have a sequencing reason that is not visible in the schedule data. Or they may not have a reason, in which case the question surfaces the gap more effectively than an assertion does.
Where findings are genuine and significant — negative float, critical path failures, invalid dates — the tone should be direct but not combative. "The schedule is currently calculating negative float of 12 working days on the commissioning milestone. We need to understand the contractor's position on this before we can accept the schedule submission" is clear, professional, and actionable. It does not accuse. It states what the data shows and what the consequence is.
It is also worth being explicit about what you are not finding. Telling a contractor "the lags in the concrete sequence look appropriate and we're not raising these as findings" builds trust and demonstrates that the review process is thoughtful rather than mechanical. Contractors who feel that every metric breach will be flagged regardless of context will start gaming the metrics rather than building better schedules. Contractors who feel the review process distinguishes legitimate from problematic findings will engage with it more seriously.
The objective of a DCMA 14 review is not a clean dashboard. It is a schedule that accurately models the project, that the planner stands behind, and that the client can use for decision-making. The metrics are a starting point for that conversation, not the end of it.