The RFI Backlog Is Eating Your Data Center Schedule

The Volume Is a Symptom

A typical hyperscaler data center build will generate somewhere between 2,000 and 5,000 requests for information across construction. The conventional industry narrative blames the volume: too many RFIs, too many trades, too much complexity. That framing is convenient, and it misses the actual problem.

The volume is a symptom. The schedule pain comes from how long each RFI sits unresolved. A program that generates 3,000 RFIs and resolves them in a median of 4 days is usually in better shape than a program with 1,500 RFIs and a 12-day median. The first program has trade contractors moving. The second has crews working around frozen scopes and burning float they will not get back.

Routing is the bottleneck.

Where the Days Actually Disappear

Look closely at the lifecycle of an RFI on a typical mission-critical program. The Navigant Construction Forum's study of 1.1 million RFIs across 1,362 projects put the median reply at 9.7 days and the processing cost near $1,080 per RFI. From the time the field engineer submits the question to the time the response is logged, the breakdown on the programs I have worked looks something like this: 4 to 6 days for routing and assignment, 3 to 5 days for clarification loops, 2 to 3 days for the actual engineering response, 1 to 2 days for closeout. The engineering work, the part that requires a trained design professional, accounts for 20 to 30 percent of the elapsed time. The rest is administrative friction.

That is the part of the workflow that rarely shows up in a post-project review. Routing decisions, ownership churn, scope clarification with the originator, the back-and-forth to determine whether the question belongs to structural, MEP, or commissioning. Each handoff costs hours, sometimes a day. Multiply that across a few thousand RFIs and the program is bleeding weeks of cumulative response time that did not need to be lost.

Three Disciplines That Cut Cycle Time

The first is a defined classification taxonomy applied at submission. Most programs let the field engineer write the question in free-text and assign a generic category like Structural or MEP. That all but guarantees a routing review at the receiving end. A taxonomy that forces the originator to identify the specific system, the specific trade interface, and the level of design impact does the routing work upfront. The cost is a few seconds at submission, and the saving is a day or two on the back end.

The second is named ownership at the gate. Every RFI category should map to a specific named owner who is responsible for either resolving it or routing it to someone else within 48 hours. A named individual with a clear default-yes-or-route decision holds up far better than a rotating MEP coordinator role. Ownership ambiguity is among the largest contributors to RFI sit-time, and it is fixable with one well-maintained matrix.

The third is response SLA tiers tied to schedule impact. A field-blocking RFI on a critical-path activity carries a different priority from an as-built clarification six months from closeout. Treating them with the same response cadence is what produces the long tail of stale RFIs that age past 30 days. A tiered SLA, with the highest tier hitting a 48-hour cap and the lowest tier at 14 days, gives the design team a basis for triage and the field a basis for escalation.

Predictive Routing Is Within Reach

The next improvement layer is predictive routing. A model trained on the project's historical RFI log can predict, at submission time, which discipline owns the question and which named owner is most likely to resolve it. A prediction that is right 70 to 80 percent of the time is enough to remove the routing review on most RFIs.

A program that already maintains a structured RFI log has the training data sitting in its system today. For teams with a clean RFI log, a first routing classifier is a contained build. The benefit on cycle time is measurable inside the first month. For project controls teams, this is one of the rare AI uses with a short feedback loop and measurable cycle-time impact, and it rarely gets prioritized, because the RFI workflow is treated as a clerical function instead of the schedule-critical one it is.

Treat the Log Like a Live System

The deepest fix is cultural. Most programs treat the RFI log as a record-keeping artifact. The PM reviews it weekly. The design team responds when notifications arrive. The field follows up when something is overdue. Rarely does anyone own the log as a system with performance metrics and improvement targets.

The better operating model treats the RFI log the way the team treats the schedule: a living instrument with weekly review, cycle-time accountability by category, and named owners for the categories that drift. The number to manage is the median resolution time by tier, with a tracked trend line on aging RFIs. The count of open RFIs is the noisier metric and tells you less. Once the cycle-time KPI is reviewed by the PM and the construction manager every week, behavior usually changes inside two weeks.

The data center construction market is already squeezing schedule on every dimension. Treat the RFI log as a controllable variable, build the routing discipline, and instrument the cycle time. If the log stays administrative, float loss will keep arriving as a surprise, even when it does not show up cleanly in the report.