How to Use DCMA-14 as an Owner's Representative

Owners use the DCMA-14 by running the contractor's native schedule through a checking tool, comparing results with the 14 thresholds, and requiring a written explanation for flagged metrics. The specification should name the metrics, the tool and the response expected, because DCMA's thresholds are advisory and tool counts differ.

This guide is for owner-side schedulers and project staff working from the DCMA-14 schedule assessment. The aim is a clause and a review routine that produce better schedules, not just cleaner scorecards.

How should an owner's representative think about the DCMA-14?

Start with what the source says. The 14 checks are in Section 4 of the DCMA EVMS Program Analysis Pamphlet (DCMA-EA PAM 200.1, October 2012), written to help analysts find problem areas in a contractor's integrated master schedule. The pamphlet calls them a framework for asking educated questions, says a red metric is not in itself synonymous with failure, and says correction is not necessarily required, but it should be understood (DCMA-EA PAM 200.1).

An owner's contract is what makes a threshold binding. A 2022 NDIA presentation with a DCMA co-author states that the 14-point check is still evident in contract CDRLs, while no longer being used by DCMA's EVMS Center (NDIA IPMD slides). Treat claims about current DCMA practice with care and anchor your requirements in your own contract text.

What should the specification say instead of "must pass DCMA-14"?

A blanket clause invites argument over definitions and invites gaming (see passing DCMA versus a good schedule). A usable clause is specific. Cover each item in the table.

The tool matters more than most owners expect. Mosaic notes that tool implementations differ and are not certified by DCMA or any other body, and that the biggest variance is which tasks count in the denominator (Mosaic WP1088). Naming the tool and version removes a recurring dispute.

Which thresholds should an owner adopt?

Use the pamphlet's numbers as a starting point and say so. The pamphlet states 5% for most percentage checks, and zero for leads and invalid dates.

Be cautious about mandating zero leads across the board. A blanket ban can be contentious, and SmartPM warns that rejecting negative lag may create owner liability; that is a secondary legal view, so have counsel review any such clause.

What might the specification language look like?

Illustrative example: the outline below is a drafting aid, not contract language, and should be reviewed by counsel before use.

• The Contractor shall submit the schedule in native format with each baseline, update and revision.
• The Owner will assess each submittal using [named tool, version] with the metrics, populations and thresholds listed in Attachment [X].
• For each metric outside its threshold, the Contractor shall submit a written explanation identifying affected activities, the cause, the impact on completion and any corrective action.
• A metric outside its threshold is not by itself a basis for rejection. The following are: invalid dates, unexplained negative float, and logic changes made without disclosure in the narrative.
• The Contractor shall state the progress scheduling option used and shall not change it without Owner approval.

The last item is easy to forget. A change from Retained Logic to Progress Override moves float with no change in the field, as explained in the negative float guide.

Worked example: reviewing one update

Illustrative example: the figures are assumed for a mid-project update on a building job with 600 incomplete tasks.

The review letter that follows is short. It rejects the update on the four invalid dates, asks for explanations on constraints, negative float and BEI, and notes that CPLI has dropped for two updates. It does not demand a zero for everything. That keeps the contractor focused on defects and the schedule moving.

What should you review on each update?

Not every metric changes monthly. A practical routine separates baseline checks from update checks.

• At baseline: logic, leads, lags, relationship types, hard constraints, high float, high duration, resources (if required), and the critical path test.
• At every update: invalid dates, negative float, missed tasks, CPLI and BEI. Also re-check the structure metrics if logic changed.
• At every revision: the structure metrics again, plus a comparison of changed logic against the narrative.

Trend the results across updates instead of treating each month as a standalone pass or fail. SmartPM makes this point about binary readings hiding root causes (SmartPM). A contractor whose missed task percentage climbs from 2% to 4% to 6% is giving you early information about BEI and CPLI before any date moves.

How do you handle flagged metrics?

Ask for a short, structured explanation for each red result, with activity IDs. Reasonable content is cause, impact, corrective action, owner and date. For negative float, the pamphlet asks for an explanation and a corrective action plan.

Use rejection sparingly. Invalid dates are a good rejection reason because they indicate the update was not completed. Unexplained negative float and unexplained constraint use are reasonable too. A hard-constraint count of 5.5% with a good explanation is a conversation, not a default.

How do you cover what the DCMA-14 omits?

The 14 checks do not test duration basis, scope completeness, risk analysis, traceability or baseline control. GAO's Schedule Assessment Guide (GAO-16-89G) lists ten best practices that cover many of these (GAO-16-89G). Owners can borrow selectively.

• Resources. Specify the loading you need. The DCMA check applies only if the contractor loads resources, as covered in resources in a construction schedule.
• Risk analysis. Decide whether you want a schedule risk analysis and at what milestones.
• Baseline control. Define how the baseline is approved, revised and compared.
• Narrative. Require a written narrative describing the plan, changes and open issues with each update.

This guide does not describe agency-specific requirements, because no published USACE, NAVFAC or GSA specification citing the DCMA-14 was confirmed in the research behind it. Check the specification of the agency or program you work for.

What mistakes do owner reviewers make?

• Reading the scorecard instead of the schedule.
• Rejecting a schedule for a 5.1% result with a sound explanation.
• Comparing results from different tools month to month.
• Reviewing only the baseline and ignoring update drift.
• Asking for DCMA-14 compliance without naming the tool or population.
• Requiring a native file but not opening it, so the critical path is never traced.