Why Your Project Timeline Slips
Common Gantt Chart Mistakes Builders Make

Every builder who has run more than a handful of jobs knows the feeling: the programme looked tight but achievable at the start, and three weeks in it is already two weeks behind. The work is progressing, the trades are showing up, and yet the completion date keeps moving. More often than not the problem was not bad luck or bad trades - it was a programme that was wrong before the first shovel went in.

The Purpose of a Programme

A Gantt chart is not a presentation tool for the client. It is a management tool for the builder - a model of how the job will unfold that lets you spot conflicts, plan deliveries, book trades in the right sequence and make early decisions before they become expensive late ones. A programme that exists only as a PDF to attach to the contract is not doing any of that work.

The mistakes below are not about the software or the format. They are about how builders think about time and sequence when constructing a programme, and why those habits produce timelines that slip almost by design.

Mistake 1: Durations Based on Hope Rather Than History

The most common programme error is duration estimates that reflect how long a task would take if everything went well. On a real job, everything does not go well. Material deliveries are late, inspections do not pass first time, weather interrupts groundworks, and a trade that is due on site Monday calls on Friday to say they have a problem on another job.

A more robust approach is to build durations from actuals wherever possible. If your plastering subcontractor consistently takes 5 days to plaster a house of this size, do not put 3.5 days in the programme because that is what you hope he will do this time. If building control typically takes 48 hours to confirm an inspection date, do not assume 24. Use what you know, not what you wish.

Where you have no historical data - particularly on first-time tasks or unusual specifications - add explicit contingency. A 10-15% duration buffer on the critical path is not pessimism; it is the difference between a programme that absorbs a single day of rain and one that falls apart the first week groundworks run.

Mistake 2: Missing Dependencies

A dependency is a link between tasks where one cannot start until another is finished. Getting dependencies wrong - or simply not mapping them at all - produces a programme that looks complete but does not reflect how the job actually has to unfold.

Common dependencies that builders miss:

• Inspection hold points. Foundations cannot be backfilled until building control has inspected and signed off the excavation. First-fix electrics and plumbing cannot be covered until the building control officer has done the first-fix inspection. These are not flexible - if the inspection is missed, work stops.
• Material lead times. Structural steel, bespoke windows, engineered timber trusses and some brickwork products have lead times of 4-12 weeks. If you order when you need them rather than when the programme requires delivery, the frame sits waiting and the critical path extends by weeks.
• Drying and curing times. Screed must dry before flooring is laid. Concrete must cure before it is loaded. Plaster must dry before decorating begins. These are physical constraints, not scheduling preferences. Compressing them produces defects, not efficiency.
• Utility connections. A new electricity supply from the DNO can take 6-12 weeks to arrange after application. If this is not in the programme as a task with its own lead time, you will reach practical completion with a building that has no power.

Mistake 3: The Critical Path Is Not Identified

The critical path is the sequence of dependent tasks that determines the minimum duration of the project. Any delay on a critical path task delays the whole project by exactly the same amount. Tasks that are not on the critical path have float - they can slip by a certain number of days without affecting the end date.

Most builder programmes do not identify the critical path explicitly. This means that when a problem occurs, it is not immediately clear whether it matters to the completion date or not. A day lost on a task with two weeks of float is irrelevant. A day lost on a critical path task needs immediate recovery action - reassigning resources, extending working hours, or adjusting the sequence elsewhere.

You do not need specialist software to identify a critical path. The process is:

1. Map all tasks and their dependencies in sequence
2. Add up the duration of each possible path through the programme from start to finish
3. The longest path is the critical path - it sets the project end date
4. Any task on this path with zero float is critical - flag it clearly

On a typical house extension, the critical path usually runs through groundworks, structural frame, roof, first fix, plaster, dry-out and second fix. Decoration and externals often have float unless they are tied to a fixed handover date.

Mistake 4: Parallel Tasks Treated as Sequential

The opposite error from missing dependencies is treating tasks as dependent when they can actually run in parallel. On many jobs, a conservative programmer puts tasks end-to-end when some of them could overlap or run simultaneously, adding unnecessary time to the programme.

