Construction scheduling: stop program blowouts

TL;DR: Programs blow out for boring, predictable reasons: dependencies nobody mapped, buffers in the wrong places, weather treated as a surprise instead of a statistic, and lead times discovered the week the material was needed. Build the program from the dependency chain backwards, put float where the risk actually lives (wet trades, inspections, long-lead orders), plan against your region's real rain record and update the program every week. A schedule you don't maintain isn't a schedule. It's a drawing of your optimism from six weeks ago.

Construction scheduling is the skill that separates builders who finish near the date they promised from builders who spend the last third of every job apologising. The frustrating part is that most blowouts aren't caused by anything exotic. Nobody's program fails because of a once-in-a-century event. Programs fail because the frame stage was booked before the slab had cured, because the windows were ordered after lockup was already on the calendar, or because a fortnight of February rain in Brisbane somehow counted as bad luck. This guide covers how to build a program that survives contact with a real Australian job site: dependencies first, buffers where they belong, weather as an input, and a weekly routine that keeps the thing alive.

Why programs blow out (it's rarely one big thing)

Talk to builders about their worst overruns and a pattern shows up fast. The blowout is almost never one catastrophic event. It's a chain of small slips that compound because the program had no way to absorb them.

The usual suspects:

Unmapped dependencies. The program says "frame: week 4" but nobody wrote down that frame depends on slab cure, plus the frame inspection, plus the truss delivery that has a three-week lead time. When one link slips, everything after it slips, and the trades booked downstream scatter to other jobs.
Buffers in the wrong place. Plenty of builders pad every task by a day or two. That hides the float where you can't manage it and trains everyone to burn it. The tasks that actually need protection, wet trades, approvals, long-lead materials, get the same thin padding as hanging doors.
Weather treated as an exception. Rain in a Melbourne winter is not an exception. It's the base case. If the program assumes five dry working days a week through July, the program is wrong on the day it's printed.
Trade availability discovered late. You can't hold a good carpentry crew on a maybe. Book late and you take whoever's free, at whatever rate the market's charging. If you want a sense of what that market looks like right now, see our guide to carpenter day rates in Australia for 2026.
No update rhythm. The program was accurate on day one and never touched again. By week six it describes a fictional job.

Fix those five and you've fixed most of the problem. The rest of this article works through how.

Map the dependency chain before you touch a calendar

The first version of your program shouldn't have dates on it at all. It should be a list of tasks and the answer to one question for each: what has to be finished before this can start?

Work through the job stage by stage and be honest about the hard dependencies versus the soft ones. Hard dependencies are physical or regulatory: you can't stand a frame on a slab that hasn't cured, and in most states you can't proceed past certain stages (slab, frame, waterproofing, final) without a mandatory inspection sign-off. Your frame also has to comply with AS 1684 for tie-down and bracing before the inspector will pass it, so "frame complete" means compliant and inspected, not "the last truss is up". The National Construction Code itself is free to read online at ncc.abcb.gov.au if you need to check what applies, which beats guessing.

Soft dependencies are preferences dressed up as rules. "Painter after tiler" might just be how you've always done it. Soft dependencies are where you find flexibility when the program comes under pressure, so know which is which.

Then find the critical path: the longest chain of hard dependencies from start to finish. That chain sets your minimum build time. A day lost on the critical path is a day lost off the end date, full stop. A day lost anywhere else only matters if it eats enough float to join the critical path. Knowing which tasks sit on that path tells you where a delay actually hurts, and where you can afford to relax.

Construction scheduling buffers: where float actually belongs

Here's the counterintuitive bit of construction scheduling: padding every task makes your program weaker, not stronger. Spread the float thin and every trade quietly absorbs their share (work expands to fill the time available), so when a genuine problem hits, the padding is already gone.

The better approach is to strip individual task estimates back to realistic-but-honest durations, then place dedicated buffers at the points of highest risk:

After wet trades and concrete. Pours, screeds, waterproofing and render are hostage to weather and cure times. A buffer after the slab protects everything downstream. Our guide on how to schedule concrete pours in Australia goes into the weather windows and delivery logistics in detail.
Around inspections and approvals. You don't control the certifier's diary. If your program assumes the inspection happens the day you call, you've scheduled a hope.
Before long-lead installations. Windows, trusses, custom joinery, switchboards. The buffer isn't for the install, it's for the delivery slipping.
One project buffer at the end. A block of contingency you own and defend, rather than dozens of small pads the trades have already spent.

How much buffer in total? We haven't seen a single percentage that survives contact with a real job, and anyone quoting you one number for every project is guessing. The honest method is to buffer by risk: a slab-and-frame stage in a wet season needs more protection than a fit-off stage in October. What matters more than the size of the buffer is that you track it. If you're burning buffer faster than you're completing work, the program is telling you something in week three that you'd otherwise learn in week thirteen.

Weather is a schedule input, not an excuse

Every builder knows rain stops work. Far fewer builders put that knowledge into the program as a number. The Bureau of Meteorology publishes historical climate data for stations across the country, including average rain days per month for your area. That data should shape your program before the job starts, not turn up afterwards in an extension of time claim.

Practically, that means two moves. First, build your working-day assumptions per month, not per week. Five productive days a week might be true for your region in November and fiction in February. If the slab stage lands in your wet season, the program should show that stage taking longer, and the buffer behind it should be fatter. Second, sequence to get weather-exposed work done in weather-favourable windows where the job allows it. Getting to lockup before the wet season is worth compressing earlier stages for, because once you're at lockup, rain costs you far less.

And when weather does hit, record it on the day: what fell, what stopped, which tasks were affected. Most standard Australian building contracts, including the common HIA and Master Builders forms, have extension of time provisions for weather delays, but they generally require notice within a set period. Check your own contract for the exact mechanism. A builder with a daily record claims an EOT in ten minutes. A builder without one is negotiating from memory against a client who remembers every sunny afternoon.

Lead times, trades and the booking problem

Materials and trades are the two supply lines your program runs on, and both punish late planning.

On materials, the discipline is simple: the day the program is drafted, list every long-lead item on the job, get current lead times in writing from suppliers, and put the order dates in the program as tasks. Not the delivery dates. The order dates. "Order windows" is a schedulable task with a deadline, and missing it is a self-inflicted delay that no EOT clause will rescue. Lead times also move with the market, so a quote from last year's job is not data.

On trades, the problem is that good crews are booked ahead, and how far ahead depends on the pipeline in your region. The broader market matters here: when activity lifts, availability tightens and rates move, which is why it's worth reading our breakdown of the 2026 housing market outlook and what HIA's forecast means for your quotes and crew. The scheduling consequence: give trades a booking window early, then confirm with real dates as the program firms up. And when the program moves, tell them immediately. A subbie who hears about a slip a fortnight out can usually reshuffle. A subbie who turns up to a site that isn't ready will requote you for the privilege next time, and the good ones stop answering.

One more honest note on delay cost: your prelims (supervision, site costs, hire) keep running through every lost week whether the contract compensates you or not. Scheduling well is margin protection, not admin.

Run the program weekly or don't bother

A program is only useful if it describes the job as it actually is. That takes a standing routine, and the builders who hold their dates treat it like tool maintenance rather than paperwork.

The weekly loop looks like this, and it takes well under an hour once it's habit:

Mark actuals. What finished this week, what started, what didn't.
Check the critical path. Has it moved? A delay off the path can put a new chain on it.
Check buffer burn. How much contingency has gone versus how much work is done?
Look three weeks ahead. Confirm the trades, chase the deliveries, book the inspections for everything starting in the next 15 working days. Almost every "sudden" delay was visible in this window and nobody looked.
Communicate changes. Trades, suppliers, client. Same day, not at the next site meeting.

The three-week lookahead is the highest-value habit on this list. Slips rarely announce themselves on the day; they announce themselves as an unconfirmed subbie or an unordered fitting three weeks out, when they're still cheap to fix.

What to build it in: whiteboard, spreadsheet or software

The method matters more than the tool, but the tool sets a ceiling on the method. A whiteboard can't hold dependencies. A spreadsheet can, sort of, until one date changes and you're manually walking the change through forty rows, which is exactly the week you won't do it. That's why programs on spreadsheets tend to die by week six: the update cost is too high, so the updates stop.

Purpose-built scheduling handles the propagation for you: link the tasks once, and when the slab slips three days, everything downstream moves with it and you can see what the slip really costs before you decide how to respond. If you're weighing up options, we've written a straight comparison of the best construction project management software for Australian builders, including where each tool fits by crew size. For what it's worth, Built Simple's Builder plan includes Gantt scheduling with dependencies, and the Pro plan adds weather alerts, but the honest advice stands regardless of whose software you pick: choose the tool your least techy crew member will actually update, because a dead program in fancy software is worth the same as a dead program on paper.

Frequently asked questions

How much buffer should I add to a construction program?
There's no verified universal percentage, and be wary of anyone selling one. Buffer by risk instead: more protection after wet trades, inspections and long-lead deliveries, less on internal fit-off, plus one project buffer at the end that you track weekly. If buffer is burning faster than work is completing, act early.

What is the critical path and why does it matter?
It's the longest chain of dependent tasks from start to handover, which makes it your minimum possible build time. Delays on the critical path push the end date directly; delays elsewhere only matter once they consume their float. Knowing the path tells you which fires to fight first.

Who wears the cost of weather delays?
It depends on your contract. Most standard Australian contracts (HIA and Master Builders forms among them) allow extensions of time for weather, usually with strict notice requirements, and whether you can claim delay costs as well as time varies by contract. Keep daily weather records and read your own EOT clause before you need it. If a variation comes out of a delay, price it properly and remember your quote to the client needs GST on top.

How often should I update the program?
Weekly, minimum, with a three-week lookahead every time. A program updated monthly is a history document. The update is also your early warning system: unconfirmed trades and unordered materials show up in the lookahead long before they show up on site.

Is scheduling software worth it for a small crew?
Once you're running more than one job, or one job with more than a handful of trades, yes, because dependency tracking by hand is where spreadsheets quietly fail. Start with something simple enough that it actually gets updated. The flashest Gantt chart loses to a plain program that's true.

The short version

Blowouts aren't weather events. They're planning debts, and they're mostly paid down before the job starts: map the hard dependencies, find the critical path, put buffers where the risk is, schedule against your region's real rain record, order the long-lead items on day one and walk the program every week with a three-week lookahead.

If you want the day-to-day arithmetic off your plate while you're at it, the free Built Simple app has 45 construction calculators built for Australian trades, no signup needed. Grab it on the App Store or Google Play and keep the numbers in your pocket, not on the back of a plasterboard offcut.