DCMA 14-Point Schedule Health Check

A reference for the 14 checks and which FloatCheck can assess from an uploaded P6 schedule — what each one measures, why it matters to a planner, the standard threshold, and what it actually takes to assess it. No upload here, no calculation — this page is static reference material, not a tool.

STATIC REFERENCE · NO ENGINE CALLS · NO JAVASCRIPT

Assessable FloatCheck computes this directly from your XER file.

Limited Computed directly, but an input the check depends on is not applied.

Partial FloatCheck computes a narrower version or a substitute measure, not the DCMA definition.

Needs baseline Only assessable once an optional baseline file is loaded.

Not assessable Needs data this app doesn't read today (resource loading, constraint types).

Jump to a check

Logic
Leads
Lags
Relationship types
Hard constraints
High float
Negative float
High duration
Invalid dates
Resources
Missed tasks
Critical path test
CPLI
BEI

Logic

Assessable

Measures: The percentage of activities missing a predecessor, a successor, or both — "open ends" in the network, excluding the schedule's one true start and one true finish activity.
Why it matters: An activity with no predecessor can be dragged anywhere by whoever's updating the schedule, with no logical reason for its date — the CPM engine can't actually drive it. Every open end is a place where the schedule's dates stop being calculated and start being guessed.
Threshold: DCMA standard: <5% of activities open-ended. FloatCheck uses the same <5% pass / <15% warning / else fail bands.
Planning Toolkit: Assessable directly — counts activities with zero entries in TASKPRED as either a predecessor or a successor, read straight from the uploaded file.
Example: Fails when: 40 of 500 activities (8%) have no predecessor and aren't the project's start milestone — each one's date is only as good as whoever typed it in, not the network logic.

Leads

Assessable

Measures: Relationships carrying negative lag — a "lead," where a successor is allowed to start before its predecessor actually finishes.
Why it matters: A lead quietly overlaps two activities that the relationship type says shouldn't overlap. It's frequently used to force a date to "look right" rather than to represent genuine overlap in the real work, and it distorts float on both sides of the relationship.
Threshold: DCMA standard: 0 relationships with negative lag. Any lead is a fail.
Planning Toolkit: Assessable directly — every predecessor edge carries its own lag_hr from TASKPRED; any value below zero is counted.
Example: Fails when: "Install formwork" is linked Finish-to-Start to "Pour concrete" with a −3 day lag — concrete can start three days before formwork is actually finished, which the relationship type says is impossible.

Lags

Assessable

Measures: Relationships carrying positive lag — a mandatory waiting period inserted between a predecessor finishing and a successor starting.
Why it matters: A little lag is normal (concrete curing time is a textbook example). A schedule leaning on lag everywhere usually means real activities — the curing itself, a delivery wait — were never modelled as their own activities, so nobody can see or manage that time directly.
Threshold: DCMA standard: <5% of relationships carrying positive lag.
Planning Toolkit: Assessable directly — same lag_hr field as the leads check, counting values above zero as a share of all relationships in the file.
Example: Fails when: 60 of 800 relationships (7.5%) carry a lag — several weeks of curing, testing and delivery waits are hidden inside relationships instead of appearing as their own trackable activities.

Relationship types

Assessable

Measures: What share of the schedule's relationships are Finish-to-Start (FS) — "B can't start until A finishes" — versus Start-to-Start, Finish-to-Finish, or Start-to-Finish.
Why it matters: FS is the relationship type that maps cleanly onto how construction sequencing actually works and is the easiest to audit by eye. A schedule full of SS/FF relationships is much harder for a reviewer to sanity-check, and is where logic errors hide most easily.
Threshold: DCMA standard: ≥90% of relationships should be Finish-to-Start.
Planning Toolkit: Assessable directly — every relationship's pred_type is read from TASKPRED and the FS share computed as a percentage of the total.
Example: Fails when: only 78% of relationships are FS — the remaining 22% (SS/FF/SF mixed through the network) make the true driving sequence much harder for a reviewer to verify by inspection.

Hard constraints

Not assessable

Measures: The share of activities carrying a "hard" date constraint — Mandatory Start, Mandatory Finish, Start On, Finish On — and constraints that restrict late dates (P6 Start/Finish On or Before); tools map P6 types differently. A "soft" constraint like Start On or After, or no constraint at all, does not count.
Why it matters: A hard constraint pins an activity's date regardless of what its logic says. Every hard constraint is a place where the network stops driving the schedule and a fixed date takes over instead — float and the critical path both become unreliable around it.
Threshold: DCMA standard: ≤5% of activities carrying a hard constraint.
Planning Toolkit: Not assessable today. The XER's cstr_type/cstr_date fields aren't used by FloatCheck's health check or CPM engine — this isn't a partial estimate, it's genuinely not computed, and the health check says so rather than guessing.
Example: Fails when: 12% of activities carry a Mandatory Start constraint left over from the original baseline — those dates no longer move no matter what happens upstream, silently breaking the logic chain around them.

