Megawatt Horizon

RFI Volume Benchmarks and Root Cause Patterns in Large Data Center Programs

Coordination conflicts and equipment delays drive RFI volume in large data center campuses.

· 8 min read
Cover illustration for “RFI Volume Benchmarks and Root Cause Patterns in Large Data Center Programs”
Portfolio Management · October 27, 2026 · 8 min read · 1,833 words

DCIM-ready BIM handoff from design models to operations requires structured asset data that stays connected through design, construction, and commissioning to avoid manual reconstruction at handover. A connected project approach addresses that upstream problem. The same approach tackles what drives high RFI volume in large data center programs: coordination conflicts, equipment specification gaps, and compressed campus schedules.

Why data center programs generate RFIs at a structurally different rate than other large construction

A single large data hall can generate hundreds of requests for information, or RFIs, on its own. A campus compounds that count across buildings with separate design and construction contracts. A high count reflects a building type where dense systems, long-lead equipment, and overlapping phases continually create questions that cross contract and discipline boundaries.

Project value also makes simple comparisons misleading. Large projects tend to produce fewer RFIs per million dollars than mid-size projects, even as their total counts rise. A campus can therefore show a lower cost-normalized rate while imposing a much greater review burden. The useful benchmark must account for both scale and the conditions producing the questions, rather than treating every dollar of construction as an equal source of uncertainty.

How campus-scale phasing multiplies coordination surface area beyond what a single-project RFI model captures

A data hall that once represented an entire facility can now be one phase of a multi-hundred-megawatt campus. Each phase inherits upstream decisions and imposes constraints downstream. The buildings are not independent units of work. Shared switchgear rooms, cooling plants, fiber entry points, and generator yards have interfaces that cross more than one design contract. Questions about who owns those interfaces lead to RFIs whose causes cannot be seen in a count for one building.

When schedules overlap, those interfaces are harder to settle. Later phases can be in design and construction while earlier phases enter commissioning. An answer issued in Phase 1 may contradict a Phase 2 drawing, producing a new question even though the original issue was resolved.

The announced commitments make that scale concrete. Amazon’s Pennsylvania investment pages identify AWS campus locations in Salem Township, Luzerne County, and Falls Township, Bucks County. Vantage Data Centers’ Frontier campus is planned at 1.4 GW in Shackelford County, Texas. STACK Infrastructure and BorderPlex Digital Assets’ Project Jupiter spans over 30 years in Doña Ana County, New Mexico. These are programs of interdependent contracts, where phased delivery is a structural condition.

Multi-discipline coordination failures as the primary RFI origin in data hall design

The largest source of data center RFIs is unresolved conflict among dense, interdependent systems. Power distribution, cooling equipment, cable trays, fire protection, and structural elements compete for constrained space. Each discipline can be correct in isolation. The conflict arises when two technically valid drawings show systems that cannot both be installed as drawn.

Once installation exposes the conflict, resolving it can require work stoppage, redesign, material changes, and schedule recovery. Power and cooling coordination also has consequences beyond construction. The Uptime Institute 2024 Global Data Center Survey found that power was the primary cause of impactful outages for 54% of operators surveyed, with cooling second. The survey finding shows the operational stakes of the power and cooling systems involved.

As AI workloads increase rack density, airflow and power-distribution assumptions that were acceptable at lower loads can push systems past design limits. A generic rack placeholder cannot test the cabinet's actual depth, its breaker positions, or its thermal output. Coordination needs accurate equipment information as much as it needs clear relationships between disciplines.

Equipment specification gaps as a compounding RFI driver, from long-lead procurement through submittal review

Design teams often get equipment information in manufacturer PDF data sheets that require conversion for use in a model. Specifications for switchgear, UPS, PDUs, cooling units, and generator sets may exist without being integrated into drawings or validation rules. The information exists, but the design cannot use it. A standard rack can conceal actual cabinet depth, while a simplified structural model can understate equipment weight. Procurement, submittal review, and installation expose those assumptions one by one.

Long-lead equipment makes the timing worse. Design teams need accurate specification data for large transformers, switchgear, and custom cooling assemblies, but may get the final specifications late in design. When a submittal differs from the assumptions already used, every affected model, drawing, and schedule needs review. A mismatch can also trigger rejection and resubmission, adding review work even when it does not become a formal RFI.

ArchiLabs’ equipment-data approach addresses this gap by treating extraction as the start of a connected workflow. Manufacturer data trapped in PDFs is wasted intelligence if it never reaches the model. Flowing it into models, validation rules, and coordination workflows makes actual equipment parameters available where design decisions are made. The value is not merely faster reading, but fewer downstream decisions built on placeholders.

How compressed schedules turn normal design uncertainty into accelerated RFI production

Compressed delivery concentrates unanswered design questions into a shorter period while leaving less time for careful answers. Large programs are shifting from time-to-build toward time-to-energize as the binding constraint, even as power procurement, permitting, and equipment lead times extend. That mismatch pushes design and construction into tighter overlap.

