gantt
A build schedule template is usually downloaded on the day a programme is needed and abandoned by the third revision. Not because the template was badly drawn, but because it was a picture. The bars were positioned by hand, the trades were placed in the order somebody remembered, and nothing in the file knew that plastering cannot start until the first fix is signed off. So when the steel arrives a week late, every bar after it has to be dragged individually, and the version that goes to the site gets out of step with the version the office is working from.
The useful part of a build schedule is not the bars. It is the sequence logic underneath them: which activity cannot start until another finishes, how much waiting time the specification demands between two of them, and which inspections have to be passed before work can continue. A template that carries that logic absorbs a late delivery in one edit. A template that does not turns every change into an afternoon of redrawing.
This article sets out what a build schedule template has to contain, how to write trade sequence as dependencies rather than positions, where lag and hold points go, and how the office programme and the site lookahead stay connected.
Template libraries offer a great many layouts, and the differences between them matter less than whether each of the following is present. Six items make the difference between a programme and a drawing.
A work breakdown that matches how the site is handed over. Usually by zone or level, then by trade within the zone. A schedule listing every trade once across the whole building cannot express the reality that the ground floor is ready for second fix while the second floor is still in first fix.
Durations with a stated basis. Ten days because the subcontractor quoted ten days, or ten days because a similar zone took ten days, is a duration. Ten days because the bar looked about right is a wish. Recording the basis in a note takes seconds and is the only thing that makes a later argument resolvable.
Dependencies, not positions. Each activity records what it waits for. This is the item most templates lack and the one that makes the rest work.
Lag where the specification requires waiting. Curing, drying, settling and testing periods are not zero length gaps between bars. They are constraints, and they belong in the file.
Hold points. Inspections, sign offs, statutory approvals and client decisions are activities with owners and durations, not notes in a margin. Work stops at them whether or not the schedule says so.
Procurement and lead times. The long lead items need their own bars, ordered back from the date they are needed on site. A schedule that only shows installation dates will discover the problem at the point where it cannot be recovered.
Templates that arrive with worked example content are more useful than empty grids, but only if the example is replaced rather than edited around. Leftover activities from a template's sample project are a common source of confusion on site, because they carry durations and dependencies that belong to a different building. Strip the example back to the trade sequence and rebuild the zones from the actual drawings before the first issue.
Two more items are worth adding once the six above are in place: a baseline copy taken at the moment the programme is agreed, and a column for actual start and finish dates against each activity. Without a baseline, nobody can say whether the schedule has slipped or been rewritten.
The sequence of trades on a build is mostly determined by physics and by access. The value of putting it in the file is that the file then enforces it.
A typical fit out sequence for a single zone runs something like this: strip out and make safe, structural work, then services roughed in, then close up and board, then finishes, then second fix of services, then commissioning and snagging. The exact order varies by project type and by contract, and it is not the point. The point is that each of those has a predecessor, and once each activity records its predecessor, the schedule can answer a question no drawn programme can: what moves if this one slips.
Four relationship types cover almost everything on a build.
| Relationship | Meaning | Typical use on a build |
|---|---|---|
| Finish to start | B cannot start until A finishes | Boarding after first fix inspection |
| Start to start, with lag | B starts a set time after A starts | Second trade following the first through a long zone |
| Finish to finish | B cannot finish until A finishes | Commissioning finishing with the last equipment install |
| Finish to start, with lag | B starts a set time after A finishes | Anything requiring a curing or drying period |
Start to start with lag is the one that most improves a build programme. Trades following each other through a large zone do not wait for the previous trade to finish the whole area. The follower starts a few days behind and moves through at a similar pace. Modelling that as finish to start makes the programme far longer than reality; modelling it as start to start with a lag is both shorter and true.
The practical test of whether the logic is real: change one early activity's duration and look at what moves. If nothing moves, the file is a picture of a schedule. If the whole downstream sequence shifts and the end date changes, the logic is doing its job. That single test is the reason to build the programme in a tool with a dependency aware Gantt view rather than in a drawing or a spreadsheet grid, where the bars are cells and no relationship exists between them.
Two categories of delay are entirely predictable and are missing from most templates.
Lag for the waiting the specification demands. Concrete has to reach strength before loading. Screeds and plaster have to dry before floor finishes go down. Paint systems have recoat intervals. Tests and commissioning have settling and observation periods. The exact figures come from the specification, the product data sheet and the engineer, and they differ by mix, thickness, ambient conditions and product. What matters for the template is that each of these periods is recorded as a lag on the relationship, taken from the document that specifies it, rather than absorbed into somebody's duration estimate. When the lag sits in the file, a late pour moves the floor finishes automatically. When it lives in a site manager's head, it moves them by surprise.
Hold points where work cannot proceed without someone else. Building control and statutory inspections, client or design team sign offs on samples and mock ups, utility connections and commissioning witnesses. Each of these is an activity that occupies real time, is owned by someone outside the trade, and stops the sequence if it is late. Putting them on the programme with an owner and a duration makes two things visible: how much of the critical path is actually waiting for a decision, and who has to be chased and when.
Procurement belongs in the same discussion, because it stops work in the same way. Long lead items need a bar for the order, a bar for manufacture and a bar for delivery, sequenced backwards from the date the item is needed in the zone. Written that way, the schedule shows the last responsible date to place each order, which is the single most useful output procurement can get from a programme.
A third category is not predictable but is plannable: weather and access restrictions. Rather than padding every external activity, a common approach is to mark which activities are weather dependent and hold a stated allowance in one place, so that using it is a visible decision rather than a quiet erosion of everybody's durations.
Two audiences read a build schedule and they need different things from it.
The full programme covers the whole project, is updated when something structural changes, and answers questions about the end date, the critical path and the consequences of a variation. It is the document the contract refers to.
The lookahead covers the next two to four weeks, is updated weekly, and answers what each trade is doing on which day, in which zone, with what delivered. It is the document that runs the site.
Teams get into trouble when these two are kept in separate files by separate people. The lookahead is then produced by retyping part of the programme, and by week three they disagree. The version on the site wall becomes the real one, the programme becomes the one shown to the client, and the gap between them is invisible until a claim depends on it.
Keeping both views over one set of activities removes the retyping. The Gantt view answers the office questions. A calendar or timetable view of the same activities, filtered to the coming weeks, is the lookahead. A kanban view of the same work, with columns for the current stage, is what the trades can update. Progress recorded once appears in all three. Where boards of different types share one workspace, the update is a single act rather than three reconciliations.
The discipline that matters is recording actual dates rather than dragging bars to where they now look right. Dragging destroys the comparison with the baseline, and with it any ability to explain what happened.
Take the schedule in use now and add predecessors to every activity, then put the curing, drying and recoat periods in as lag taken from the specification rather than folded into durations. Add the inspections and sign offs as activities with owners. Then change one early duration and check that the end date moves; if it does not, the logic is not there yet.
Once the logic holds, generate the site lookahead from the same activities instead of retyping it. Pinateca keeps Gantt, calendar, timetable and kanban views over one set of work and is free for up to five people and ten boards, which is enough for a small builder to run a live programme without a second file.
It can be drawn in one, and that is the limitation. A spreadsheet Gantt is coloured cells, so no activity knows what it waits for, and a single late delivery has to be corrected by hand across every bar after it. For a short project with a stable sequence that is tolerable. For anything with trade overlap, curing periods and inspections, the corrections become the job.
Detailed enough that each activity has one responsible trade, one zone and a duration somebody can defend, and no more. Activities shorter than about a day clutter the programme without improving decisions, and the detail below that level belongs in the weekly lookahead where it can change without touching the contract programme.
As lag on the relationship between the two activities, with the figure taken from the specification or the product data sheet rather than estimated. Held that way, a late pour automatically moves everything that depended on it. Folded into a trade's duration, the same delay looks like the trade being slow and the real constraint disappears from view.
Yes, as activities with an owner and a duration. They consume real time and they stop the sequence when they are late, which makes them part of the critical path whether or not they are drawn. Showing them also makes it clear how much of the programme is waiting on decisions rather than on work, which is often more than anyone expects.
Record actual dates weekly and reissue the lookahead from the same file. The full programme only needs reissuing when something structural changes, such as a variation or a confirmed slip to the end date. What matters more than frequency is that actual dates are recorded rather than bars being dragged, since dragging removes any comparison with the agreed baseline.