Every project schedule assumes a certain amount of friction — weather days, permit delays, material lead times. But there’s one delay source that shows up on almost every project, in almost every phase, and rarely gets the scrutiny it deserves: the Request for Information, or RFI.
An RFI is meant to take minutes to write and, ideally, a day or two to answer. In practice, on many projects, RFIs sit open for a week, two weeks, or longer — and every day one sits unanswered is a day of risk: idle crews, rework, or a decision made on a guess instead of a confirmed answer. This post breaks down exactly why RFIs cause so much delay, what makes the problem worse on large EPC (engineering, procurement, and construction) projects specifically, and what’s actually fixable versus what’s inherent to the process.
The RFI Delay Isn’t One Problem — It’s Five
When people say “RFIs are slowing us down,” they’re usually describing one or more of five distinct failure points, each of which compounds the others.
1. Classification Delay
Before an RFI can be routed anywhere, someone has to read it and figure out what kind of question it actually is — structural, MEP, life safety, finish selection, scope clarification, or something else entirely. On a busy project, this triage step often waits in a queue behind other administrative work. If the person doing the triage is out sick, traveling, or simply behind on email, every RFI submitted that day sits untouched until they resurface.
2. Routing Delay
Once classified, an RFI has to reach the correct reviewer — and construction projects often have a sprawling, non-obvious chain of who’s responsible for what. A structural question involving a foundation redesign might touch the structural engineer, the geotechnical consultant, and the owner’s budget approval, in that order. If an RFI gets sent to the wrong person first, the clock doesn’t stop — it just runs invisibly until someone notices the misroute and forwards it, often days later.
3. Prioritization Delay
Not every RFI is equally urgent, but most manual systems treat them as a first-in-first-out queue. A question that’s blocking tomorrow’s concrete pour should jump ahead of a question about carpet color due in six weeks — but without an explicit priority flag and someone actively managing that queue, urgent RFIs get buried under routine ones simply because of submission order.
4. Response Delay
Even once an RFI reaches the right person with the right priority, the reviewer still needs time to research the answer — checking other drawings, consulting a colleague, or reviewing site photos. This part of the delay is legitimate: some questions genuinely require careful technical judgment. But this stage becomes disproportionately long when the reviewer has to first track down the referenced drawings and specs manually, rather than having them surfaced automatically alongside the question.
5. Escalation Delay
When an RFI blows past its agreed response window, most manual processes have no automatic mechanism to flag it. Someone in the field has to notice the delay, chase it down, and escalate it — which often only happens once the delay has already cost a day of schedule. Without a built-in escalation trigger, RFIs default to sitting quietly until they become urgent enough that someone complains.
Each of these five delay points is independently small — hours here, a day there — but stacked together across hundreds of RFIs on a single project, they add up to weeks of schedule float being quietly consumed.
Why the Cost Is Bigger Than It Looks
An unanswered RFI rarely delays just one task. Construction sequencing is interdependent: framing can’t start until curing is confirmed, MEP rough-in can’t start until framing is inspected, and finishes can’t start until MEP is closed up. When an RFI blocks one link in that chain, every downstream trade either sits idle or has to be re-sequenced — which itself takes coordination time and often means paying a crew to remobilize later.
There’s also a quieter cost: when field teams get tired of waiting on slow RFI responses, they sometimes proceed on a best guess to avoid losing a day, which is exactly the scenario RFIs exist to prevent. A guess that turns out wrong becomes rework — demolishing and rebuilding a wall section, re-pouring concrete, or re-routing conduit — which costs far more than the delay would have.
What Makes This Worse on EPC Projects
EPC (engineering, procurement, and construction) projects — common in infrastructure, industrial, and energy work — face a version of this problem that’s structurally harder than a typical commercial build.
Multiple engineering disciplines working in parallel. A single EPC project might have civil, structural, mechanical, electrical, instrumentation, and process engineering teams all issuing and receiving RFIs simultaneously, often across different companies or joint venture partners. Routing a question correctly requires understanding not just the discipline, but which specific engineering firm or subcontract package owns that scope.
Geographic and time-zone separation. EPC projects frequently have design offices, procurement teams, and field construction spread across different countries and time zones. An RFI submitted at the end of a site’s workday might not reach an active reviewer until the next business day somewhere else — adding built-in latency before anyone even opens it.
Contractual complexity. Large EPC contracts often have detailed clauses governing exactly who has authority to answer what kind of RFI, tied to liability and change-order implications. A question that looks purely technical on the surface may actually require sign-off from a contracts administrator before an answer becomes official — adding a layer of review that’s easy to overlook until it causes a delay.
Sheer volume. EPC projects can generate RFI counts in the thousands over the project lifecycle, with hundreds open at any given time. At that scale, manual triage isn’t just slow — it becomes practically unsustainable without dedicated administrative staff whose full-time job is RFI logistics rather than engineering judgment.
Higher stakes per RFI. Because EPC projects often involve safety-critical systems — pressure vessels, electrical systems, structural load paths — the review process for each RFI tends to be more rigorous, and the cost of a wrong guess in the field is proportionally higher. This makes speed and accuracy both matter more, at the exact moment when volume makes both harder to maintain.
Common RFI Challenges Beyond EPC
Even outside large EPC work, several recurring challenges show up across almost every project type:
- Duplicate RFIs from different subcontractors asking about the same conflict, because there’s no shared, searchable log they can check first
- Incomplete RFIs that reference the wrong drawing revision or leave out a spec section, forcing a round-trip just to clarify the question itself
- Siloed communication tools — RFIs tracked in Procore, but urgent flags communicated over text or WhatsApp, so nothing lines up in one place
- No visibility for project executives, who often don’t know how many RFIs are open, which are overdue, or which discipline is the current bottleneck until it shows up in a monthly report
- Inconsistent response-time expectations between different design firms or consultants on the same project, so some RFIs get fast answers and others sit for weeks with no clear reason why
Measuring the Real Cost of RFI Delay
Most teams feel the pain of slow RFIs anecdotally — a crew standing around, a frustrated superintendent — but few actually measure it. A useful exercise for any project team is to track, for a sample of recent RFIs, the gap between submission date and the date a decision was actually usable in the field, then multiply that by the daily cost of the crew or equipment sitting idle because of it. On projects that run this exercise, the numbers are often larger than expected, because the delay isn’t just the reviewer’s response time — it’s the classification, routing, and escalation lag stacked on top of it, most of which never shows up in a status report until someone goes looking.
This is also why RFI delay is often invisible to project executives until it’s already baked into a missed milestone. A weekly status report might show “RFI #402 – open,” but it rarely shows that the RFI sat unclassified for two days before anyone routed it, or that it was sent to the wrong engineer first. Without that visibility, the same delay patterns repeat project after project, because nobody can see where the time is actually going.
A Realistic Scenario
Consider a mid-size commercial build with a framing crew scheduled to start on a new section the following morning. The crew lead notices that the drawing shows a beam depth that conflicts with the structural spec — a routine but urgent discrepancy. An RFI is submitted through the project’s document control system that afternoon.
In a manual process, the RFI sits in a shared inbox overnight because the project engineer who normally triages incoming RFIs is out of office. The next morning, it’s finally read, classified as structural, and forwarded to the structural engineer — who is now the third person to see it, roughly 18 hours after submission. The engineer answers within two hours, but by then the framing crew has already had to be rescheduled, and the subcontractor invoices for a partial mobilization charge.
None of the individual steps in this chain was unreasonable on its own — the triage delay was overnight, the routing took a few minutes, the actual engineering answer was fast. But stacked together, the total time from submission to usable answer was long enough to cost a full day of schedule and an unplanned mobilization fee. This is the pattern that repeats, at varying scale, across almost every project that manages RFIs primarily through email and manual review.
How AI Closes These Gaps
The common thread across all five delay points — classification, routing, prioritization, response, and escalation — is that they’re all information-processing tasks: reading a question, understanding its context, matching it to the right person, and tracking a deadline. These are exactly the tasks well-suited to an AI agent working alongside your existing document control system.
An RFI-focused AI agent can read an incoming question, cross-reference it against project drawings and specifications, classify what discipline it belongs to, route it to the correct reviewer based on your project’s actual authority structure, flag it as urgent if it’s tied to a near-term schedule milestone, and automatically escalate it if no response comes back within the agreed window — all without replacing Procore, Autodesk BIM 360, or whatever system you already use for document control.
RhinoAgents’ AI Agents for Construction include an RFI & Document Assistant built specifically for this workflow — ingesting RFIs, checking them against blueprints and specs, and routing and escalating them automatically, so the five points of manual delay described above stop being silent schedule killers. It plugs into your existing project management stack and can push urgent alerts straight to site teams over WhatsApp or SMS the moment a priority RFI needs attention.
The Takeaway
RFIs don’t delay projects because the questions themselves are hard — most are answered in minutes once they reach the right desk. They delay projects because the logistics around getting a question to the right person, at the right priority, with an enforced deadline, break down at scale. Fixing that logistics problem — through better process discipline, standardized RFI templates, and increasingly through AI-assisted classification and routing — is one of the highest-leverage things a project team can do to protect schedule and margin.
If your team is losing days to RFI logistics rather than the actual technical review, it’s worth seeing how automated classification, routing, and escalation compares to your current process. You can explore RhinoAgents’ construction AI agents to see how it fits alongside your existing tools.
