Every superintendent has a story about the RFI that ate a month. Mine was a curtain wall embed detail on a five-story podium job. The question went in on a Tuesday, looked routine, and sat in the architect's inbox behind a stack of finish selections. By the time the answer came back, we'd already poured two levels of deck with the wrong embed spacing cast in. The fix cost us drilled-in anchors, an engineer's letter, and eleven working days we never got back. Nobody set out to blow the schedule. The RFI just fell through a crack, and the crack was invisible until it wasn't.
That's the real problem with Requests for Information. It isn't that they exist — questions are healthy, and a contractor who never writes an RFI is usually one who's guessing. The problem is that RFIs live in a different world than the schedule. They sit in a log, in an inbox, in somebody's ball-in-court queue, quietly aging, while the work they're blocking marches straight toward them on the calendar. Good project management software for construction exists to collapse those two worlds into one, so a pending question shows up as a threat to next week's plan before it becomes this week's stop-work.
Why RFIs Are Really a Scheduling Problem
Treat an RFI as a piece of paper and it becomes an administrative chore — log it, route it, file the response. Treat it as a schedule constraint and everything changes. An open RFI is a hold on a specific activity, at a specific location, with a specific date it has to clear by or the work behind it can't start.
That's the mental shift that separates crews who stay ahead from crews who are always reacting. In the Last Planner world it's just constraint analysis: before an activity is allowed onto the weekly work plan, it has to be clean — materials on site, prerequisite work complete, inspections lined up, and no unanswered questions hanging over it. An RFI is one of the most common constraints there is, and it's the one people most often forget to check because it doesn't take up space on the jobsite. You can walk the floor and see that the drywall isn't stocked. You can't walk the floor and see that the answer to the header question hasn't come back.
So the first job of any tool handling RFIs well is to tie each open question to the activities it blocks and the date those activities need it by. Once that link exists, a pending RFI stops being a line in a log and becomes a countdown clock against your look-ahead.
Write the RFI So It Comes Back Answered
Software can route a bad RFI just as fast as a good one, and a bad RFI is worse than none because it burns days and comes back useless. Before any of the tracking matters, the question itself has to be written to get a real answer on the first pass.
- Ask one question. The multi-part RFI is a trap. Bundle five questions and the architect answers three, defers one, and misses the last — and now you're chasing the whole thing again. One RFI, one issue.
- Propose your answer. Don't ask "what should we do here?" Ask "we intend to do X per detail Y — please confirm or advise." A confirm-or-correct question turns around far faster than an open-ended one, because you've done the design team's thinking for them.
- Reference the exact document. Drawing number, detail callout, spec section and paragraph. If the reviewer has to hunt for what you're even talking about, your RFI goes to the bottom of the pile.
- Say what it blocks and when. "This holds the level 3 deck pour scheduled for the week of the 14th" gives the reviewer a reason to move. An RFI with no stated schedule impact reads as optional.
Field-generated RFIs are where quality either lives or dies. When a foreman hits a conflict at 9 a.m., the right move is to capture it right there — photo, location, drawing reference — not to carry it around in his head until he's back at the trailer that evening, half of it forgotten. A construction schedule app that lets crews raise an RFI from the exact spot, with a picture attached, catches the issue while it's still sharp. That's the strongest argument for mobile RFI creation: not convenience, but accuracy.
Ball-in-Court: The Thing That Actually Stalls RFIs
If you audit a stalled RFI log, you'll rarely find questions that are genuinely hard to answer. You'll find questions where nobody was sure whose move it was. It went to the architect, who kicked it to the structural engineer, who wanted the manufacturer's shop input, and for two weeks it sat in the gap between three parties, each assuming another had it.
This is where honest ball-in-court tracking earns its keep. Every RFI should show, at a glance, exactly one party who owns the next action and how long it's been sitting with them. The moment ownership is fuzzy, the RFI stops moving. A clean system makes the holder visible and the clock loud — and it lets you run a weekly report that answers the only question that matters in the coordination meeting: what's been sitting the longest, and with whom?
A practical rule of thumb: any RFI with real schedule impact that's been in one court more than five working days needs a phone call, not another email. The log tells you which ones. The phone call is still yours to make.
Setting Realistic Turnaround and Building the Buffer
Most contracts spec a response window — often ten or fourteen calendar days. Plan as if the reviewer will use every day of it, because they will, and then some. That means the discipline isn't in the tracking, it's in the timing of submission.
Work it backward from the look-ahead. If an activity is four weeks out on your look-ahead schedule and it depends on an answer, and the contract allows fourteen days for a response, the RFI has to be in this week — not the week before the work, when it's already too late to matter. A three or four week look-ahead exists precisely to surface these needs early enough to act. The window between "we spotted the constraint" and "we need it resolved" is your working room, and RFIs are the constraint most likely to blow through it if you submit reactively.
I tell every PM I work with to add a couple days of their own buffer on top of the contract window for anything that touches structure or a critical path activity. Answers that require an engineer's calc, a manufacturer's confirmation, or a redesign don't come back in the standard window no matter what the spec says. Build the pad in when you plan the submission, not when you're already late.
When the Answer Comes Back: Distribution and Downstream Effects
An answered RFI helps nobody if the answer stops at the PM's desk. The response has to reach every trade whose work it touches, and it frequently touches more than the trade that asked. A framing RFI answered with a revised header detail affects the framer, sure — but also the electrician who was going to run through that wall, the mechanical contractor whose duct clears it by an inch, and the inspector who's going to look at all of it.
Solid distribution management means the response goes out with acknowledgment tracking, so you know it landed and wasn't just fired into a group email nobody opened. And the useful next step is connecting that response back to the schedule it was holding: the constraint clears, the activity releases onto the weekly work plan, and the crews who were waiting get the green light through the same board they already watch. On a rolling look-ahead, this closure should be visible — the item that was flagged red for a pending answer flips clear, and everyone downstream sees the path open.
Watch for the RFI that comes back as a scope change in disguise. "Provide additional blocking as shown" is a design clarification and a change order all at once. A tool that lets you flag an RFI as change-order-generating keeps that thread connected, so the schedule adjustment and the cost conversation don't drift apart and surprise you at closeout.
Documenting Impact — Because Sometimes the Delay Isn't Yours
Here's the part crews skip until it hurts them: when a slow RFI response actually delays the work, you need the record to prove it. The date you asked, the date you got an answer, the activity that sat idle in between, and the crew that stood around or got pulled to other work. That timeline is the backbone of any legitimate time-extension request or delay claim.
You don't build that record after the fact — you can't, honestly, because memory doesn't hold dates. You build it by logging RFIs against affected activities as you go, so the impact is captured in the ordinary course of the work. When a design team's delay genuinely costs you, contemporaneous documentation is the difference between a claim that holds and a claim that's your word against theirs. This is the quiet, unglamorous reason to keep the log tight even on the RFIs that eventually resolve fine.
Learning From the Log
Over a full job, your RFI log is a map of where the drawings were weakest. Cluster them by category — waterproofing details, dissimilar-metal connections, whatever your recurring pain was — and you've got a punch list for the next preconstruction review with that architect or on that building type. Contractors who mine their own history stop asking the same question on every project. It's the cheapest process improvement available, and almost nobody does it because the data sits in a log they never look back at.
The Bottom Line
RFIs don't wreck schedules because they're hard to answer. They wreck schedules because they age in the dark, disconnected from the work they're holding, until the work catches up to them. The whole point of managing them through real construction software is to keep them in the light — tied to the activities they block, owned by exactly one party, counted down against real dates, and closed out where the crews can see it.
That's also exactly what a good look-ahead does for every other constraint, which is why RFI tracking and short-interval scheduling belong in the same conversation. When your open questions and your weekly work plan live on the same board — the way they do in a tool like LookAheadWall — a pending answer stops being an inbox item and becomes what it always really was: a date on your calendar you're either going to beat or explain. Beat it early enough and nobody ever hears about the RFI. That's the goal. The best RFI management is the kind that keeps the story about the curtain wall embed from ever happening in the first place.