The Project That Would Not Slip
Northwind's ERP migration runs to 40 tasks, scheduled from the start date, with a go-live milestone the client has fixed contractually at 14 November. The project manager pinned eleven tasks with Must Start On constraints because vendors committed to those dates, set the go-live milestone's predecessor to a Finish No Later Than constraint, and added Fixed Dates to two tasks whose dates kept changing on their own. When the integration task grew from 10 days to 18, the project end date did not move and the timeline still reads 14 November. Meanwhile the resource managers report the assigned developers are booked at 130% in the two weeks before go-live. The project manager insists Workfront is 'lying about the dates' and wants to reschedule the whole project from the completion date.
1. Explain why the end date did not move when the integration task grew, and what the constraints are concealing.
Read the worked answer
The plan is not wrong; it is over-constrained, and over-constraint produces silence rather than an error.
- Must Start On pins a task to a date regardless of its predecessor. When the integration task expands, successors carrying Must Start On do not move, the growth is absorbed as negative float, and nothing downstream propagates to the milestone.
- Fixed Dates pins both start and finish. Those two tasks are now decorative: they will not respond to predecessors or duration changes at all.
- Finish No Later Than is a limit, not a driver. It stops the milestone drifting past 14 November; it does not pull earlier work forward to protect that date.
Net effect: every constraint that was added to stop dates moving has removed the schedule's ability to warn anyone. The honest read is that the critical path now runs through the constraint, and the plan has no slack information left to give.
The PM's instinct to reschedule from the completion date is not automatically the answer - that mode changes which tasks are driven by predecessors versus successors and can produce a different set of surprises. First make the constraints visible: report all tasks by constraint type, then question each one.
2. Recommend a corrected approach for the vendor-fixed dates and the contractual go-live. Include what you would do about the Fixed Dates tasks and how you would tell whether the plan is feasible.
Read the worked answer
Vendor dates. A vendor commitment is a constraint on the vendor, not a scheduling instruction. Replace Must Start On with Start No Earlier Than where the truth is 'the vendor cannot start before this,' and leave the task As Soon As Possible otherwise. Start No Earlier Than blocks early starts without blocking a late one, so slippage still propagates.
Fixed Dates tasks. Unscheduled them: schedule As Soon As Possible and fix the underlying cause (usually a duration type fighting the plan, or assignments with their own dates). A task that ignores its predecessors is a data-integrity problem, not a feature.
Go-live. Keep the milestone as a Must Finish On milestone only if it is genuinely immovable, and protect it with an explicit buffer task feeding it, so float is a designed number rather than an accident. Do not model the deadline by constraining every task upstream.
Feasibility test. After cleaning constraints, run the timeline and read the critical path and total slack. If integration now finishes after 14 November, that is the finding - surface it in the steering meeting with the two or three realistic options (descope, add capacity, move the date) rather than letting constraints hide it.
Cross-check with resourcing. The 130% booking is the same problem seen from the other side: pinned dates compressed the assignments. If the growth is real, the capacity conversation and the schedule conversation are one conversation.