Delay propagation
Delay propagation is the way a delay on one task moves the tasks that depend on it, directly or through a chain, until slack in the plan absorbs it or it reaches the project's finish date. It is also called a schedule cascade.
A delay moves along the dependency links. At each successor, the plan's slack takes what it can; what is left passes on to the next link. A merge point, where a task waits for several others, can hide part of a delay or pass it on in full.
This is why the finish date rarely moves by exactly the delay: it moves by the delay minus the slack along the path it travels.
Worked example
| Task | Duration | Depends on | Scheduled | Total float | After the delay |
|---|---|---|---|---|---|
| 1. Design | 5 days | None | Days 1 to 5 | 0 days | Unchanged |
| 2. Build | 10 days | 1 | Days 6 to 15 | 0 days | Unchanged |
| 3. Data migration | 8 days | 1 | Days 6 to 13 | 2 days | Days 6 to 19 |
| 4. Testing | 5 days | 2, 3 | Days 16 to 20 | 0 days | Days 20 to 24 |
| 5. Go-live | Milestone | 4 | Day 21 | 0 days | Day 25 |
The delay: Data migration takes 6 days longer.
Data migration has 2 days of float because Testing also waits for Build. A delay of 6 days uses that float and passes 4 days on: Testing and Go-live move by 4 days, and Go-live lands on day 25.
Open this example in the free delay simulator to change the durations, the links or the delay and watch the schedule move.