Task dependencies: why adding durations gives the wrong deadline
A four-task example separates elapsed time, labor cost and shared resources before you estimate deadline confidence.
Two 10-day tasks do not always take 20 days
Consider this deterministic example. Discovery takes 4 days. Design takes 6 days after discovery. Integration takes 10 days after discovery. Acceptance takes 3 days after both design and integration. Assume separate people can perform design and integration concurrently.
| Task | Duration | Predecessor | Start | Finish |
|---|---|---|---|---|
| Discovery | 4 | None | 0 | 4 |
| Design | 6 | Discovery | 4 | 10 |
| Integration | 10 | Discovery | 4 | 14 |
| Acceptance | 3 | Design, integration | 14 | 17 |
Adding durations gives 23 task-days. Elapsed project duration is 17 days: 4 + max(6, 10) + 3. At a $500 daily burn rate on every task, labor cost remains 23 × $500 = $11,500. Concurrent work shortens the calendar without deleting work.
What changes when durations are uncertain
Replace each fixed duration with optimistic, likely and pessimistic estimates. Each simulated run samples durations and schedules the same dependency graph. Sometimes design may finish after integration. The controlling path can switch. Adding the individual P80 durations does not generally produce the project's P80 duration.
A delay on design might initially fit inside its four-day gap before acceptance. A larger delay can extend the project. The same delay on integration extends this deterministic example immediately. Where a risk lands matters as much as its size.
A dependency graph is not resource scheduling
If one person must do both design and integration, the 17-day example is infeasible despite its valid dependency graph. BidVariance does not automatically resolve shared staffing. You can explicitly sequence those tasks when that reflects the plan, or adjust the model to represent the actual delivery arrangement. Do not interpret a dependency-only result as evidence that enough people are available.
The engine uses calendar days for deadline comparisons. A task estimated in working days must be translated consistently to elapsed calendar duration, with weekends and holidays reflected in your assumptions. A five-working-day task is not automatically five calendar days.
Review the network before the probability
- Give every task its real prerequisites.
- Check whether concurrent tasks can actually be staffed.
- Put a task-specific delay on the affected task; reserve project-wide delay for effects on final delivery.
- Enter both start and promised completion dates.
- Review deadline confidence and cost together: a feasible date can still be an unprofitable bid.
Use the free deadline calculator for a single duration range. For a connected task network, follow the app setup guide and read how each simulation is scheduled.