Five critical path mistakes that quietly wreck programmes

Mistake one: treating the critical path as static. The path you baselined in January is not the path you are on in April. Every completed task, every delay, and every scope change can re-route it. If your tooling does not recalculate the path automatically when dates change, you are navigating with an old map.

Mistake two: ignoring near-critical tasks. A task with two days of float is one bad stand-up away from being critical. Teams that only watch zero-float tasks get blindsided when a near-critical chain slips and instantly becomes the new critical path. Track everything with float below five days.

Mistake three: forgetting lead and lag. A Finish-to-Start dependency with a ten-day lag is very different from a plain Finish-to-Start. When lag time is recorded in people’s heads instead of in the plan, float calculations are wrong and the "critical" path is fiction.

Mistake four: ignoring resource constraints. Two parallel tasks with no logical dependency still cannot both happen if they need the same specialist. Resource-constrained scheduling can silently extend your real end date beyond what pure dependency logic suggests.

Mistake five: keeping the path secret. If only the PMO knows which tasks are critical, the people doing those tasks cannot protect them. Colour the critical path on the shared Gantt view, show total float in the task table, and let every task owner see exactly how much slack they do or do not have.