Critical Path Test (CPT)

What it is

The Critical Path Test checks whether the schedule's critical path is valid and actuallydrives the project completion date. It is check #12 of the DCMA 14-Point Assessment.
The test adds a deliberate delay to an incomplete activity on the critical path, recalculatesthe schedule, and measures how far the project finish moves. On a sound critical path, thefinish should slip by the same amount as the delay. If it slips less, or not at all, something inthe network is absorbing the delay instead of passing it through to completion.

Why it matters

Every forecast, delay analysis, and recovery plan built on a schedule assumes the criticalpath is real. If the path is broken, the schedule can show a completion date that wouldn'tmove even if critical work slipped in the field. The Critical Path Test confirms that the logicbehaves the way the schedule claims it does.

DCMA acceptance criteria

The project completion date should move by an amount equal to the delay applied to thecritical path. A finish that moves less than the delay means the test fails.

How SmartPM runs the test

SmartPM applies the delay to a critical activity, recalculates the schedule, and comparesthe resulting finish slip against the delay. Two settings control the test:

Delay added to the critical task (working days):

The number of working daysSmartPM adds to the critical activity before recalculating. Enter any whole number of days.

Allowed difference in the finish slip (working days):

How far the finish slip can differfrom the applied delay and still pass. Enter any whole number of days; 0 requires anexact day-for-day match.

The test passes when the difference between the applied delay and the actual finish slipis within the allowed difference. For example, with a 20-day delay and an alloweddifference of 2 days:

A small allowed difference is useful when the critical activity and the finish milestone siton different calendars, since the same delay can convert to a slightly different number ofworking days at the finish. Keep it small; a large tolerance can hide a path that's partiallybroken. Choose a delay large enough to exceed any gap between the forecast finish and aconstrained date, so a constraint can't quietly absorb it.

What causes a failure

A failed test usually points to one of these conditions:

• Hard constraints such as Mandatory Finish or Finish On on the completion milestoneor along the path, holding dates in place regardless of logic.

• Missing logic where activities lack a predecessor or successor and the delay hasnowhere to flow.

• Dangling activities where SS or FF relationships leave the start or finish of an activityunconnected, so the delay doesn't carry forward.

• Large lags or calendar issues that shift or absorb time between the delayed activityand the finish.

Related SmartPM Metrics

Several existing SmartPM metrics flag the conditions that cause a path to fail. They showwhere the risk is; the Critical Path Test confirms whether the path actually holds when it'sstressed.

SmartPM Metric	How it Relates
Critical Path %	Shows how much of the schedule is critical; an unusually low or high value can signal a distorted path
Missing Logic	Identifies open ends that can stop a delay from reaching the finish
Dangling Activities	Identifies SS/FF patterns that leave activity starts or finishes unconstrained
Constraints	Identifies dates that can override logic and absorb a delay
High Float Activities	Often a symptom of missing or broken logic in the network