Infrastructure Must Be Engineered Before Installation Begins — Or the Building Won’t Support Its Systems
Most technology failures don’t happen because equipment was installed incorrectly.
They happen because the infrastructure wasn’t fully engineered.
I saw this firsthand.
A Real Project: No Infrastructure, Only Pathways
I joined a project after construction drawings were already complete. One of my first tasks was simple: confirm the building could support its technology systems.
I was told, confidently:
“Technology has been handled.”
“IT is coordinating it.”
So, I asked to see the technology design.
There wasn’t a complete technology design package yet.
What existed were pathway drawings:
- Cable trays
- Conduit runs
- Distribution routes
What didn’t exist was infrastructure:
- No rack layouts
- No equipment rooms
- No AV power
- No conduit to AV endpoints
- No wall backers for displays
- No system architecture
- No capacity planning
The operational requirements for the systems the building needed to support hadn’t been fully defined.
The drawings showed where cable could go.
They did not define what the cable served.
Nothing defined what was at the ends of the cables.
This distinction is important.
Pathways are distribution.
Infrastructure defines the systems.
And in this project, infrastructure hadn’t been engineered.
This Goes Far Beyond “IT”
Most people assume technology means network and Wi‑Fi.
It doesn’t.
A modern building’s technology ecosystem includes:
- Access control
- Door hardware and locking interfaces
- Security and surveillance
- AV systems and displays
- Lighting control platforms such as Lutron
- Motorized shades
- Paging and background audio
- Control processors and relays
- Power, cooling, and space allocation for all of it
These systems don’t operate independently. They operate in concert:
- Shades lower
- Lights dim
- Displays activate
- Doors secure and release
None of that works reliably without infrastructure engineered to support it.
The Problem Was Already Locked In
By the time the gap was discovered, critical decisions were already final:
- MEP systems were sized
- Space was allocated
- Construction documents were issued
- Pathways were drawn
But none of it was based on operational requirements.
Infrastructure hadn’t driven the design.
Installation had.
Once construction documents are issued, infrastructure is no longer designed.
It is corrected — always at greater cost.
How This Happens — Even When Everyone Does Their Job
The IT team hired a reputable integrator.
The integrator did exactly what integrators do: they produced pathway layouts.
But pathway layouts assume infrastructure already exists. They assume:
- Equipment rooms exist
- Power exists
- Cooling exists
- Capacity exists
- System architecture exists
None of that had been defined.
Instead, each party made reasonable assumptions:
- The architect assumed IT had defined the requirements.
- The integrator assumed infrastructure had been engineered upstream.
- IT assumed the infrastructure would support operations.
David J. Goetz, CPP, PSP, Senior Principal and NY ICT Manager at NY based technology design firm Shen Milsom & Wilke reinforces a critical point: "Pathway layouts alone cannot define infrastructure. Infrastructure must be planned and engineered based on operational requirements before installation begins."
Everyone acted logically within their role.
But no one performed infrastructure engineering.
And no one interviewed end users to understand how the building actually needed to function.
At this stage, gaps in infrastructure were effectively built into the project.
The infrastructure was being planned without defining its purpose.
Infrastructure Engineering Begins With Assessment — Not Installation
As Goetz explained, "Infrastructure engineering must begin with assessment and programming."
- Not installation.
- Not device selection.
- Not pathway layouts.
Assessment means understanding how the organization operates and engineering infrastructure to support it. That requires:
- End‑user interviews
- Programming and planning
- Capacity and growth analysis
- Power and cooling evaluation
- Coordination with architectural, mechanical, and electrical systems
- Early identification of risks and constraints
- Sequencing infrastructure into the broader building design
Infrastructure engineering is a front‑loaded discipline.
It must inform the building — not chase it.
When assessment and programming are skipped, infrastructure isn’t fully defined. Planning is based on assumptions.
And assumptions can lead to gaps.
The Gap Was Larger Than Anyone Realized
When independent infrastructure evaluation finally occurred, the extent of the problem became clear.
The building didn’t just need minor adjustments.
It needed infrastructure that had never been engineered.
An entirely new IT room had to be created.
Not relocated.
Not expanded.
Created.
The original design had assumed existing IT rooms would suffice. Once infrastructure requirements were properly evaluated, it became clear that system distribution distances, pathway routing, and network architecture required an additional intermediate distribution point (another IDF Room).
Without it, system performance, reliability, and future scalability would be compromised.
Adding this technology room required:
- Reallocating usable space
- Modifying pathways
- Coordinating new power and cooling
- Revising construction documents already issued
This infrastructure wasn’t added as an enhancement.
This infrastructure was always required; it had not yet been fully engineered.
Cooling capacity was also insufficient in multiple technology rooms. Spaces had been allocated, but thermal loads had never been calculated.
Critical conduit pathways were missing entirely; AV endpoints and distributed equipment locations had no infrastructure to support them.
At the same time, other areas were overbuilt and pathways were based on assumptions rather than engineered requirements.
Infrastructure wasn’t optimized; it had been estimated rather than fully engineered.
Because these gaps were discovered after construction documents were issued and pathways were installed, correcting them required redesign, re‑coordination, and avoidable cost.
The building had been designed.
The technology infrastructure had not.
This Happens Everywhere — Not Just Large Projects
This issue appears in:
- Office fit‑outs
- Tenant improvements
- Leased spaces
- Renovations
- Build‑to‑suit environments
- Even smaller projects require infrastructure definition before installation begins.
Otherwise, the same failure occurs — simply on a smaller scale.
Design and Installation Are Not the Same Thing
Technology design engineers define infrastructure.
Integrators install systems.
Both roles are essential.
But they are not interchangeable.
Infrastructure must be engineered first.
Installation must follow.
Reversing that sequence guarantees correction later.
The Bottom Line
Technology failures rarely happen because equipment wasn’t installed.
They happen because infrastructure was never engineered.
Pathways are not infrastructure.
Infrastructure must be intentionally designed before installation begins.
The correct sequence is clear:
→Assessment
→ Infrastructure Engineering
→ Installation
Get that sequence right, and technology supports operations.
Get it wrong, and you correct it later — at significant cost.
As Goetz reinforced, "Infrastructure engineering must lead the design process — because once installation begins, it is already too late to define what the building truly needs to support."
If infrastructure isn’t engineered first, installation doesn’t solve the problem.
It exposes it.
Frequently Asked Questions
What is technology infrastructure engineering in building design?
Technology infrastructure engineering defines the power, cooling, capacity, space allocation, and system architecture required to support building systems before installation begins. It ensures operational requirements drive the design — not assumptions.
What is the difference between pathway drawings and infrastructure engineering?
Pathway drawings show distribution routes such as conduit and cable trays. Infrastructure engineering defines the system requirements, capacity, room planning, and operational support those pathways must serve. Pathways distribute systems. Infrastructure defines them.
When should technology infrastructure be designed in a construction project?
Technology infrastructure should be defined during programming, schematic design, and design development — before construction documents are issued. Infrastructure must inform the building design, not be corrected after installation begins.
Be the first to comment on "The Building Was Designed. The Technology Infrastructure Wasn’t"