Five CPM Scheduling Mistakes I See on Every Audit

I audit construction programmes for a living, and the same five defects show up in roughly 80% of them. Each one quietly distorts the critical path and the float that the team is supposed to be managing. None of them are difficult to fix; the difficulty is in spotting them and persuading the planner to clean them up.

First, open-ended activities — tasks with no predecessor or no successor. Every activity except the project start and finish must be tied at both ends. An open end is invisible to the critical path engine and will silently distort float, often inflating it on activities that are actually time-sensitive. Most P6 and MS Project audits find between five and twenty open ends. Run an open-end report every Friday; do not let it accumulate.

Second, missing logic between trades. A schedule that runs structure, services and finishes as three parallel chains without crossover links is fiction. The structure chain might finish on day 200, the services chain on day 220, but if services genuinely cannot start in a level until structure is complete in that level, that constraint must be modelled with finish-to-start links per zone. Push for explicit handover milestones between disciplines and link the trades through them.

Third, hammock and level-of-effort activities masquerading as work. A 'project management' hammock spanning the whole job inflates total float on the activities running underneath it and makes it impossible to read the real critical path. The schedule looks healthier than it is. Flag hammocks separately, do not delete them, but exclude them from float and critical path reports.

Fourth, lag abuse. Long lags hide missing activities. If you see a 14-day finish-to-start lag, ask what is actually happening in those 14 days. Curing time? Add it as a 'concrete cure' activity. Drying time? Add it as a 'screed dry' activity. Procurement? That is a delivery activity. A schedule with explicit work activities for every passing day is auditable; a schedule with lags is not.

Fifth, hardcoded constraints. 'Must Finish On' dates and 'Start No Earlier Than' constraints override logic and turn the schedule into a wish list. The CPM engine will obey the constraint and quietly distort float across the network to make it work. Replace constraints with deadlines (which flag but do not override) and let the float tell the truth about whether the date is achievable.

Two bonus defects worth a mention. Activities longer than the reporting cycle — a 60-day activity in a project with a 14-day status update is uncontrollable; split it. And calendars that do not match site reality — winter calendars, weather assumptions, public holidays. A schedule built on a default 5-day calendar in a region with 12 wet days per month is already a claim.

The fix for all of these is the same: a weekly schedule health check. Run open-end, missing-logic, long-lag, hardcoded-constraint and activity-duration reports. Twenty minutes a week from the planner. Build it into the schedule update cycle and the schedule stays defensible — both for internal forecasting and, eventually, for any retrospective delay analysis you may need to do.