The RFI backlog is the delay nobody blames

A request for information, or RFI, is a standard construction document formalized by AIA’s summary of the G716 RFI form, used when an owner, architect, or contractor needs to request clarification that can’t be resolved by simply reviewing the plans or specifications. On paper, an RFI is a small, routine document. In practice, on a multi-site buildout program, the accumulated time spent waiting on RFI answers is one of the more common and least discussed causes of schedule slippage, and it rarely gets named as the reason a project finished late.

The conventional view: RFIs are a communication tool, not a delay risk#

Most project teams treat RFIs as administrative housekeeping: a contractor has a question, submits it, waits for an answer, and moves on once it arrives. Under the standard form, an RFI response isn’t supposed to authorize additional cost or time on its own, so on the surface it looks schedule-neutral. Delays, in this view, come from bigger, more visible causes: a labor shortage, a permitting holdup, a weather event, a change order that blows up scope. RFIs sit in the background as paperwork, not as a schedule risk in their own right.

Why that view falls short#

The problem with treating RFIs as schedule-neutral is that work behind an unanswered RFI usually doesn’t continue. A framing crew that needs a clarification on a detail can’t safely guess and keep going. A finish contractor waiting on a spec confirmation holds their sequence rather than risk redoing the work. Each of those pauses is small on its own and easy to explain away individually. Stacked across a project with dozens of open RFIs, especially on a program running several similar buildouts where the same design ambiguity generates the same question at every site, that waiting time adds up to real schedule loss that never gets logged as a single, attributable delay. See how schedule slippage becomes a cost problem before anyone catches it. An oft-cited industry benchmark from a 2013 Navigant Construction Forum study put median RFI closure time at roughly 9.7 days; that figure is old enough and cited secondhand widely enough that it shouldn’t be treated as current fact without a fresher, directly sourced number. What doesn’t need a fresh citation is the mechanism: every day an RFI sits open past the point where downstream work depends on the answer is a day that rarely gets coded as "RFI delay" on the schedule, even though that’s exactly what it is.

The reframe: RFI turnaround is a leading indicator, not paperwork#

Once RFI response time is tracked as its own metric, separate from the general schedule view, it starts to function as an early warning sign rather than an administrative record. A design team that consistently takes two to three weeks to answer RFIs is a schedule risk that shows up before the first missed milestone does, the same way a vendor with a pattern of late deliveries is a risk that shows up before the first blown budget line. See evaluating vendors against their own track record, not just the current bid. On a program running multiple similar buildouts, an RFI that took three weeks to answer at the first site and gets asked again, unanswered, at the fifth site is a design or specification gap that should have been fixed once, not re-litigated project by project.

What it means in practice#

None of this requires new software or a heavier process. It requires logging RFI submission and response dates with the same discipline as milestone dates, and reviewing turnaround time as its own line in the same meeting where schedule and budget get reviewed, not as a separate log nobody checks until a delay has already happened. For an owner running several capital projects a year, the RFI log across all of them, not just one project, is usually a more honest early signal of where the next delay is coming from than the schedule itself. See how REAL tracks budget, schedule, and vendor performance together on capital projects. The schedule slip that gets attributed to "the trades were behind" almost always has an earlier cause sitting in the RFI log, a question that took three weeks to answer instead of three days. Treat that number like the leading indicator it is, and the postmortem gets a lot shorter.