The DCMA 14-point schedule metrics

The fourteen checks that most schedule-quality software runs, and almost nobody reads in the original. This page quotes the source at length, because the source is a US Government work and the usual second-hand summaries lose the two things that matter most: what population the metrics are counted over, and how firmly the source disclaims them.

The source

The authority is DCMA-EA PAM 200.1, Earned Value Management System (EVMS) Program Analysis Pamphlet, Defense Contract Management Agency, Engineering and Analysis Directorate, 29 October 2012. The fourteen metrics are section 4, pages 28 to 32 of a 49-page document.

Its face page carries the marking "RELEASABILITY – UNLIMITED" and declares the pamphlet cleared for public release. It bears no copyright notice, and as a work of the United States Government it may be quoted freely. That is why this page quotes it rather than paraphrasing it.

A caution on sourcing. Copies of earlier DCMA training material circulate widely, the numbering differs between revisions, and some files offered as the pamphlet are not the pamphlet at all — one commonly linked "2009" PDF is a saved web challenge page. Everything below is cited to PAM 200.1 and to nothing else.

The scope caveat, first

This is the single most common reason two tools disagree about the same file, so it goes before the list rather than after it. Section 4.0 states:

The DCMA 14 Point Schedule Metrics were developed to identify potential problem areas with a contractor's IMS. This analysis should exclude Completed tasks, LOE tasks, Subprojects (called Summary tasks in MS Project), and Milestones.

Four exclusions, and each one changes every percentage on the page. A schedule with 900 milestones and 3,000 detail activities produces one set of numbers if milestones are counted and a different set if they are not. Before comparing any two 14-point results, ask what each one counted.

The same paragraph continues:

These metrics provide the analyst with a framework for asking educated questions and performing follow-up research. The identification of a "red" metric is not in and of itself synonymous with failure but rather an indicator or a catalyst to dig deeper in the analysis for understanding the reason for the situation. Consequently, correction of that metric is not necessarily required, but it should be understood.

The fourteen

Thresholds below are the source's own, from the sections named. Nothing in this table is this project's threshold.

Four of those rows are routinely restated wrongly.

Hard constraints are enumerated at §4.5 as Must-Finish-On, Must-Start-On, Start-No-Later-Than and Finish-No-Later-Than. The pamphlet names As-Soon-As- Possible, Start-No-Earlier-Than and Finish-No-Earlier-Than as soft constraints that "enable the schedule to be logic-driven", and sets no limit on their number.

High duration has two conditions, not one: the baseline duration must exceed 44 working days and the baseline start must fall within the detail planning period or rolling wave. A tool that drops the second condition counts every far-future placeholder.

High float uses 44 working days, which §4.6 glosses as two months, and gives a diagnosis rather than a verdict: high float "may be a result of missing predecessors and/or successors", and above 5% "the network may be unstable and may not be logic-driven".

Resources is conditional. §4.10 notes that the IMS Data Item Description "does not require the contractor to load resources directly into the schedule", and the metric is calculated only "if the contractor does resource load their schedule". A zero here can mean a clean schedule or an unresourced one.

CPLI, in words and symbols

§3.1.2.3 defines the Critical Path Length Index as "a measure of the efficiency required to complete a milestone on-time". The formula as printed is:

CPLI = (CPL + TF) / CPL

In words: take the critical path length, add the total float, and divide the result by the critical path length. CPL is the length in work days from time now until the milestone being measured; TF is the total float at that milestone, which may be negative.

The pamphlet's own reading of the result: a CPLI of 1.00 means one day's work must be accomplished for every day that passes; below 1.00 the schedule is "inefficient with regard to meeting the baseline date of the milestone (i.e. going to finish late)"; above 1.00 it is running ahead. "A CPLI less than 0.95 should be considered a flag and requires further investigation."

§3.1.2.3 also asks the analyst to record which completion milestone was chosen and which method identified the critical path. That requirement survives any disagreement about the metric, and the standards crosswalk returns to it, because the definition of the critical path is itself contested.

BEI, and a contradiction in the source

§3.1.2.4 describes the Baseline Execution Index as a measure of task throughput: it "compares the cumulative number of tasks completed to the cumulative number of tasks with a baseline finish date on or before the current reporting period", and "Tasks missing baseline finish dates are included in the denominator." Below 0.95 is a flag.

The formula as printed in the pamphlet does not say that. It reads:

BEIcum = Total # of Tasks Complete / (Total # of Tasks Completed Before Now + Total # of Tasks Missing Baseline Finish Date)

