Five critical path mistakes that quietly wreck programmes

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.

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.

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.

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.

Keeping the path secret

If only the PMO knows which tasks are critical, the people doing those tasks cannot protect them. Show total float in the shared task table, filter it to zero in a saved view everyone can open, and let every task owner see exactly how much slack they do or do not have.