High float

Assessable

Measures: The share of activities carrying total float above a threshold — standard 44 working days (roughly two months).
Why it matters: Float that high is rarely real slack in the work — it can be a sign an activity is missing a successor it should logically have, so the backward pass never constrains it. High float hides risk rather than describing genuine flexibility.
Threshold: DCMA standard: <5% of activities above 44 working days of total float.
Planning Toolkit: Assessable directly — total float comes straight from FloatCheck's own CPM engine (the same forward/backward pass LeadTime uses), not an estimate. FloatCheck's engine does not apply constraints, actual dates or the data date, so float can differ from P6.
Example: Fails when: 9% of activities carry more than 44 working days of float. Review each for missing successor logic before treating it as real slack.

Negative float

Limited

Measures: Activities whose total float has gone below zero — the network can no longer meet whatever is anchoring the backward pass without a change.
Why it matters: This is a direct signal: it's not "getting tight," the schedule's own logic says a date can no longer be met as things stand. It demands a real decision — recover time, replan, or accept and document the slip.
Threshold: DCMA standard: 0 activities with negative float.
Planning Toolkit: Limited: constraints and must-finish dates are not applied, so negative float from imposed dates is not detected. Total float per activity comes from FloatCheck's own CPM engine; any value below zero is flagged.
Example: Fails when: 6 activities on the facade package show −4 days of float — the current logic and durations can no longer deliver the date those activities are chained to.

High duration

Assessable

Measures: The share of activities with a planned duration above a threshold — standard 44 working days.
Why it matters: A very long single activity is hard to status honestly — "60% complete" on a four-month activity means very little — and hides whatever real internal milestones and risk actually live inside it. Breaking it into shorter activities makes it trackable and gives it real logic ties instead of one long block.
Threshold: DCMA standard: <5% of activities above 44 working days duration.
Planning Toolkit: Assessable directly — duration comes from the file's own target_drtn_hr_cnt (or remain_drtn_hr_cnt for in-progress activities), converted to working days.
Example: Fails when: "Structural steel erection" runs as one 90-day activity — there's no way to tell from the schedule alone whether it's tracking to plan or three weeks behind, because nothing inside it is broken out.

Invalid dates

Partial

Measures: Activities whose actual or forecast dates fall outside a sane range relative to the project's data date — a forecast start in the past, or an actual finish in the future.
Why it matters: These are usually simple update mistakes — a status not applied, a date typed into the wrong field — but they poison every calculation downstream of them (float, the critical path, percent complete) until they're corrected.
Threshold: DCMA standard: 0 activities with invalid dates.
Planning Toolkit: Partial: narrower than the full DCMA definition today — FloatCheck currently checks for activities missing an early start or early finish date entirely, rather than the full past/future-relative-to-data-date comparison.
Example: Fails when: an activity shows an actual finish date three weeks after the file's own data date — work that, per the file, hasn't happened yet is recorded as already complete.

Resources

Not assessable

Measures: The share of activities with at least one resource (labour, equipment, material) assigned.
Why it matters: An unresourced schedule can show a beautiful critical path that's physically impossible — there's no way to know from dates and logic alone whether the crews, plant and materials needed actually exist in the quantities and timeframes the schedule assumes.
Threshold: DCMA standard: 100% of (non-summary, non-LOE) activities resource-loaded.
Planning Toolkit: Not assessable today. FloatCheck's parser doesn't read the XER's TASKRSRC table at all — resource loading is a real, separate parsing effort this app hasn't taken on, not an estimate standing in for one.
Example: Fails when: the earthworks package has fully-logic-driven dates but zero equipment assigned to any activity in it — the schedule can't tell you whether the excavators it needs are even booked.

Missed tasks

Partial

Measures: Activities with a baseline finish on or before the status date that finished late or are not finished, as a share of all baseline-due activities.
Why it matters: This is a direct, countable measure of schedule slippage that's already happened, as opposed to float (which is a measure of risk to dates that haven't happened yet). A high count here means the schedule isn't being kept current with real progress.
Threshold: DCMA standard: ≤5% of baseline-due activities missed.
Planning Toolkit: Partial: FloatCheck counts incomplete activities whose forecast finish is before the XER export date (ERMHDR), not the DCMA baseline measure.
Example: Fails when: 14 activities show a forecast finish two to six weeks before the file's own data date, still marked in-progress — the schedule hasn't been updated to reflect what actually happened on site.

