BEI and CPLI: The DCMA Performance Metrics That Predict Project Completion

The BEI schedule metric, or Baseline Execution Index, is the ratio of tasks actually completed to tasks that were baselined to be complete by the status date. A value of 1.00 means the project is on pace. DCMA treats a BEI below 0.95 as a flag requiring additional investigation.

The Critical Path Length Index (CPLI) and BEI are metrics 13 and 14 of the DCMA-14 schedule assessment. Unlike most of the other checks, they do not test schedule structure. They test performance.

What is the BEI schedule metric and how is it calculated?

The pamphlet defines BEI as the cumulative number of tasks completed divided by the cumulative number of tasks with a baseline finish on or before the reporting period. Tasks that are missing a baseline finish are added to the denominator (DCMA-EA PAM 200.1).

```
BEI = cumulative tasks completed
÷ cumulative tasks with a baseline finish on or before the status date
```

A BEI below 0.95 should be considered a flag and requires additional investigation. The pamphlet notes that BEI ignores whether tasks finished early or late, which is why it is read alongside Hit Task %.

Illustrative example: assume 100 tasks were baselined to finish on or before the status date, and 90 are complete.

If 104 tasks are complete, the BEI is 1.04, because some completed tasks were baselined for a later period. The index counts tasks, not duration or value, so ten small tasks weigh the same as ten major ones.

How is CPLI calculated?

The Critical Path Length Index measures whether the remaining critical path can be completed in the remaining time. The pamphlet's formula is (critical path length + total float) divided by critical path length, where the critical path length is the number of work days from the status date to the milestone being measured (DCMA-EA PAM 200.1).

```
CPLI = (CPL + TF) ÷ CPL
CPL = work days from the status date to the milestone measured
TF = total float of the milestone, in work days
```

A CPLI of 1.00 means you must accomplish a day of work per day. Below 1.00 the work is forecast to finish late. Above 1.00 it is forecast to finish early. The pamphlet considers a CPLI below 0.95 a flag.

Illustrative example: assume 100 work days remain on the critical path to the substantial completion milestone, and the milestone has total float of -10 work days.

Because the numerator includes total float, negative float reduces CPLI directly. Positive float raises it. The index depends on which milestone you measure, so state the milestone along with the number.

Does DCMA flag BEI at 0.95 or 1.0?

DCMA flags BEI and CPLI below 0.95. Many secondary sources, including vendor guides, state 1.0 or "at least 1.0" as the threshold (SmartPM; Mosaic WP1088). The difference is one of framing:

When you cite DCMA, use 0.95. When you set your own internal threshold, you can choose a stricter value, but say it is your own. Owners writing specifications should name the number they want instead of relying on the label "DCMA."

What is the difference between BEI and Hit Task %?

BEI ignores whether a task finished early or late; it just counts completed tasks against baselined tasks. Hit Task % is its on-time companion: tasks completed on or before the baseline date, divided by tasks with a baseline finish in the current fiscal month (DCMA-EA PAM 200.1).

A project can have a healthy BEI built on completing easy tasks while the critical ones slip. A weak Hit Task % with a strong BEI suggests tasks are finishing late rather than not at all. Read both, and look at which tasks make up the gap.

How do you use BEI and CPLI to forecast completion?

Track both indices at every update and plot them as trend lines instead of reading a single number. A BEI that declines from 1.02 to 0.97 to 0.91 over three updates says execution is slipping, even before any metric crosses a threshold. Mosaic's white paper reports that studies have indicated BEI can be an earlier warning than many other tools, but cites no source, so treat that as an opinion until you verify it on your own data (Mosaic WP1088).

CPLI looks forward; BEI looks backward. A project with BEI below 0.95 and CPLI near 1.00 has missed tasks but the critical path still holds, so the misses are probably off the critical path or recoverable. A project with BEI near 1.00 and CPLI of 0.90 has completed what it planned, but the critical path itself is stretched, which can mean the baseline was optimistic or the completed work was not the driving work.

Neither index replaces a schedule narrative. They tell you where to look.

Worked example: reading a trend across four updates

Illustrative example: the figures below are assumed to show how the two indices behave together on one project over four monthly updates, with CPLI measured to substantial completion.

BEI crosses the 0.95 flag in March, while CPLI does not cross it until April. In this assumed case BEI gave the earlier signal, which is consistent with how the two are built: BEI reacts to every missed task, while CPLI reacts only when the delay reaches the measured milestone. The response is not to react to the number but to ask which 28 tasks were missed by April, who owns them, and whether they sit on the driving path.

How do you check BEI in P6?

You can compute BEI from a baseline comparison, or use a schedule analysis tool that calculates it for you. A manual approach works for small schedules.

1. Assign the baseline and confirm the status date.
2. Filter activities where the baseline finish is on or before the status date, excluding the same populations you exclude for the other checks (level-of-effort, summary and milestone tasks, depending on your specification).
3. Count the filtered activities. This is the denominator.
4. Count how many of those are complete (actual finish present). This is the numerator.
5. Divide, and record the date, the baseline used and the exclusion rules.

Record the method in the narrative, because small choices such as whether milestones count change the result. If two parties compute BEI with different tools or filters, agree the method first and compare second.

What affects BEI and CPLI accuracy?

• Baseline quality. BEI depends on the baseline finish dates. If the baseline was changed mid-project, past BEI values do not compare with current ones.
• Task granularity. Many small tasks make BEI respond quickly; a few long ones make it lumpy. See high duration activities.
• Status accuracy. Progress entered after the cut-off, or invalid dates, change which tasks count as complete. See invalid dates.
• Milestone choice. CPLI changes with the target milestone and its float.
• Tool differences. Software counts tasks differently, especially around the denominator, and the implementations are not certified by DCMA or any other body.
• Gaming. Splitting tasks into trivial pieces inflates BEI. A reviewer who watches the count of tasks as well as the ratio will spot it, as discussed in passing DCMA versus having a good schedule.

Common mistakes with BEI and CPLI

• Quoting 1.0 as the DCMA threshold when the pamphlet says 0.95.
• Computing BEI on the whole schedule instead of cumulative to the status date.
• Reporting CPLI without naming the milestone.
• Using duration-weighted or cost-weighted progress and calling the result BEI.
• Treating a BEI above 1.00 as proof that the critical path is healthy.