DCMA 14-Point Schedule Health Check

A reference for the 14 checks FloatCheck runs against 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.

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 — as opposed to a "soft" constraint like Start On or After, or no constraint at all.
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 read by FloatCheck's parser at all — 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's usually 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.
Example: Fails when: 9% of activities carry more than 44 days of float — almost all of them turn out to be missing a successor link, not genuinely slack work.

Negative float

Assessable

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 the most direct, least ambiguous signal in the whole assessment: 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: Assessable directly — 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, full stop.

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

Assessable

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: Assessable directly, though 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

Assessable

Measures: Activities whose forecast finish date has already passed the project's data date, but which aren't marked complete.
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 incomplete activities missed.
Planning Toolkit: Assessable directly — compares each activity's early finish date to the file's own data date, for every activity not marked TK_Complete.
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

Assessable

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 broken critical path is the single most damaging schedule defect there is — every crashing, recovery, or "what does this delay actually cost us" conversation is built on top of it being real.
Threshold: DCMA standard: the project finish date shifts by exactly the added duration, every time.
Planning Toolkit: Assessable, but via a different method than 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. A large disagreement is the same underlying signal (the recorded critical path and the network's actual logic don't agree) reached a different way.
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 — (Baseline Critical Path Length + Total Float) / Baseline Critical Path Length. In plain terms: does the time actually left, plus the float you have, still add up to what the original baseline said the critical path would take?
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.
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's become a de facto industry standard well beyond defense contracting, widely used across construction and infrastructure programme controls.

What Planning Toolkit actually runs

FloatCheck implements 10 of these 14 checks fully from a P6 XER file alone: logic, leads, lags, relationship types, high float, negative float, high duration, invalid dates, missed tasks, and the critical path test (via its own recomputed-float-vs-stored-float comparison, not the textbook 600-day method). Two more — CPLI and BEI — become assessable once you load an optional baseline file alongside your update. Two checks are honestly not assessable today:

Hard constraints (check 5) — the XER's constraint fields aren't read by the parser 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.