Most of the cost and programme risk in a construction project is committed before a contractor is ever appointed. By the time tender documents go out, the sequencing, the access strategy and the plant zones are largely fixed in the drawings — and any buildability problem baked into that information becomes someone’s claim, someone’s delay or someone’s redesign later, at a point where changing it is expensive rather than free.
A buildability review does one specific thing: it asks a design to justify itself against how the building will actually go together, before that design is frozen into a tender package. It is not a value-engineering exercise and it is not a cost check. It is a site-sequence check, carried out by someone who has actually run the trades being reviewed.
What a buildability review actually looks at
Access and sequence. Can the packages implied by the design actually be installed in the order the programme assumes? A services run that is only accessible after a partition goes in, but is specified to be tested and commissioned before it, is a buildability problem hiding in a programme logic problem.
Plant space and tolerance. Drawings show equipment as clean boxes with clean clearances. Real plant needs maintenance access, filter-pull space, crane or hoist routes for replacement, and tolerance for the fact that risers are rarely built to the millimetre. A coordinated model that works on paper can still be unbuildable at 1:1 scale.
Interfaces between packages. Most defects and most disputes sit at the boundary between two trades, not inside either one of them. Who fire-stops the hole the ductwork contractor cuts? Who is responsible for the builder’s work opening that the structural engineer assumed the M&E designer would specify? A buildability review exists to find these questions and answer them in the documents, rather than leave them to be negotiated on site.
Long-lead items. Some equipment has a lead time long enough to dictate the critical path on its own. A buildability review checks that anything with a meaningful lead time is identified, procured on a realistic timeline, and not quietly assumed to be “in stock” by a programme built before anyone asked the manufacturer.
Why tender stage, specifically
Earlier than tender, the design is often still moving, and a buildability comment can get lost in the noise of other changes. Later than tender — once a contractor is on board and pricing against fixed documents — a buildability gap becomes a variation, a claim, or a fight about who should have spotted it. Tender stage is the last point where a problem can be fixed in the drawings rather than negotiated in the contract.
It is also the point where the documents are supposed to be complete enough to price accurately. A tender package that has not been buildability-checked tends to attract either inflated contingency pricing from contractors who can see the gaps, or thin pricing from contractors who haven’t — both of which cause problems for the client later, just at different points in the programme.
The questions worth asking, in practice
Before a design goes out to tender, it is worth someone with delivery-side experience asking, in plain terms: how does this actually get built, in what order, by whom, with what access, and what happens at the point where one package’s work becomes another’s problem? Where the honest answer is “we’re not sure,” that is exactly where the review has earned its fee — because the alternative is finding out on site, on the client’s clock.