Top 20 Scheduling Mistakes in Construction

Ranked roughly by how much damage each one does to the decisions you make from the file. The first five account for most of what goes wrong.

The five that break the schedule

1. Tasks with no predecessor or no successor

A task with no successor pushes nothing. A task with no predecessor gets pushed by nothing. Either way it has left the network, and when reality slips, that task stays where it is.

Fix: every task except the first and the last needs both. Filter on missing links before every issue of the schedule.

2. Hard constraints instead of logic

Must Start On, Must Finish On, Finish No Later Than — each one pins a segment of the network to a fixed date and stops delay propagating through it.

Usually applied by someone trying to make the schedule display a date that was requested rather than calculated.

Fix: As Soon As Possible by default. Soft constraints (No Earlier Than) are fine for real external dates — deliveries, permits, site handover. Every hard constraint needs a written reason.

3. Linking summary tasks

Dependencies on summary tasks corrupt the CPM calculation and produce a critical path that runs through rollup bars instead of real work.

Fix: link detail tasks only. Summary tasks exist to roll up, not to sequence.

4. Never setting the status date

Actual dates get entered, remaining work never gets rescheduled, and the status date is left blank. MS Project then leaves planned work sitting in the past while reporting a finish date that assumes nothing slipped.

Fix: set the status date, then reschedule uncompleted work to start after it. Both steps, every update.

5. Not testing whether the critical path works

A critical path exists in every file. Whether delaying a task on it delays the project is a separate question, and most people never check.

Fix: add 600 days to a critical task, recalculate, confirm the finish moves by roughly 600 days, then undo. If it does not move, something is absorbing the delay.

The five that make it unrealistic

6. Negative lag to force overlap

Negative lag pulls a successor backwards to create overlap that was never modelled. It distorts the critical path and hides the real sequencing decision.

Fix: model the overlap properly with a Start-to-Start link plus a positive lag, or split the predecessor into stages.

7. Positive lag doing the work of an activity

Ten days of lag between pour and strike represents cure time. Nobody owns it, no resource is consumed, no report shows it. When it needs to become fourteen days, nobody notices.

Fix: if the time represents real work or a real constraint, make it an activity. Keep lag for genuinely passive waiting, and keep it rare.

8. Activities that are too long

A 120-day task cannot be reported on monthly. It sits at "about 40%" for a quarter.

Fix: target durations at or below your reporting interval. Anything over roughly 44 working days deserves individual justification.

9. Ignoring negative float

Negative float means the schedule is declaring a date impossible. Left in the file across revisions, it means somebody saw a red number and looked away.

Fix: trace it to its source constraint or deadline every revision. Either resolve it or document why it stands.

10. Very high float treated as comfort

Two hundred days of float is not margin. It is almost always loose logic — the task has links, but links that do not tie it to anything relevant.

Fix: review anything above roughly 44 days of float. Ask what actually constrains that task.

The five that come from the plan, not the software

11. Missing scope

Commissioning, testing, permit cycles, utility connections, rework allowance, supplier lead times. The schedule can be technically flawless and still forecast a date that was never achievable.

Fix: check the end of the schedule specifically. Handover and commissioning are the phases most often compressed into one bar.

12. Durations with no basis

Numbers that came from a meeting rather than from production rates, historical data or a quantity divided by a crew output.

Fix: record the basis alongside the duration. Quantity ÷ productivity ÷ crew size. Where it is judgement, say so.

13. Ignoring weather and seasonality

Earthworks in the wet season, concrete in extreme heat, external finishes in winter — planned as if the calendar were uniform.

Fix: use calendars with realistic non-working periods, or apply seasonal productivity factors to affected activities.

14. Resource conflicts nobody looked at

The same crew scheduled on three activities in the same week, in a schedule nobody resource-levelled or even inspected.

Fix: even without full resource loading, check that key crews and major plant are not double-booked at peaks.

15. Contingency hidden inside durations

Every activity padded by 20% "to be safe". The padding is invisible, so it cannot be managed, and Parkinson's Law consumes it silently.

Fix: estimate at realistic durations and hold contingency as a declared, visible buffer that someone owns.

The five that break trust and auditability

16. Duplicate task names

Three tasks called "Concrete pour". Cost cannot be allocated, claims cannot be traced, and no revision comparison will work.

Fix: unique names, prefixed by location or WBS. "Concrete pour — Block B, level 3".

17. Generic or truncated names

"Works", "Phase 2", "Misc". The reader cannot tell what was scoped.

Fix: verb plus object plus location. Minimum five words is a reasonable floor.

18. Milestones with duration

A milestone with three days of duration is not a milestone. Contractual deliverables and payment triggers stop being readable.

Fix: milestones are zero duration. Anything with duration is an activity.

19. Rebaselining to hide variance

The forecast slips, so the baseline moves, and the variance disappears. Now nothing can be compared across revisions and the whole control history resets.

Fix: rebaseline only for approved scope or programme change. Record every rebaseline with date and reason, and keep the previous baseline.

20. Issuing without comparing to the previous revision

The schedule is issued each month and nobody diffs it. Tasks are deleted, durations changed, logic rewired, and the recipient has no way to know.

Fix: a revision comparison with every issue — what changed, what was added, what was deleted. If your comparison tool matches tasks by ID alone it will produce nonsense; matching must consider the task description too.

The single check that catches the most

If you only run one test before issuing: filter for tasks with no successor.

It is fast, it needs no add-in, and it catches the most damaging defect on the list. A schedule where 30% of tasks push nothing is not forecasting anything, no matter how good the bars look.

Frequently asked questions

Which of these does MS Project warn you about? Essentially none. MS Project will let you link summary tasks, apply constraints that break the critical path, and leave planned work in the past without a single warning.

Is it ever acceptable to use a hard constraint? Rarely, and always with a written reason. A contractual milestone that must be tested against reality is better modelled as a deadline, which shows negative float when missed instead of silently freezing the network.

How many of these can be checked automatically? Sixteen of the twenty are mechanically measurable from the file. Missing scope, duration basis, weather assumptions and resource conflicts need human judgement.

What is the fastest way to review someone else's schedule? Four numbers, in order: percentage of tasks without logic, percentage with hard constraints, count of tasks with negative float, and whether a status date exists at all. If the fourth is missing, the first three are describing a file that was never updated.

BaselinePlan builds low-cost quality and revision-comparison tools for MS Project. Sixteen of the twenty checks above run automatically against an XML export.