Critical path test

Partial

Measures: Whether the schedule's critical path is genuinely continuous and logic-driven. The textbook DCMA method: add a large arbitrary duration (600 days is the commonly cited reference figure) to one critical activity's remaining duration and confirm the project finish date shifts by exactly that amount — if it doesn't, the "critical" path isn't actually driving completion somewhere.
Why it matters: A critical path that does not drive the finish undermines recovery and delay discussions built on it.
Threshold: DCMA standard: the project finish date shifts by exactly the added duration, every time.
Planning Toolkit: Partial: replaced by a different check, not the textbook 600-day test — FloatCheck recomputes total float independently with its own CPM engine and compares it activity-by-activity to the float already stored in the file by P6, flagging any activity that differs by more than two working days. This is a float-consistency check, not the DCMA Critical Path Test; it does not show whether the critical path drives the finish.
Example: Fails when: 18 activities show a recomputed float more than two working days off from what the file itself reports — the schedule's own stored numbers and its own logic have quietly drifted apart.

CPLI

Needs baseline

Measures: Critical Path Length Index — (Critical Path Length + Total Float) / Critical Path Length, where length runs from the status date to project finish and float is measured to the baseline/contract finish. In plain terms: a CPLI below 1.00 means the remaining critical path is longer than the time left to the baseline or contract finish.
Why it matters: It's a single number answering "is this project still fitting inside its original time budget," independent of whether the finish date itself has moved — two schedules with the same slipped date can have very different CPLIs depending on how much genuine capacity to recover is left.
Threshold: DCMA standard: ≥0.95. A CPLI of 1.00 means the project still fits its baseline time budget exactly; below 1.00 signals a likely delay.
Planning Toolkit: Assessable only when a baseline file is loaded (FloatCheck's optional third upload, alongside the previous/current update pair). With no baseline, this reads "not assessable" rather than a guessed or defaulted value — there's no baseline critical path length to divide by. FloatCheck's version is an approximation: it divides by the baseline's critical path length and adds the lowest float from its own recompute, which is measured to the recomputed finish rather than the baseline/contract finish. Because no contract or must-finish date is applied, this float is normally about zero, so FloatCheck's CPLI will usually read close to 1.00 and should not be used to judge slippage against the contract finish.
Example: Fails when: CPLI comes out at 0.82 — the current driving float plus what's left of the baseline critical path length no longer adds up to the original time budget; real recovery time has been consumed, not just moved around.

BEI

Needs baseline

Measures: Baseline Execution Index — Activities Actually Complete / Activities the Baseline Planned to be Complete by Now. A direct measure of execution pace against the original plan, not against the current (possibly already-revised) schedule.
Why it matters: A project can look fine against its own latest revised schedule while badly missing its original commitments — BEI is the number that keeps that honest, since it never moves the goalposts.
Threshold: DCMA standard: ≥0.95. A BEI of 1.00 means on-pace execution against the baseline; below 1.00 means falling behind it.
Planning Toolkit: Assessable only when a baseline file is loaded, same as CPLI. With no baseline, or when no activities were baseline-due by the current data date, this reads "not assessable" — never a fabricated ratio.
Example: Fails when: 340 of 400 baseline-due activities are actually complete — a BEI of 0.85, meaning execution is running meaningfully behind the pace the original baseline committed to, even if the current schedule's own dates still look achievable.

What this is, and where it comes from

The DCMA 14-Point Assessment was developed by the U.S. Defense Contract Management Agency to check the structural health of a project schedule before trusting the dates it produces. It doesn't ask "is the project late" — it asks whether the schedule's own logic, float, and relationships are sound enough for its dates to mean anything in the first place. It is widely used as a reference well beyond defense contracting, including in construction and infrastructure programme controls.

What Planning Toolkit actually runs

From a P6 XER file alone, FloatCheck computes 7 checks directly; Invalid dates (#9) and Missed tasks (#11) are narrower versions; #12 is replaced by a float-consistency check. Of the 7, six are Assessable (logic, leads, lags, relationship types, high float, high duration) and negative float is Limited, because constraints and must-finish dates are not applied. Checks 9, 11 and 12 are marked Partial. Two more — CPLI and BEI — become assessable once you load an optional baseline file alongside your update. Two checks are not assessable today:

Hard constraints (check 5) — the XER's constraint fields aren't used by the health check yet.
Resources (check 10) — resource loading (the XER's TASKRSRC table) isn't parsed; this is a genuinely separate parsing effort FloatCheck hasn't taken on.

FloatCheck's own health check tab states this the same way this page does — a check that can't be assessed reads "Not assessable," never a default, a zero standing in for missing data, or a guess.