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.
Scoring is deterministic: the same file scored under the same profile gets the same number, every time. There is no AI judgment in the score itself, and every engine release must pass an automated regression gate that pins known scores before it can deploy, so your score cannot drift by accident.
The 17 checks, and how the 14 scored ones are weighted
Only the 14 DCMA checks are scored; each contributes to the final score in proportion to its weight, so a FAIL on a high-weight check hurts more than one on a low-weight check. The 3 value checks (15–17) are reported for insight but carry no weight.
Only the 14 DCMA checks are scored; their weights total 104 points, and each percentage below is that check’s share of the 104. The 3 value checks (15–17) are reported but carry no score weight. Percentages assume every scored check is applicable; NA checks are excluded from the denominator at runtime, so the effective weight of the remaining scored checks scales up accordingly.
Your Schedule Health Score is always a number from 0 to 100. Here is how we get there. We run 17 checks, but only the 14 DCMA checks are scored; each carries a weight based on how much it affects whether a schedule will hold, 104 weight points in total. Your score is the share of the applicable points your schedule earns: pass a check and you keep its points, fail it and you lose them. If a check does not apply to your file, we leave it out of the total so it never counts against you. The 3 value checks (15–17) are reported for insight but never affect the score. The 104 points are just the internal scale. The number you see is normalized to 0 to 100, so you can compare any two schedules and track the same one over time.
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: An injected delay on the critical path must flow day-for-day to the project finish
We inject a 600-day delay into an in-progress critical task and confirm the project finish moves with it. If the delay is absorbed (by missing links or hard constraints), the finish date is not actually driven by the network and cannot be trusted.
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.
Beyond the score: schedule risk & confidence
The score measures how well the schedule is built. A separate Monte Carlo analysis estimates how likely it is to finish on time: a P50/P80 confidence date and the tasks that drive the risk.
How schedule risk and confidence analysis works →