Most office fitout programmes fail in the reading, not the running. A bar chart is easy to produce. Reading it honestly, seeing where the slack really sits, which steps carry the whole chain, and which steps will quietly redirect everything below them, is what separates a programme that holds from one that drifts. The question a tenant should ask about a programme is not how long it runs for, but which moments inside it cannot be compressed and which can absorb a bad week.
This article is about how to read a fitout programme for dependency risk. It is not a stage-by-stage walk from site measure through handover. It is a framework for looking at any programme and working out how fragile it is, so that the date on the final page means something. If site measure to handover is the span you are trying to hold, the honest question is not how long each stage takes on its own, but which stages are load-bearing and what happens when one of them slips.
What a critical path actually looks like inside a fitout
A critical path is not the longest sequence of tasks on a bar chart. It is the chain of dependencies where a one-day slip on any single link becomes a one-day slip on handover. Inside a fitout, that chain is shorter than the programme suggests and narrower than tenants assume. It tends to run through one design decision, one procurement order, one install window, and one commissioning slot, and the rest of the activity on the bar chart is hanging off that thread.
The practical consequence is that most of the tasks on a fitout programme are not on the critical path at all. They can be moved, resequenced, or delayed a few days without the handover date changing. The critical tasks cannot. Telling which is which is the first job a tenant has when a builder hands them a programme, because the parts that look busy are rarely the parts that are load-bearing, and the parts that look quiet sometimes are. Reading the programme backwards from the handover date is one of the cleanest ways to find the chain.
A fast test for whether a step is critical is to ask what happens to handover if it slips by a day. If handover also slips, the step is critical. If the programme absorbs the slip, the step is not. Running that question down a bar chart line by line exposes how much of the whole programme is held by three or four specific moments rather than fifty distributed activities.
Where the float lives, and where it does not
Float is the amount of time a step can move without pushing the handover date. It is the programme’s shock absorber. Inside a fitout, float is not evenly distributed. It concentrates in a small number of stages and disappears in the stages most sensitive to slippage, which is the opposite of what tenants usually assume. The stages with float tend to be the quiet ones. The stages without float are often the ones that look flexible on paper.
Concept and early design carry some float, because modest slippage at the front is recoverable if the downstream team has room to compress. Procurement of long-lead items carries almost none, because the clock is running on external suppliers who are not inside the programme at all. Construction carries variable float depending on how trades are interleaved, but by the time services rough-in is complete, float drops toward zero. Commissioning and handover carry no float. Slippage there is absorbed by the tenant, not the programme.
When a builder says there is float in the programme, ask where. The answer should name specific stages, not a global total at the bottom of the bar chart. Float described as a single number has usually been spent quietly somewhere upstream before the tenant looked.
Gating stages versus parallel stages
Every fitout programme contains two kinds of stages. Gating stages have to finish before the next stage can start. Parallel stages run alongside other work without blocking it. The discipline of reading a programme is to tell which is which, because the failure mode of each is completely different, even though the two kinds of stage are drawn with the same shape of bar.
Gating stages are where the programme either moves or does not. Landlord approval is the clearest example: no approval, no site access, no early works. Site survey is another: no measured shell, no finalised construction documentation. Early services set-out is another: no set-out, no coordinated ceiling grid. When a gating stage slips, everything below it slips with it unless there is explicit float downstream to absorb the blow, which there rarely is.
Parallel stages are where the programme earns its efficiency. Joinery fabrication runs alongside partition framing. Electrical rough-in runs alongside mechanical rough-in. Manifestation and signage can be designed while the walls go up. Treating parallel stages as if they were gating inflates the programme and creates the illusion of buffer where none exists. Treating gating stages as parallel is how a programme quietly collapses halfway through.
Single-point-of-failure steps
Inside every fitout programme there are a small number of steps that carry the whole chain. These are the ones where one slip, one missed decision, or one late document reshapes the work of every trade below them. There are rarely more than a dozen across the life of the programme, and they are rarely marked as critical on a bar chart because their weight is analytical rather than visual.
The common ones are easy to name once you look. The approved construction drawing set: if it issues late or changes after trades start pricing, every following order is built on moving ground. The final ceiling set-out: if it shifts after services are roughed in, every service already installed has to be adjusted, and most of that cost lands on the programme rather than the variation. The long-lead procurement cut-off: if a joinery, glazing, or specialty flooring order slips past its window, the sequence that follows has to fit inside time it does not have.
Each of these is a pinch point, not a duration. The entry on the bar chart may take a day. The consequence of getting it wrong runs for weeks. A builder who understands their own programme can name the three or four pinch points on it without looking at the schedule. A builder who cannot is worth asking why.
The re-sequencing trap
When a stage slips, the natural instinct is to reorder the programme so the downstream work keeps moving. Sometimes that works. Often it does not, and the resequenced version turns out to be quietly more expensive and more fragile than the version it replaced.
Re-sequencing looks like problem-solving but it moves the risk into a shape nobody has planned for. A services rough-in pulled forward to close a gap will collide with partitions framed in the old order. A ceiling set-out pushed back to accommodate late design changes will compress commissioning into a window that was never sized for it. A finishes package brought forward because joinery is late will expose finished surfaces to trade traffic they were not meant to see. Each of those moves has its own downstream consequences, and the original sequence existed for reasons that were not written on the bar chart. The correct order a fitout is built in exists because the dependencies between trades rarely change even when the timetable does.
The discipline is to treat re-sequencing as an engineering decision, not a scheduling decision. If a stage has to move, the new sequence has to be checked against every dependency it will now touch, and the cost of that reshuffle has to be weighed against the time it saves. Many programmes that slip recover better by holding the original sequence and absorbing the slip at handover than by reshaping the middle under pressure.
The missed dependency that reshapes downstream work
The single most common cause of a fitout programme slipping is a dependency that was not recognised as a dependency until construction was already under way. It is usually a detail that looked like a parallel decision on paper and turned out to block several other activities once it became physical.
The patterns repeat across projects. A partition layout that was not reconciled with the ceiling grid, so framed walls have to be shifted to land on a tile edge. A power and data layout that was signed off before workstation positions were locked, so cabling has to be rerun after the furniture supplier confirms dimensions. A landlord requirement for a new hydrant or sprinkler tapping that was not identified until a reviewer asked the question, so a trade that was never in the programme has to be inserted into it. A fire separation detail that was assumed to be standard and turned out to need a specific rated system, so framing already in place has to be demolished and rebuilt. Each of these is the small early decision that quietly sabotages everything downstream.
None of these look like dependency risks when the programme is signed. All of them behave like dependency risks once construction starts. Reading a programme for missed dependencies means reading the drawings and the specification together with the bar chart, and asking at every interface between systems whose decision the next decision depends on. The more interfaces a programme has, and the more parties controlling those interfaces, the more places this kind of silent dependency lives. Where design, procurement and construction sit inside the same team, as in a complete office fitout delivery, there are still interfaces but they are easier to own, which tends to reduce the number of dependencies that only become visible under pressure.
Stress-testing a programme before you sign off on it
A programme that has been stress-tested before the first day of construction survives slippage better than a programme that only gets stress-tested after the first slip. The exercise is short. A tenant can insist on it as a condition of accepting the programme, and it tends to be one of the most valuable hours in the pre-construction window.
Five questions do the work. Which three tasks, if they slip by a day, cause handover to slip by a day? If the builder cannot name them, the critical path has not been properly identified. Where is the float, and how much has already been committed? If the float is described as a global total, it has probably been spent somewhere upstream. Which procurement orders have to land before construction starts, and what happens if one arrives a week late? If the answer is vague, procurement is fragile. Which landlord or certifier interactions are gating the programme, and who owns them? If nobody owns them, the gate has no real schedule. Which trades depend on the previous trade’s final set-out, and what happens when that set-out is wrong? If the answer is “we will adjust in the field”, the programme is absorbing rework as planned work.
Running those five questions across a bar chart turns it from a picture into a plan, and a plan is the only thing that can govern a build. The individual stage durations matter less than whether the dependencies between them are real, named, owned, and sized. A programme that passes this test at the start is the one that tends to hold from site measure through to handover, because the reasons most programmes slip are the same few failure points showing up at the same few stages.
If you are trying to read a fitout programme for dependency risk before you commit to a handover date, or reset one that has already started to drift, we can help you walk the critical path in detail and work out where the programme is carrying real weight and where it has room to move.
📞 Call us on 1300 60 93 93