If One Task Slips Three Days, How Late Is the Project?

In the first case study, while building this ERP project's WBS, Claude added three dependency lines of its own accord (the first case study). One of them was "migration execution & verification → integration test execution" — the common-sense observation that integration testing means nothing without cleansed data, pinned down as a single line. That line goes to work in this installment.

Over the last two installments we saw SPI 0.84, extended the migration verification task by three days, and replayed the record of doing so. The remaining question is this article's title: if one task slips three days, how late is the project? The answer, up front — at first it was zero days, and the zero was the problem. Not an ad; a lab report. Same stage as the previous two installments: the re-anchored replica (code MCG-26B on screen), execution week 7.

Minimum viable theory — the grammar of lines

The arrows in a Gantt have a grammar. FS (Finish-to-Start) — the successor starts after the predecessor finishes — is the base form, joined by SS (start together), FF (finish together), and the rare SF. A line can carry lag or lead. Put the lines together and you get a graph, and on that graph the longest path with zero slack gets computed — the critical path. A task on the critical path slips a day, the project slips a day. Tasks off the path hold total float, and delays within that float never reach the end date.

Summed up without formulas: delay flows along the lines, float absorbs it, and the critical path is the channel where float is zero. One line on lag's usefulness too — time that is waiting rather than work ("7 days for payment after contract signing") belongs on the line as +7d, not as a fake task; that's what keeps a graph clean.

Lines aren't only drawn between leaf tasks. This project's integration test phase carries the four module unit tests as predecessors (the tree's predecessor cell shows 1.4.2, 1.5.2 with a +2 folded away), and a line drawn on a phase expands to its leaves at computation time. "The integration phase opens when all unit tests are done" becomes one line instead of four — and the closer the graph's grammar gets to human sentences, the fewer lines get forgotten.

Our starting state: a 92-day plan with a 12-node critical path — from planning through requirements and design review, on through the four modules' unit tests, defect fixing, and user training, down to stabilization.

The Gantt before the adjustment — month zoom on the back half of the plan, with migration, integration test, training, and open phases chained by dependency arrows; the system open milestone diamond sits just ahead of the red critical tail

We pushed it three days — and nothing happened

Before we extended the duration, the migration verification node's panel had this to say:

The detail panel of the migration verification node — under the header, a green check reading "15 days of slack — even if late, no impact on the overall schedule," and a VALIDATION box showing Off critical path · 15d total float

"15 days of slack — even if late, no impact on the overall schedule." The tool translates float into a human sentence. And when we stretched the duration from 7 to 10 days, it was as foretold. The successor — integration test execution — moved five calendar days out (three working days of delay spreading across a weekend), and there the propagation stopped. System open: unmoved. Project finish: unmoved. The recalculation shifted downstream dates we never touched, and the float swallowed the whole delay.

The Gantt right after the three-day extension — the migration verification bar is longer and the integration test execution bar has shifted right, while the system open diamond and the open-and-stabilization phase stay put; the end of the shifted bar now sits to the right of the open diamond

On an Excel schedule this is where a different kind of evening begins: fix one cell, then trace every row that references it by eye, repairing one at a time. Here the computation flowed along the lines and the human read the result. Note, too, that none of this automatic movement shows up in the change history from last installment — the human touched one duration, and one duration is what the history holds. The rest belongs to the computation.

Doubting an answer of zero

But look at that capture again. The end of the shifted integration test bar sits to the right of the system open diamond. We would be opening the system before integration testing finishes. An obvious contradiction — and not a warning in sight.

CPM didn't lie. It honored exactly the lines we gave it. In the original plan, test execution ended just before the open, so nobody drew the "tests finish, then we open" line — drawing it wouldn't have changed anything. When the delay broke that assumption, the missing line was computed as missing. That is what the 15 days of slack really were: mostly not slack at all, but phantom float manufactured by an omitted dependency.

If the 100% Rule is the discipline that catches missing work (Part 1), the dependency graph has no such discipline yet. A missing line is quiet — until a delay comes knocking.

Schedule practice has a pre-kickoff inspection for exactly this hole: sweep for tasks with no successors (dangling activities) and ask of each one, "if this runs late, does it truly hurt nothing?" Our integration test execution was precisely such a node — no successors, generous float. A checklist would have caught it in five minutes; we caught it only after the delay knocked. Even in the age of tools that compute the graph for you, interrogating the graph remains a human job.

Fill in one line and the critical path moves house

As the final touch of the adjustment session, we drew the line — integration test execution → open & stabilization, FS. The recalculation ran, and this time everything moved.

The Gantt after the dependency was added — the migration verification and integration test execution bars have turned critical red, the system open diamond has moved right, the four unit test bars have gone back to normal blue, and the toolbar total now reads 92 days

System open: three working days — five calendar days — later. The 87-day total became 92.
Critical path: swapped from 12 nodes to 8. The four unit tests, defect fixing, and user training left the critical path; migration verification and integration test execution joined it. The red channel in the Gantt moved house wholesale.
The node's panel warning flipped too — "15 days of slack" became "no slack — if this task is late, the project finish is late."

A moved critical path is not a statistic — it means the watch list changed. Yesterday the tasks a PM needed to check every morning were four unit tests. From today they are migration verification and integration test execution. One delay replaced the project's surveillance list, and no human had to recompute it — the red channel shows the new address.

Now the title's question can be answered. If one task slips three days, how late is the project? — Three working days if the graph is honest; zero if the graph has a hole. Zero is the scarier answer. Three days provokes a response; zero produces a false calm.

One side observation worth recording: the re-anchored replica's back half computed a few days differently from the original, because the original's execution window contained the Chuseok and Hangul Day holidays and the replica's window doesn't. The scheduler reads the holiday calendar — one more reason the dates in these captures differ from the canon installments.

Honestly — what it doesn't do

Per this series' custom, the misses go on the record too.

It won't find the missing line for you. This article's plot twist is also its core limitation. Tests overrunning the open milestone drew no warning. A heuristic like "task ends past a milestone with no path to it" would have exposed the hole before any delay did.
No what-if. You can't preview "if I draw this line, how far does the open move?" You draw it for real and wait for the recalculation (⌘Z undoes it).
Recalculation is asynchronous. For some tens of seconds after an edit, stale dates can linger. On a shared project that's a "why hasn't it changed yet?" moment.
Float is visible only in the panel. Neither the Gantt bars nor the tree columns show slack, so there's no at-a-glance view of "where the float lives and how much."

Closing

One event ran through this trilogy. The legacy data the risk register had warned about actually grabbed an ankle (Part 9), SPI dragged the delay into the open as a number (Part 10), the change history kept the record of the response (Part 11), and the dependency graph computed where the delay would land (this installment). Four screens, one question with four faces — when plan and reality diverge, what do you base the next decision on?

Gantt arrows are not decoration. Those lines are what the PM knows about the project, written down as a graph, and the computation is exactly as honest as that knowledge. Drawing the lines is still a human's job — to borrow the first installment's phrasing, recall belongs to the machine, but commitment belongs to the human. What this tool does is show you, in numbers and a red channel, the moment those commitments begin to contradict each other.

So here is the one thing to try on your own schedule this week: find the tasks with no successors and ask, "if this runs late, does it truly hurt no one?" If it hurts, a line is missing. We had that question asked for us by a delay, and the tuition was five days.