06 — Insights

Building a programme that survives contact with reality

Most self-build programmes are an optimistic best-case sequence with no float built in. Here's how major-programme practice thinks about the same problem, and what to borrow from it.

08 Oct 20267 min read

Ask most self-builders for their programme and you'll get a single line per trade, laid end to end, adding up to a plausible-looking total. Ask what happens if the groundworker overruns by a week, or the roof trusses arrive late, and the honest answer is usually that nobody's worked it out — the programme was built to produce a number, not to survive contact with an actual build.

Large infrastructure programmes can't afford that. When a scheme runs for years and costs hundreds of millions, an optimistic best-case sequence isn't just embarrassing when it slips, it's financially ruinous. So the discipline that's grown up around programme management is really just a set of honest answers to "what happens if this bit is late" — and it scales down to a single house rather better than people expect.

Find the critical path, not just the task list

A list of trades in order is not a programme. A programme identifies which tasks actually determine the finish date — the critical path — and which have slack, or float, sitting around them. Plastering can usually happen a few days later than planned without moving the end date, because other things are happening in parallel. First fix electrics often can't, because everything after it depends on it being done.

The practical value of knowing this is knowing where to spend your attention. A week's delay on a critical-path task costs the project a week. The same delay on a task with two weeks of float costs nothing at all, provided it doesn't run over its float too. Most self-builders manage every trade with equal anxiety, when only a handful of them are actually capable of moving the finish date.

Float is not the same as contingency

It's worth keeping these two separate, because they get conflated constantly. Float is slack already built into the sequence of a specific task — the two weeks plastering could slip without consequence. Contingency is a separate reserve of time (and money) held against the programme as a whole, for the things you haven't specifically predicted. A programme with generous float on individual tasks can still get wiped out by a single unpredicted event if there's no contingency held in reserve behind it.

Lead times, checked against the actual supplier, not a rule of thumb

"Windows take about eight weeks" is the kind of thing that gets typed into a programme and never checked again. Real lead times move with demand, with the specific product, and with the time of year — a bespoke timber frame ordered in spring for autumn delivery is a different proposition to the same order placed in September for a Christmas delivery. Before a lead time goes into the programme, it's worth getting it confirmed in writing from the actual supplier you intend to use, not estimated from what a similar project needed eighteen months ago.

The items worth chasing hardest are the ones with both a long lead time and a critical-path position: trusses, structural steel, a bespoke staircase, specialist glazing. A three-week slip on a long-lead item that's also on the critical path is a three-week slip on completion, in full.

Weather and inspections are schedule items, not excuses

Two categories of delay are entirely predictable in aggregate even though they're unpredictable in the specific week: weather-dependent activities (groundworks, roofing, external render) and statutory inspections (building control sign-offs, warranty provider inspections) that have to happen at fixed points and can't simply be skipped if the inspector is booked out. Both deserve an explicit allowance in the programme rather than being treated as things that go wrong. A programme with zero weather allowance for groundworks starting in November isn't optimistic, it's just wrong.

What actually causes the delays people don't plan for

  • A trade that's also committed to another job finishing late, and yours is now behind theirs in the queue
  • A design detail resolved on site because it was never fully drawn, costing days while everyone waits for an answer
  • A delivery that arrives complete except for one missing component, holding up an entire fix
  • An inspection failing on a detail that then has to be opened up and redone before it can be re-inspected
  • A knock-on decision — a kitchen layout, a staircase position — that was left open too long and now blocks two other trades

What a programme worth trusting actually contains

  • Tasks broken down enough to show real dependencies, not one line per trade
  • The critical path identified explicitly, not left implicit
  • Float shown separately from contingency, both stated as numbers rather than a vague sense of buffer
  • Lead times confirmed with named suppliers, dated, and revisited as the programme moves
  • An explicit weather allowance on weather-dependent activities, sized to the season they fall in
  • Inspection and sign-off points built in as fixed dates to work around, not squeezed in afterwards
  • A realistic view of what happens to the whole programme if a critical-path item slips by two weeks