DCMA-14 Metric 1 — Logic: What It Measures and How to Fix Failures

The DCMA logic metric measures the share of incomplete tasks that are missing a predecessor, a successor, or both. The DCMA pamphlet says that share should not exceed 5%, and anything above 5% is a flag. In a construction schedule it is the best single indicator that activities are tied into the network, so float and the critical path calculate reliably.

This is metric 1 of the DCMA-14 schedule assessment. The rest of this article defines it precisely, shows the arithmetic, and walks through finding and fixing the gaps.

How does DCMA define the logic metric?

The formula is:

Missing Logic % = incomplete tasks missing a predecessor and/or a successor ÷ incomplete tasks

A task counts once, however many links it lacks. An activity with no predecessor and no successor is one failure, not two. The threshold is 5%, and the pamphlet says more than 5% "should be considered a flag."

The population matters. The pamphlet says the analysis "should exclude Completed tasks, LOE tasks, Subprojects (Summary tasks in MS Project), and Milestones." Mosaic Projects' white paper on the 14 points notes the 2009 and 2012 versions differ on population, and that tools implement the counting differently. The biggest variance is which tasks land in the denominator.

Logic density versus link density

Search results often blur two ideas. DCMA's metric is a pass-or-flag count of tasks with missing links. Link density is the average number of relationships per activity, such as 1.8 links per task. Link density is not a DCMA metric and has no DCMA threshold.

They answer different questions. A schedule can average three links per activity and still have 30 orphaned tasks, because the links bunch in one area. Conversely, a clean linear chain of 100 tasks averages about one link per task and has zero missing logic. When someone asks for "logic density," confirm which they mean.

What is the worked example?

Illustrative example, with assumed counts: a schedule has 520 activities. Of those, 190 are complete, 45 are level-of-effort or summary rows, and 35 are milestones. That leaves 250 incomplete detail tasks.

The result is 5.2%, just over the line and a flag. Notice that the 2 overlapping tasks count once, so adding 6 and 9 would overstate the failure at 15. Also note that dropping the 35 milestones from the denominator is what the pamphlet prescribes. A tool that included all 520 activities would show 2.5% for the same file and look compliant.

Why do construction schedules fail the logic check?

Most failures come from a few repeatable patterns:

• Dangling activities. The activity has a start predecessor but nothing after it, or a successor but no start link. Mosaic describes these as activities with only a start or finish tie.
• Imported or summarized subcontractor schedules. A sub's detail is pasted in, tied to a phase milestone, but not to the activities that really drive it.
• Deleted activities. Removing a task without relinking its neighbors leaves its old successors with no predecessor.
• Unlinked punch-list and closeout work. These activities sit at the tail of the schedule with no successor to the completion milestone.
• Assumed sequence. The scheduler plans in the order of the WBS and relies on that visual order instead of links. Dates then reflect the activity table, not the logic.

GAO's Schedule Assessment Guide, GAO-16-89G makes the same point under its sequencing best practice: all activities need to be properly linked so dates follow from logic.

How do I check for missing logic in P6?

The approach is a filter on the relationship counts, then a review pass. P6 also has a schedule check report that includes a section on open ends, but menu names differ between versions, so confirm field and section names in your version.

1. Add columns for predecessor and successor counts, or use a filter that selects activities with none.
2. Restrict the filter to incomplete activities and exclude activity types outside the DCMA population: level-of-effort, WBS summary and, to match the pamphlet, milestones.
3. Sort or group by WBS so clusters are visible. Fifteen gaps in one subcontract package point to a pasted-in schedule.
4. Export the list with activity IDs, names and the missing side (predecessor, successor or both).
5. Compute the percentage with the pamphlet's denominator and record it, along with the date and tool.

Run the filter on a copy if you plan to repair in bulk, and record a before-and-after count for the submittal narrative.

How do I fix missing logic without creating false links?

The goal is real dependencies, not zero on the report. Adding a link to every orphan to satisfy the metric produces a different problem: constraints that look like logic but are not.

Work through each gap by asking two questions: what must finish or start before this work can begin, and what can't begin until this work is done?

For the table, assume the fixes reflect the real construction sequence. Each fix attaches the orphan at both ends, so float is driven by the network from then on.

Which tasks should connect to the completion milestones?

Every chain should eventually reach a project completion milestone, and every chain should start from a tie to the project start or a real predecessor. The pamphlet excludes milestones from the count, but a start or finish milestone with no logic is still a defect in practice. A finish milestone with no predecessors is a milestone that cannot be late.

What does missing logic do to other metrics?

Missing logic rarely shows up alone. The pamphlet states that high float "may be a result of missing predecessors and/or successors," because an activity with no successor drifts toward the end of the project in the backward pass and picks up float. See the high float article for how the 44-working-day cutoff behaves.

The critical path test is affected too. Missing predecessors and successors are the stated cause of broken logic, so a slip on the critical path may not reach the end milestone. And constraint-driven dates can hide the gap: a task with a forced date looks scheduled, so check hard constraints alongside logic.

Link types matter a little as well. Paired start-to-start and finish-to-finish links count differently between tools, as covered in relationship types, so a count produced by one tool may not match another's.

What are the edge cases that change the count?

Three cases regularly cause arguments about the number.

Paired links. A start-to-start link with a matching finish-to-finish link between the same two activities is common in construction. Mosaic notes that MS Project does not allow paired SS and FF links between the same two activities while P6 does, so the same logic may be built differently and counted differently. An activity tied only by an SS predecessor and an FF successor is fine, but one tied only by SS on the predecessor side has no finish constraint on its successor path.

Open ends by design. A long-lead procurement item may have a predecessor in the submittal chain and a successor that lives on an installation activity in another contractor's schedule. If the tie is genuinely external, document it and, where possible, add an interface milestone so the end is not open.

Actualized work. Completed tasks are excluded, but an in-progress task still counts. A common error is leaving the successor off an activity because "it's already started." The activity is incomplete and must still link forward.

When a reviewer and a contractor disagree on the percentage, compare populations before comparing activities.

How will a reviewer challenge a logic result?

Expect three questions. Which tool and population produced the percentage? Which flagged activities are real gaps, and which are deliberate open ends, such as a procurement item whose successor lives in another contract? And what changed since the last update, because a rising count suggests new work is being added without ties.

A defensible response is a short table: activity ID, the missing side, the reason, and the repair or a date for it. DCMA's text on flags applies here: correction may not always be required, but the reason should be understood.