Technical review

Hamid runs the first full clash check on the team's combined model on the Wednesday evening of week five, and brings the result to the big room the next morning: 240 clashes. The number silences the table. Then Hamid shows them what the clashes are. Ninety-one are the same sprinkler main passing through the same timber beam on every one of eight floors, because the sprinkler model was drawn before the beams were sized. Forty are ducts touching ceilings that are drawn as solid boxes in the architectural model. Thirty are pipes meeting pipes inside the walls where they are meant to meet. The rest, about seventy, are real. 'Two hundred and forty is not the number,' Hamid says. 'Seventy is the number, and I can tell you which ten matter.'

What technical review is

Technical review is the checking of a design by people who did not produce it, against criteria they can state. On a building project it takes several forms. Coordination review checks that the disciplines' models and drawings agree with each other: that ducts do not pass through beams, that stairs reach the floors they serve, that the electrical room is the size the equipment needs. Peer review checks a discipline's work against its own standards: a structural engineer who did not design the structure checks that it is sound and complies with the code. Code review checks the design against the building code, the fire code and the accessibility standards. Constructability review checks that the design can be built on this site in a reasonable sequence. Commissioning review checks that the design meets the owners' project requirements and can be tested to show it does.

Solberg asks the teams to schedule all of these in weeks five to nine, with a named reviewer for each, and to treat every comment as an issue to be closed, not a criticism to be answered. Each issue is recorded with its source, its description, the discipline responsible, a priority and a status. An issue is closed only when the change has been made and the reviewer has accepted it. The team uses the same issue format for clashes and for review comments, so that everything that must be fixed is in one list.

Clash detection

Clash detection is the automatic search for places where elements of the combined model occupy the same space or come closer than they should. The team combines its discipline models each week into one federated model, which keeps each discipline's model separate but displays them together, and runs a set of tests between pairs of disciplines: structure against mechanical, structure against plumbing, mechanical against electrical, and so on. Each test can look for hard clashes, where two solid elements overlap; clearance clashes, where an element intrudes into a space that must be kept clear, such as the access space in front of an electrical panel or around a valve; and, with more effort, workflow clashes, where elements would be installed in an order that cannot work, such as a duct that must be in place before the beam it passes over.

Raw clash counts mislead, as the first check showed, because one problem repeated on eight floors appears as eight clashes, and because some clashes are not problems at all. Hamid filters them: he groups repeated clashes into one issue, removes the clashes between elements that are meant to meet, and sets tolerances so that a pipe touching its own insulation does not count. Then he ranks the remaining issues by the cost of fixing them later: a duct through a beam, which requires an engineer's approval and a factory-cut opening, is worth far more attention than a cable tray touching a ceiling.

The team agrees a priority order for resolving clashes, following a common rule: the element that is hardest to move gives way least. Structure moves last; gravity drains, which must slope, come next; large ducts next; then sprinkler mains, smaller pipes, cable trays and conduit, which can be routed around almost anything. The rule does not mean that structure never moves, but that a change to structure needs a stronger reason.

Burning down the issues

Each week Hamid records how many new clashes the check found, after filtering, and how many the team closed. The script below shows the six weeks from the first full check to the final review, and estimates when the open issues will be cleared at the current rate.

# Clash and issue burndown from the weekly federated model reviews
weeks = [1, 2, 3, 4, 5, 6]
found = [240, 96, 70, 44, 30, 18]       # new clashes each week (after filtering duplicates)
closed = [60, 130, 110, 80, 62, 40]     # clashes resolved each week
open_ = 0
for w, f, c in zip(weeks, found, closed):
    open_ = max(0, open_ + f - c)
    print(f"week {w}: found {f:3d}, closed {c:3d}, open {open_:3d}")
rate = sum(closed[-3:]) / 3 - sum(found[-3:]) / 3
print(f"net closing rate over the last three weeks {rate:.0f} per week; weeks to clear {open_ / rate:.1f}" if rate > 0 else "not converging")
severity = {"hard: structure vs duct": 0.25, "hard: pipe vs pipe": 0.15, "clearance: access to valves": 0.35, "workflow: sequence": 0.25}
print("open by type: " + ", ".join(f"{k} {round(open_ * v)}" for k, v in severity.items()))

