Construction scheduling
The Builder's Guide to Critical Path Scheduling
Most construction programs fail the same way: a bar chart drawn once at contract signing, never re-baselined, and quietly ignored by week six. Critical path scheduling fixes that by making the program describe how the build actually behaves — which tasks hold up the handover date, and which ones have room to move.
What the critical path actually is
The critical path is the longest chain of dependent tasks through the job. Every task on it has zero float: delay one day, and handover moves one day. On a typical two-storey residential build the chain usually runs site set-out → footings → slab pour and cure → frame → roof → lock-up → internal linings → finishes → practical completion. Everything hanging off that spine — landscaping, driveway, fit-off of external services — has slack and can absorb a hit without touching the end date.
The practical value is triage. When a supplier lets you down, you need to know in seconds whether it costs you a day of handover or nothing at all. That answer only exists if the dependencies are modelled.
Modelling dependencies properly
Link tasks by the physical reason one follows another, not by the dates you'd like them to land on. Four relationships cover almost every residential sequence:
- Finish-to-start — the default. Frame can't start until the slab is poured and cured.
- Start-to-start with a lag — electrical rough-in starts two days after plumbing rough-in starts, so the trades stagger rather than collide.
- Finish-to-finish — painting and second fix carpentry need to land together before the final clean.
- Lag for cure and dry time — a seven-day slab cure is not a task anyone performs, but it is a real constraint. Model it as a lag so it can never be squeezed to win a day on paper.
Float is a budget, so spend it
Float — the number of days a task can slip before it becomes critical — is the most under-used number in construction. Treat it as a budget. A task with eight days of float is where you park the trade who needs flexibility, and where you absorb a late delivery without a phone call to the client.
Watch for float draining away. A task that had ten days of slack in March and two in May is on its way to becoming critical, and it will surprise you the week it does. Reviewing the float column weekly is a cheaper habit than re-sequencing a job under pressure.
Site conditions shift — re-baseline instead of arguing
Rock in the footing trench, a wet fortnight, a variation approved three weeks after it was raised: site conditions move, and the program has to move with them. The failure mode isn't the delay itself, it's a schedule that stops matching reality and therefore stops being consulted.
Keep the original baseline, apply the change, and compare. That comparison is what turns a delay into a documented extension of time rather than a dispute — and it's the same evidence a client needs when a variation genuinely pushes handover.
A weekly rhythm that keeps it honest
- Mark completed tasks and update percent complete on anything in progress.
- Recalculate the critical path — it moves as work lands early or late.
- Check which tasks lost float this week and why.
- Confirm the next two weeks of trades against the updated dates.
- Log the reason for every date change so the audit trail writes itself.
Twenty minutes a week is the entire cost. The return is that nobody on site is working from a program that expired in month two.
Bringing it into SiteStride
SiteStride computes the critical path from your task dependencies and shows float directly on the Gantt, so a slipped pour immediately shows what it does — or doesn't do — to handover. Trades assigned to tasks move with the dates, and every change lands in the site log alongside the notes, RFIs and variations that caused it.
That's the whole idea behind building schedules that ship: one plan, kept current, that the site and the office both trust. See what the construction scheduling software does in practice.