Examples where parallelism is often missed:

• External scaffolding erection can often start while internal groundworks are still finishing
• Groundwork drainage runs can proceed in parallel with blockwork to damp-proof course level in a different part of the site
• Decorating can start in rooms where second fix is complete while second fix continues in others
• External works (landscaping, paths, fencing) can start as soon as the main structure is watertight, not only after internal completion

Look at each pair of tasks in your programme and ask: does one genuinely need to be complete before the other can start, or is that assumption just habit? Removing unnecessary sequential links can compress a programme by days or weeks without changing any individual task duration.

Mistake 5: No Float for Client Decisions

A client-supplied decision is a dependency. If the kitchen layout needs to be confirmed before the first-fix plumbing can be set out, that decision has a deadline - and if the client misses it, the plumber waits and the programme slips.

Most programmes do not include client decision points as explicit tasks with deadlines. This means when a client takes two weeks to confirm a tile choice that was needed last week, there is no clear record of who caused the delay and no trigger for the builder to communicate urgency before the impact hits the programme.

Add client decisions to the programme as milestones with clear due dates: "Kitchen layout confirmed - required by [date]", "Window colour selected - required by [date]". Send reminders two weeks before each deadline and record the actual date when the decision arrives. This creates a clear programme delay record if a decision arrives late, which matters when discussing the impact on the contract completion date.

Mistake 6: The Programme Is Not Updated

A programme written at the start of the job and never touched again is not a management tool - it is a historical artefact. Within two or three weeks of starting, most jobs have diverged from the original plan in at least a few places. If the programme is not updated to reflect actual progress, it cannot tell you anything useful about where the job is going.

A working programme is updated at least weekly:

• Actual start and finish dates recorded as tasks complete
• Remaining durations revised on tasks in progress
• New tasks added for scope changes or unforeseen works
• The forecast completion date recalculated from current position

This weekly update does not need to take long - 20-30 minutes at the end of Friday is enough on a typical domestic project. The discipline of doing it forces you to confront the current position honestly rather than operating on an optimistic assumption that things will catch up on their own.

Mistake 7: One Programme for the Whole Job

A single high-level programme showing 15-20 tasks across 20 weeks is useful for the client and for milestone tracking. It is not useful for managing the next two weeks on site. High-level programmes compress detail that matters - within "first fix electrics" there might be five separate visits from the electrician on different days, interspersed with other trades. At the high level this looks like a single 5-day bar. On the ground it requires careful sequencing with the plumber, plasterer and structural carpenter.

Consider running two programmes in parallel: a high-level summary for the client and contract milestones, and a rolling 4-6 week detailed look-ahead for day-to-day site management. The look-ahead is updated weekly and covers every trade visit, delivery, inspection and decision point in the near term in enough detail to act on.

Building a Programme That Holds

A programme that holds is built from the right inputs and maintained through the life of the job. The practical steps:

1. List every task, including inspections, utility connections, material deliveries, client decisions and any drying or curing periods - not just the trade activities
2. Map dependencies for every task before assigning any dates
3. Assign durations from actuals wherever possible; add explicit contingency on the critical path
4. Identify the critical path and mark critical tasks clearly
5. Order long-lead materials as soon as the programme shows when they are needed - do not wait until they are on the horizon
6. Update weekly with actual progress and revised forecasts
7. Communicate early when the forecast completion date changes - one week's notice is more useful to a client than one day's notice

When the Programme Slips Anyway

Even a well-constructed programme will slip on some jobs. The goal is not a perfect forecast - it is early visibility of problems while there is still time to respond. A programme that tells you on week 6 that you are heading for a 2-week overrun on week 20 gives you 14 weeks to find recovery actions. The same information delivered on week 18 gives you two weeks to explain the situation to the client and negotiate the implications.

The difference between a builder who manages delays well and one who is constantly firefighting is almost always programme discipline - not luck, not trade quality, and not the complexity of the job. The tools are simple. The discipline of using them consistently is where most builders fall short.