How to Manage Construction RFIs So the Answer Arrives Before the Crew Needs It

The pile crew hits refusal four metres above design tip elevation on the second bent of the day. The superintendent calls the office, the project coordinator writes it up as an RFI to the engineer of record, and it goes out that afternoon with a photo of the driving log. The contract gives the consultant ten business days to respond. The crane, the barge, the hammer and a six-person crew are on the clock every one of those days. On day four the super gives up waiting, skips to the next bent, and reconfigures the leads. On day nine the answer comes back: drive to refusal, confirm capacity with a PDA test, carry on. By then the rig is two bents downstream and the test rig has to be re-mobilized to a pile everyone already moved past.

Nothing about that RFI was slow by the contract's definition. The consultant met the deadline. The problem is that the log measured the wrong date.

The log tracks turnaround. The crew needs a need-by date

Open most RFI logs and you'll find a number, a subject, a date sent, a date due (sent plus the contract window), a date answered, and a status. That's a document-tracking log. It tells you whether the consultant is late. It tells you nothing about whether you are.

The date that matters on site is the day the answer stops being useful. Take the affected activity from the schedule, subtract the time you need to act on the answer (order material, cut steel, re-sequence the crew, get a shop drawing back), and that's the need-by date. On a lot of civil work it lands well inside the contract window, sometimes before the RFI is even written.

So the first change is a column: need-by date, next to the activity it gates. The second change is that the log is sorted by that column, not by RFI number. An RFI that is three days from its need-by date and five days from its contract due date is the one that gets the phone call, and the number-sorted log hides it at the bottom of the page.

The need-by date isn't a guess. It comes straight out of the three-week look-ahead. If the look-ahead screens each activity for its constraints, every unanswered RFI on that list is a constraint with a date attached. Run the two documents together and the RFI log stops being paperwork and starts being part of the schedule.

Write the RFI so it can be answered in one pass

A lot of slow RFIs are slow because they came back as a question. The consultant reads it, can't tell what's being asked, and sends a clarification request. That round trip costs a week.

The shape that gets answered fast has four parts:

• The conflict, with references. Drawing number, detail, spec section, and what they disagree about or fail to cover. "Detail 4 on S-201 shows a 300 mm cap; the schedule on S-001 calls for 350 mm at grid C" is answerable. "Please confirm cap thickness" is not.
• One question. If there are three questions, that's three RFIs. A bundled RFI waits for its slowest question, and the two easy ones sit answered-but-unissued for a week while someone chases the hard one.
• A proposed answer. "We propose to drive to refusal and confirm capacity by PDA on one pile per bent." This turns the consultant's job from designing to approving. It also puts your preferred method on the record, which matters later.
• The consequence of no answer by the need-by date. Plainly, not as a threat. "Pile crew reaches bent 7 on the 14th; without direction we will stand down or skip, both of which carry cost." Consultants prioritize their inbox like everyone else, and a stated consequence moves an RFI up the pile.

Attach the sketch or the photo. A marked-up plan view answers half the questions the text would otherwise raise.

Triage before anything goes on the log

Not every question the field asks belongs on the RFI log. I sort them into three piles.

First, questions the documents already answer. A lot of RFIs are somebody not having read the spec section, and sending them to the consultant is expensive in credibility. Whoever writes RFIs should have the drawing set and the spec open and should check first.

Second, genuine gaps and conflicts. The documents are silent, ambiguous, or contradict each other, and only the consultant can say what was intended. These are RFIs.

Third, questions whose answer will change the work. A hidden utility, an obstruction, a site condition that doesn't match the geotech. You still write the RFI, but you flag it on the log as potential change the day it goes out, because the response is likely to trigger the notice provisions in your contract, and those clocks don't wait for the RFI to be answered. When the answer lands and it does change scope, the item moves to the change log with a date trail already behind it. Keep the two logs separate, but make the handoff explicit. An RFI is a question, not a change order, and treating a changed answer as if it were approved extra work is how contractors end up doing that work for free.

Run the log weekly, from the schedule side

The RFI review shouldn't be a scroll through open items at the end of the coordination meeting. It should be a filter: every open RFI with a need-by date inside the next three weeks, sorted soonest first. That's usually a short list, and it's the whole conversation.

For each one, three questions. Is the consultant aware of the need-by date, or only the contract due date? Has anyone spoken to them, or only emailed? And if the answer doesn't arrive, what does the crew do instead?

The escalation ladder is short and it starts early. A reminder a few days before need-by, to the person who will actually write the answer, not the general inbox. A phone call when it's inside a week. The owner's representative when it's inside a few days, because the owner is the one paying for the standby and usually the one who can get a consultant's attention. None of that is adversarial if the need-by date was on the RFI when it went out.

Close the loop on site, not in the log

"Answered" is not the end of an RFI. The answer has to reach the crew that asked, in a form they'll use: a marked-up drawing in the site set, a revised IFC sheet, a note at the morning tailgate. I've seen answers sit in an email thread for a week while the crew built from the old detail because nobody told the foreman the question had come back.

Two more columns pay for themselves here: issued to field (date, and how) and incorporated (what was done with it). If the answer was partial, or answered a different question, close the RFI and open a new one that asks the remaining piece.

And there will be a later. On any project that ends in a delay discussion, the RFI log is one of the first documents both sides pull. A log that shows the question, the proposed answer, the need-by date, the reminder, the escalation, and the date the field got the answer tells a clean story. A log that shows a number and two dates tells nothing at all, and the gap gets filled by whoever has the better memory.

Spreadsheet or software

Everything above fits in a spreadsheet with eight or nine columns. The project management platforms do RFIs well, and what you're buying is the audit trail, the automatic reminders, and the consultant seeing the same log you do instead of a PDF attachment. Those are real gains on a job with a hundred RFIs, but they won't fix a log with no need-by date, because the software won't invent one for you. Sort out what the log is for first.

If your RFI log is a list of numbers that gets scrolled through on Thursdays, and the answers keep landing after the crew has moved on, that's the kind of thing I look at in a Manara discovery call: which documents run the job, where the dates on them come from, and what a week of your coordinator's time is actually buying. Usually the fix is a few columns and a habit, not a platform.