In words: the printed denominator is tasks completed before now, plus tasks missing a baseline finish date — which divides completed tasks by completed tasks, and is not the quantity the surrounding prose describes.

The pamphlet's own numbered procedure, in the same section, defines the denominator differently again, and consistently with the prose. It defines Baseline Count as "The number of tasks with a baseline finish date on or before the reporting period end", and step 8 instructs the analyst to "Divide the 'Total number of tasks completed' by the 'Baseline Count' to get the BEI value."

So the printed formula appears to be a typographical error, and the worked steps carry the intended calculation. This page reports both rather than silently correcting a primary document: a reader meeting two tools that report different BEIs for one file is better served by knowing the source contradicts itself than by a tidy formula.

The same section requires a companion metric. "The BEI is always compared against the Hit Task Percentage." Hit Task Percentage is the number of tasks completed on or before their baseline finish date, divided by the number of tasks with a baseline finish date within the current reporting period. It cannot exceed 1. The pair exists because BEI "does not provide insight into tasks completed early or late… as long as the task was completed prior to time now" — a contractor can post a healthy BEI by completing large numbers of the wrong tasks.

Current status of the document

Read this carefully, because it is easy to overstate in either direction.

PAM 200.1 is the last formally published DCMA statement of the fourteen metrics that could be located. No cancellation, rescission or superseding issuance could be obtained: dcma.mil returns HTTP 403 on every path attempted, so the agency's own current library could not be read directly.

What could be read, through an April 2025 archive snapshot of DCMA's EVMS page, is that the agency's current compliance work is organised around a different instrument entirely — the DECM metric set (DCMA EVMS Compliance Metrics), at Metrics Templates version 7.0, under nine Business Practices maintained as recently as November 2025. The fourteen metrics, CPLI and BEI do not appear in that structure.

That is the honest statement of the position: a 2012 pamphlet that remains the published source, an agency whose live compliance work is built on something else, and no document establishing that the fourteen were withdrawn or superseded. Anyone telling you otherwise should be asked for the issuance number.

What the fourteen do not settle

Two free, thorough treatments already exist, and both are worth reading in full rather than summarised here.

Ron Winter, PSP, DCMA 14-Point Schedule Assessment, 7 January 2011, 25 pages — ronwinterconsulting.com. A construction-side reading that asks whether the protocol is "a good thing or might it be a 'ticking time bomb'" in a litigation-oriented industry. Its conclusion is blunt: the paper recommends that findings from a 14-point check "not be used in a legal dispute situation to either prove or disprove the fitness of any particular schedule or the expertise of any particular Scheduler." Its appendix of cross-examination questions is the most useful part for anyone who may have to defend or attack such a result — which revision was used, what study supports 44 working days as a limit, and whether capping float encourages schedulers to sequester it.

Mosaic Projects white paper WP1088, DCMA 14-Point Assessment Metrics (CC-BY 3.0) — mosaicprojects.com.au. Its central caution is that "conforming to the checks does not of itself indicate the schedule is sensible, realistic, and achievable; correlation is not the same a causation." It also records the practical problem this page opened with. No independent attestation exists for any tool's implementation of the checks — DCMA does not vouch for one and neither does any other body — so results vary between tools, and "The biggest issue is around counting of the number of tasks to be considered."

And the position this site takes, which is not ours but GAO's. Appendix VII of GAO-16-89G lists the fourteen and then states: "However, DCMA's 14PA thresholds are not compliance triggers. Rather, they are used as a starting point toward an objective analysis of the schedule."

GAO declines to publish thresholds of its own at all. Appendix VI of the same guide: "No 'pass-or-fail' thresholds or tripwires are associated with the measures. Measures are evaluated in context with qualitative program information and any documented justification. Moreover, severity of the errors or anomalies takes precedence over quantity because any error can potentially affect the reliability of the entire schedule network."

A red metric is a prompt to look. It is not a finding.

How this project handles them

Schedule Forensics computes the fourteen as health metrics and reports each one with the origin of its threshold attached, including the metrics for which the pamphlet states no number. They are reported separately from clause findings and are not treated as a verdict on a schedule, because no document reviewed here requires them and their author disclaims them.

What the tool reports and what it refuses to decide is set out in what the result can support and the rule reference.

Related: GAO-16-89G and the ten best practices · Standards crosswalk · Federal construction specifications · Glossary

Source: web/pages/dcma-14-point.md. Source commit date: 2026-09-11.