The 600-day test: the five-minute experiment that exposes a defended date

The mechanics

Copy the file. On the copy, pick an incomplete task on the critical path and add 600 working days to its remaining duration. Recalculate. Watch the project finish.

In a schedule with sound logic, the finish moves by approximately the same amount: 600 days in, roughly 600 days out, less whatever genuine float and calendar effects absorb. That is the whole test. A healthy network transmits the shock; anything that dampens it is worth a line in your review.

When the finish does not move

Four causes cover almost every case, and each one is a different finding:

• A hard constraint is holding the date. A mandatory finish or must-finish-on somewhere downstream pins the milestone in place. The schedule is asserting a date rather than calculating one, and negative float is quietly piling up behind the constraint where nobody reads it.
• A parallel path was secretly the driver. If the finish moves, but by far less than 600 days, another chain took over as the longest path. Your critical path is mislabelled, and every management conversation based on it has been about the wrong work.
• The logic dead-ends. The task you extended has no successor chain that reaches completion. The delay falls into a hole. The network is severed at that point, and any task upstream of the break can slip forever without the finish noticing.
• The finish milestone is not linked to the work. A completion milestone with no meaningful predecessors is a printed date wearing a milestone symbol. Nothing in the programme can ever move it, which is precisely why some programmes are built that way.

Why 600 days

The number is deliberately absurd. A 20-day bump can be swallowed by legitimate float or by a near-parallel path, and you learn nothing. 600 working days swamps any plausible float value and any parallel path on any normal programme, so the only way the finish survives intact is structural interference. The test works because a sound schedule has no honest way to absorb it.

Variations worth running

Run it against each contractual milestone, not just project finish. A programme can pass the test to completion while a sectional handover milestone sits constrained and severed from the work that delivers it, and the sectional dates are usually where the liquidated damages live.

The reverse test is just as useful: on a copy, remove a suspect constraint and recalculate. The date the milestone snaps to is what the network really thinks, and the gap between that and the constrained date is the size of the fiction the constraint has been maintaining. Schedulers who defend a constraint as "just a target" tend to go quiet when the unconstrained date lands months later.

Practical safety

Always on a copy, never the live file. This sounds obvious until the day someone runs it in the shared P6 database and the 600-day duration ends up in Thursday's client export. In P6 specifically, check the scheduling options on the copy before trusting the result: retained logic versus progress override, calendar for scheduling relationship lag, and multiple-float-path settings all change how the shock propagates, and a test run under different options than the live file tells you about the options, not the schedule.

What to write down

Three fields: which task you extended, how far the finish (or the milestone under test) moved, and the gap between that movement and 600 days. The gap is the finding. It is the measured size of the interference between the work and the date, and it turns "I do not trust this programme" into a number the other side has to explain. A fair counterargument exists: one passing run proves only that one path transmits delay. If the result matters, repeat the test on two or three tasks on different legs of the critical path before signing off.