There’s a pattern that plays out on technology-intensive building projects with enough consistency that it has a name in the industry: the technology afterthought.
This happens when the design progresses through schematic design and design development with placeholder allowances for AV, IT, security, and specialty systems. Technology scope gets deferred to a later phase, and somewhere between construction documents and bid – or worse, during construction itself – the real scope comes into focus, and the project pays for the delay.
What would have taken a conversation to resolve at SD becomes a coordination issue at DD, a specification rewrite at CDs, a change order during construction, and a costly retrofit after occupancy. But while the pattern is predictable, so is the way to avoid it.
Technology planning for architects is a core design discipline that affects space planning, structural coordination, MEP engineering, cost estimating, and the owner’s ability to actually use the building the way they intended. The reason it gets deferred is rarely intentional – it’s usually that the expertise isn’t on the team yet.
But deferring technology planning doesn’t defer its consequences. Every decision made in SD without accounting for technology infrastructure creates a constraint that becomes progressively more expensive to resolve. And by the time you bring in a technology consultant, the design has made commitments that the systems can’t support without change orders.
The solution is to involve a technology consultant like TMC at the start of schematic design, before those constraints are locked in. The value this engagement delivers in accuracy, coordination, and avoided cost consistently exceeds its fee.
Integrated building technology – the IT networks, AV systems, security infrastructure, distributed antenna systems, access control, and building automation that make a modern facility function – is not self-contained. It has physical, electrical, and spatial requirements that run through every discipline on the project.
Here are a few examples of how technology infrastructure intersects with the rest of the design:
Technology equipment rooms, telecommunications closets, head-end spaces, and server rooms require dedicated square footage with specific dimensional constraints, adjacency requirements, and access provisions. Space that isn’t allocated in schematic design gets carved out of something else later – at a cost.
IT and AV equipment generate heat and draw power in ways that need to be incorporated into mechanical and electrical engineering. Systems designed without accurate technology load data will either be under-engineered (requiring upgrades) or over-engineered (wasting budget).
Low-voltage technology systems require conduit infrastructure, cable trays, and pathways that need to be coordinated with structural framing, mechanical systems, and other above-ceiling work. Routing that isn’t planned in design gets improvised in the field – which is how RFIs and change orders are born.
Speaker placements, display mounting locations, security camera positions, and access control hardware all affect walls, ceilings, and millwork. Technology decisions made after architectural details are finalized require rework.
The technology systems that fall under Divisions 25, 27, and 28 represent a specialized body of knowledge that most architecture firms don’t carry internally. This isn’t a gap that reflects poorly on the firm; it’s simply a reflection of how these disciplines work.
The challenge is that AV, IT, and security systems in architecture don’t behave like other building systems because they’re more interconnected, more dependent on current market conditions and vendor ecosystems, and more sensitive to owner operational requirements than mechanical or electrical systems of comparable cost. Designing them well requires not just technical knowledge, but familiarity with how owners actually use them.
When these disciplines are subcontracted late in the design process – brought in at CDs to write specs for systems that haven’t been coordinated into the design – the result is typically one of two things:
Neither serves the project, the owner, or the architect.
Engaging a technology consultant for architects, such as TMC, during SD and keeping them engaged through construction administration can help you solve these problems. The earlier the engagement, the more the consultant’s expertise shapes the design rather than reacting to it.
Construction document technology specifications are where design intent becomes a contractual obligation. The quality of technology specs in CDs determines everything from whether contractors can price scope accurately to whether the project team will spend the construction phase answering RFIs or managing the work.
Strong construction document technology specs should:
Specs produced by a technology consultant who has been on the project since SD reflect the actual design – the real systems, the real coordination that has been completed, and the real owner requirements – while specs produced by a consultant brought in at CDs reflect whatever can be assembled from the available information under time pressure.
The principle that early decisions are cheaper than late ones applies across all construction disciplines – but the compounding effect is particularly pronounced for building technology design. Here’s what deferring technology planning typically looks like at each phase:
Technology decisions are still conceptual at SD, so factors like equipment room locations, pathway strategies, and system types can be established through a few targeted conversations.
During SD, a technology consultant like TMC can contribute:
The cost of getting something wrong at this stage is a revised narrative, but failing to catch problems here will affect every subsequent phase.
At DD, technology systems need to be integrated into the developing architectural and engineering design. Conduit routing needs to be coordinated with MEP. Equipment room layouts need to be developed. Power and cooling loads need to be incorporated into the engineering models.
A technology consultant engaged at DD can complete this coordination before it becomes a redesign problem. When technology enters at DD without SD groundwork, the consultant is simultaneously catching up on decisions already made and trying to influence decisions still in progress – a much harder position to be in.
At CDs, the question is whether the technology systems have been designed in sufficient detail to produce specifications and drawings that contractors can actually build from. Vague specs at this stage – the kind that result from technology scope being deferred to CDs – produce exactly the bid ambiguity and field RFI volume that derail schedules and inflate costs.
A technology consultant who has been on the project since SD will arrive at CDs with a complete picture of the design, the owner’s requirements, and the coordination already completed. The result is construction document technology specifications that support accurate bidding and clean construction.
The consequences of deferred technology planning are impossible to ignore on bid day:
Correcting scope gaps at bid is expensive in both time and outcome. The owner either accepts a higher cost, accepts reduced scope, or carries ambiguity into a contract that will resolve itself as change orders.
Technology afterthought discovered during construction must be resolved under the worst possible conditions. The clock is running, the contractor is waiting, and every day construction is delayed has a cost.
For example, field conflicts between technology conduit and MEP systems, equipment rooms that don’t accommodate the installed systems, and spec gaps that generate RFI chains are all more expensive to resolve in the field than they would have been to prevent in design.
Not all technology consultants are equally suited to work alongside an architecture team from schematic design through construction administration. The capabilities that matter most for this kind of engagement are different from what’s needed for a post-occupancy technology audit or a standalone security assessment.
The right technology consultant for architectural project work should bring:
At TMC, our work with architects spans 35+ years and covers the full range of Divisions 25, 27, and 28 across government, healthcare, education, airport, stadium, and enterprise projects. We engage at schematic design, stay through construction administration, and bring no vendor allegiances to the table – only our clients’ interests.
The best way to protect a technology-intensive building project from cost overruns, coordination failures, and owner disappointment is to engage a consultant before the design locks in decisions that technology systems can’t support. That means at schematic design – not design development, CDs, or bid.
Ready to engage a trusted technology consultant? At TMC, we partner with architects from the earliest phases of design through construction closeout. Our experts will:
If you’re working on a project where technology scope is a significant part of the program, contact our team today to talk through how early engagement can protect your project – and your firm’s reputation.