How the Schedule Health Score works
The Schedule Health Score is a 0-100 number we compute from your schedule file. It is our composite index, not an official DCMA output. DCMA gives only pass/fail per check. We weight those results and produce a single score so you can track improvement over time.
DCMA (Defense Contract Management Agency) developed the 14-point assessment as a standard way to evaluate whether a project schedule is reliable enough to manage to. Federal agencies use it to vet contractor schedules before committing funds. We built our engine on the same 14 checks, plus 3 additional value checks, because the standard is the best publicly documented framework for schedule health.
The 17 checks and their weights
Each check contributes to the final score proportionally to its weight. A FAIL on a high-weight check hurts more than a FAIL on a low-weight check.
Percentages assume all 17 checks are applicable (total raw points: 119). NA checks are excluded from the denominator at runtime, so the effective weight of remaining checks scales up accordingly.
Threshold: At most 5% of tasks missing a predecessor or successor
Every task except the first and last must have at least one predecessor and one successor. Gaps in the logic network make the schedule uncontrollable: delays cannot propagate, float is unreliable, and the finish date is a guess.
Threshold: A valid critical path must exist and be continuous
The critical path is the longest logical path from project start to finish. If no tasks are marked critical, the network is broken. Without a valid critical path, total float across the project is meaningless.
Threshold: At most 5% of tasks with hard constraints (SNET, SNLT, MSO, MFO)
Hard constraints override logic. When a constrained task cannot move, its successors cannot move either, even when reality changes. High hard-constraint counts produce schedules that do not respond to progress updates.
Threshold: 0% — no tasks with negative total float allowed
Negative total float means the schedule mathematically predicts a late finish before work begins. It is almost always caused by a hard constraint that conflicts with the logic network, or a deadline imposed without adjusting scope.
Threshold: 0% — no negative lags allowed
A negative lag on a Finish-to-Start relationship means a successor starts before its predecessor finishes. This is physically impossible in most cases and hides real work. The engine allows zero tolerance; any occurrence is a FAIL.
Threshold: At most 5% of baseline-eligible tasks missed
Applies to in-progress schedules with a baseline and data date. A task is "missed" when its baseline finish has passed but it is not 100% complete. These are the tasks causing live slippage right now.
Threshold: BEI ≥ 0.95
Ratio of tasks completed to tasks that should be complete by the data date, per baseline. Below 0.95 means more than 5% of tasks are running late against the original plan. Chronic BEI below 0.95 indicates systemic slippage.
Threshold: CPLI ≥ 0.95
CPLI = (remaining float + critical path length) / critical path length. Below 0.95 is a reliable predictor of a late project finish. It accounts for both how far you have to go and how much margin you have left.
Threshold: 0% — no invalid dates allowed
Incomplete tasks with early finish dates before the data date, actual dates after the data date, or finish dates before start dates. These break every downstream calculation that depends on those dates.
Threshold: At most 5% of tasks with total float above 44 working days
Very high float almost always means a missing logic tie or artificially inflated duration. Tasks with 44+ days of float are not contributing to schedule control and are likely disconnected from the network.
Threshold: At most 5% of tasks with duration above 44 working days
Tasks longer than two months are too coarse to measure or manage. Progress cannot be tracked accurately and delays are detected too late to recover. Summary tasks are excluded.
Threshold: At least 90% of relationships must be Finish-to-Start
Finish-to-Start is the only relationship type that maps cleanly to how work happens in the field. SF and FF relationships are hard to manage and often indicate incorrect logic. The engine requires at least 90% FS.
Threshold: At most 5% of relationships with positive lag
Lags represent waiting time. Excessive lags often mask missing activities (the wait is really undocumented work) and create unrealistic float in the network.
Threshold: All work tasks must have a resource or cost assignment
Unresourced tasks cannot be cost-loaded or used for earned-value analysis. If the schedule is not resource-loaded at all, this check returns NA rather than FAIL, since the check is inapplicable to that type of schedule.
Threshold: Average of at least 2.0 logic links per task
A well-connected schedule has each task linking to at least one predecessor and one successor, for an average of 2.0+ link endpoints per task. Below this floor signals widespread open ends beyond what the logic check alone catches.
Threshold: No task with 8 or more predecessors
A task with many converging predecessors is a high-risk merge point. If any one predecessor is late, the merge task is late. Eight or more predecessors on a single task creates a bottleneck that is almost impossible to manage.
Threshold: No task longer than 10% of the total project span
If a single task spans more than 10% of the project duration, it is probably a placeholder or a roll-up that should be decomposed. These tasks produce misleading progress reports and make the schedule unmanageable at the working level.
Honest about the limits: the score is only as good as what is in the file. A schedule with accurate data gets an accurate score. A schedule with placeholder logic or dummy dates will score poorly, which is the point.