week 1: found 240, closed  60, open 180
week 2: found  96, closed 130, open 146
week 3: found  70, closed 110, open 106
week 4: found  44, closed  80, open  70
week 5: found  30, closed  62, open  38
week 6: found  18, closed  40, open  16
net closing rate over the last three weeks 30 per week; weeks to clear 0.5
open by type: hard: structure vs duct 4, hard: pipe vs pipe 2, clearance: access to valves 6, workflow: sequence 4

The pattern is typical. New clashes fall quickly once the disciplines start working to the same grid, levels and zones, and once the rule about running main ducts between beam lines takes effect. The number closed each week falls too, because the easy clashes are closed first and the last ones are hard. By the final review the team expects about seven open issues, mostly clearance and sequence questions that need the builder's input. Solberg says that is an honest result: a design development model with no open clashes at all usually means the checks were not strict enough.

One clash taught the team more than the others. The sprinkler main that passed through the same beam on every floor could be fixed in two ways: by moving the main, which would put it in the homes' living rooms, or by giving the beam a factory-cut opening on every floor, which Tomasz could approve because it was near the beam's support where the shear is high but the bending moment low. In the concrete tower, the sleeve is cast into the slab's edge beam, at little extra cost if it is in the model before the tendons are laid out. The team adopts the opening, and adds a rule: every penetration of structure is modeled, approved by Tomasz and given an identifier that will appear on the shop drawings.

Peer and code review

Szymańska conducts a peer review of the structure in week seven. She checks the load paths from the roof to the foundations, the lateral system, the transfer girder, the connections between the tower and the cores, and the tower's movement under wind. She raises eleven issues, most of them small. The largest is that the tower's floors will shorten slightly over time as the concrete columns creep and shrink, while the concrete cores will not, so the floors near the cores will end up slightly higher than those at the facade. The difference over eight floors is small but enough to crack finishes and tilt doors, and she asks Tomasz to calculate it and to detail the connections at the cores to allow for it.

Danielle Roy and Nadia Kostyshyn review the fire protection and code compliance together in week eight. Their issues are about the separations between users, the protection of the stairs, the travel distances in the clinic, and the encapsulation of the timber where it meets the concrete cores. Kostyshyn finds one serious issue: the clinic's group room, which the team had planned for evening community meetings of up to sixty people, would be an assembly occupancy within the clinic, which changes its exits and its separation. The team keeps the group room at the east end but turns it to open directly onto the lobby of the east stair, giving it a second exit, and encloses it with a separation from the rest of the clinic, with its own door from the elevator lobby for evening meetings.

Daniel Achterberg, the accessibility consultant, reviews the routes, the entrances and the accessible homes, and walks the team through the clinic plan as a wheelchair user would. He asks for the clinic's reception counter to have a lower section on the side a wheelchair user approaches from, and for the transit hall's real-time screens to be repeated with audible announcements and at a height readable from a seat. Both are added to the issues list.

Constructability

Marcus Oyelaran's constructability review in week eight looks at the building as a sequence of work on a tight site. Where will the crane stand, and can it reach every corner of the tower? How will materials arrive on a lane that also serves the hub's deliveries? Where will they be stored, when the site has almost no free ground? How will the podium's concrete be poured without closing the avenue? He proposes that the crane stand inside the tower's footprint at the west core, climbing with the building, and that the timber panels or the concrete reinforcement arrive just in time, lifted straight from the truck to the floor. He asks for the facade panels to be designed so that they can be installed from inside the floor without scaffolding, and for the podium roof's waterproofing to be completed before the tower rises above it, so that the clinic below can be fitted out while the tower is still being built.

Two of Oyelaran's comments change the design. The forecourt at the corner, which Hamid had designed with planted beds and seating, must also serve as the builder's site entrance during construction, so its paving and its stormwater storage below must be strong enough for trucks and finished last. And the first-floor slab over the loading bay, where the transfer girder sits, must be poured early, because everything above it depends on it. Both go into the issues list and the decision log.

Exercise 10: technical review

• Run a weekly clash check on your federated model, filter and group the results, and rank the real issues by the cost of fixing them later.
• Track found, closed and open issues each week, and estimate when they will be cleared.
• Schedule peer, code, accessibility, constructability and commissioning reviews with named reviewers, and record every comment as an issue.
• Close each issue only when the change is made and the reviewer accepts it.

Self-check

• Do you know which ten open issues matter most?
• Has every penetration of the structure been modeled and approved?
• Has the builder told you where the crane will stand and how materials will arrive?