Ask ten contractors why a job ran late and you will hear ten different stories. Look at the programmes underneath them and you keep finding the same five causes. None of them are exotic. All of them are foreseeable, which means a programme can be built to absorb them instead of being surprised by them.
1. Rain treated as an act of God rather than a season
Uganda has two wet seasons, and they arrive every year. A programme that shows excavation and external works running straight through March to May without a single lost day is not optimistic, it is wrong.
The fix is not padding every task. It is knowing which activities are weather-exposed — earthworks, foundations, external blockwork, roofing, painting, external finishes — and either scheduling them outside the wet window or carrying explicit weather float against those tasks alone. Internal works are your wet-season friend: if the structure is closed, finishing crews keep earning while the yard is a lake.
What to write into the programme
- Named weather-exposed activities, flagged as such
- A stated number of rain days per month, agreed with the client up front
- A rule for what happens when they are used up
The last point matters most. Disputes rarely start with the rain. They start when nobody agreed in advance who carries the delay.
2. Approvals scheduled as if they were instant
Statutory approvals, utility connections and client sign-offs all take calendar time that is largely outside your control. A programme that assumes a drawing goes out on Monday and comes back approved on Wednesday has invented time it does not have.
Treat every approval as a task with a duration, an owner and a predecessor. If the client needs two weeks to review finishes schedules, that is a two-week task on the critical path, not a footnote. Making it visible is what forces the conversation early, when it is still cheap.
3. Long-lead items ordered at the last responsible moment
Imported items — lifts, switchgear, specialist cladding, some steel sections — carry lead times measured in months, plus clearing time at the border. Ordering them when the programme first needs them on site guarantees a wait.
Work backwards instead. Take the installation date, add the lead time, add clearing and inland transport, add a contingency, and you have your order-by date. That date belongs in the programme as a milestone with a name against it. On a well-run job the procurement schedule and the construction programme are the same document read two different ways.
4. Cash flow that starves the critical path
A programme assumes resources will be there. Cash decides whether they are. When a valuation is late or a payment is short, the first casualty is usually material deliveries, and the second is subcontractor attendance. Both land squarely on the critical path.
Build the cash curve alongside the programme, not after it. If the two disagree — the programme wants a slab in week 12 and the cash to buy the steel arrives in week 14 — you have found a problem while it is still a spreadsheet rather than an idle crew.
5. Sequencing that ignores what the trades actually need
The most common self-inflicted delay is sending a trade to a place that is not ready for them. Tiling before the screed has cured. Ceilings before the services above them are signed off. Painting before the windows are in and the dust has stopped.
Each of these forces rework or standing time, and neither shows on the programme until the slip is already real. The defence is a short-interval look-ahead — three weeks, updated weekly — that asks one question of every activity: is the area actually free, and are the preceding trades signed off?
Where float should live
Float spread thinly across every task disappears without anyone noticing. Float held deliberately, in named buffers before high-risk milestones, is visible and defensible.
Put buffers where the risk concentrates:
- Before the first major concrete pour, where setting out and formwork problems surface
- Before the building is made watertight, because everything internal waits on it
- Before handover, where snagging always takes longer than anyone plans
When a buffer is consumed, that is information: it tells you the risk it was protecting has materialised, and you can act while there is still time. Float hidden inside task durations tells you nothing until it is gone.
The weekly discipline that holds it together
A programme is not a document you produce at tender and print at handover. It is a weekly instrument. The teams that finish on time tend to do the same three things every week: update actual progress honestly, re-forecast the next three weeks, and name the single activity that most threatens the completion date.
That last one is the whole game. There is always one. Knowing which it is this week, and putting your attention there, is most of what programme management amounts to.