With fast-track delivery, field work starts before the design is complete. As a result, crews can need an answer before the design team has developed it. The response then delays work or accepts risk. An orderly RFI process cannot remove that choice when the underlying engineering remains unresolved. Response speed alone is therefore a poor measure of whether the program has controlled its exposure.

The other root causes intensify this pressure. A late equipment specification can invalidate a coordinated layout just as installation begins, while the proposed fix affects shared infrastructure serving another phase. The question now crosses equipment, discipline, and contract boundaries while crews wait for an answer. Each condition amplifies the others, so the review burden grows through their interaction rather than through a simple addition of separate problems.

What BIM coordination actually resolves and where it leaves RFI root causes untouched

Building information modeling, or BIM, can solve spatial conflicts before crews run into them. A federated model brings disciplines together so that competing routes and equipment locations can be examined before installation. That is a real reduction in field uncertainty. Tracked coordination issues with viewpoints, owners, and due dates also help keep conflicts under review after a weekly meeting until they reach resolution.

But a coordinated model is only as useful as its equipment data. Approximate cabinets and cable trays can fit together while their actual counterparts do not. Clash detection cannot supply a final specification that has not arrived, nor answer an engineering question that schedule compression has brought forward. Automating extraction does not remove the need to govern data quality before safety-critical decisions depend on it.

The limits extend to asset information. COBie and structured asset data are often validated at closeout rather than throughout design and construction, delaying detection of handoff defects until correction is hardest. A governed common data environment improves traceability and decisions by connecting models, RFIs, submittals, and field photos. Its governance is limited to information flow. The next source of persistent RFI volume is what happens when those records remain separate.

How fragmented information workflows convert root-cause conditions into sustained RFI volume throughout a program

Fragmentation makes the same uncertainty return after someone has resolved it. Teams manually rebuild information in models, RFI logs, submittal registers, equipment schedules, and cable routing sheets. A change in one record does not propagate automatically. Each document that depends on that record is another place where the old design can remain. Under schedule pressure, that divergence reaches the field as a fresh question.

A rack move shows how this happens. Relocation affects power capacity, cooling load, cable routing, fire suppression zones, and structural loading. Those dependencies are often in different documents or systems, and each one needs to be updated. If the updates do not happen in sequence, a field team can receive a drawing that no longer matches the design intent. The resulting RFI is new paperwork for a change already decided.

An RFI answer can create the same problem. Closing the log entry does not update the model, equipment schedule, or operations documentation. The answer may remain isolated in the most complete record of what was uncertain and how it was resolved, then resurface as a discrepancy during commissioning or handoff. Traceability prevents that recurrence by linking answers, decisions, and equipment parameters to their supporting information.

How does a connected project workflow support DCIM-ready BIM handoff and prevent RFIs upstream?

For teams addressing those causes, the shift is from tracking questions to connecting the information that produces them. A connected operating system for data center projects joins design work with structured automation and a handoff that is ready for operations. Layouts, critical-systems engineering, cable routing, RFI logs, submittal registers, and equipment schedules share a common data record so that changes propagate without separate manual reconstruction.

In that workflow, the manufacturer specifications that teams extract go into models and validation rules. Deterministic rules check power allocation, cooling load, cable routing, and clearances using logic that field teams and commissioning authorities can review. AI has a different role in routing RFIs, flagging delays, and finding patterns in large logs. Precision and compliance require rules. For fixed modules, automation similarly centers on placement and connections to shared infrastructure.

DCIM-ready BIM handoff is the downstream test of that connected record. Structured asset data must reach data center infrastructure management systems, or DCIM, as well as EPMS and BMS, without being manually rebuilt at handover. Those system boundaries need explicit attention during design because gaps between them create operational risk. An incomplete handoff exposes fragmentation accumulated during design and construction. The goal is not merely an exportable model, but operations information that retains the equipment parameters and resolved decisions established along the way.

How project teams can use RFI origin data to anticipate volume and target prevention efforts

Teams can turn this structural understanding into a forecast by classifying RFI origins as coordination conflicts, specification gaps, schedule-driven information voids, and phasing boundaries. A prior phase’s log is more useful for locating likely trouble than a generic project benchmark. Comparing origins by phase, discipline boundary, and equipment category shows where prevention work belongs before installation starts.

Timing gives that forecast practical value. Volume tends to concentrate at phase starts, when shared-infrastructure ownership is being established, during submittal review, when specifications diverge from assumptions, and during fast-track overlap. Teams should clearly map the electrical-room-to-data-hall, cooling-plant-to-distribution, and cable-entry-to-tray-routing boundaries in coordination reviews. Those interfaces are more likely sources of questions than isolated single-discipline runs.

Large transformers, switchgear, and custom cooling assemblies should be treated as RFI risks from specification onward, with provisional assumptions flagged in the model. Origin data then provides a way to distinguish faster paperwork from lower exposure, because the categories generating questions reveal which upstream conditions remain unresolved. At campus scale, RFI volume is a known, addressable condition.

More in Portfolio Management