Writing a good RFI is one of the most underrated skills in commercial construction. Do it well, and you get a clear answer from the architect in a day. Do it poorly, and you get a one-line response that raises more questions than it answers — and you've just burned a week.
After talking to dozens of project managers about their RFI process, the same mistakes come up over and over. Some of them are small. Some of them cost real money. Here are the five biggest ones, and what to do about each.
Mistake 1: Being Too Vague
The most common RFI mistake is also the simplest: not being specific enough. "Please clarify the door hardware requirements" is not an RFI. It's a suggestion that something might be wrong. The architect needs to know exactly where the conflict is, what documents are involved, and what decision you need them to make.
The fix: Every RFI should reference a specific drawing number, a specific section of the spec, and describe the exact conflict in two or three sentences. If you can't do that, you haven't done enough research to write the RFI yet.
Mistake 2: Not Checking Addenda First
Addenda are issued to modify or clarify the original bid documents. They come out during bidding and sometimes after. If an architect already addressed your question in an addendum and you send an RFI asking the same thing, you've just told them you're not paying attention to the project documents.
The fix: Before you write any RFI, search every addendum that's been issued on the project. If it's already been addressed, close the loop with your sub and move on.
Mistake 3: Burying the Question
Some PMs write three paragraphs of background before getting to what they actually need. The architect is reviewing 20 RFIs a week. They don't have time to parse your essay. Front-load the question.
The fix: Put the actual question in the first two sentences. Everything else — the context, the conflict, the references — comes after. Think of it like an executive summary. Lead with the answer you need, then back it up.
Mistake 4: Ignoring the Response Deadline
Most contracts specify a response time for RFIs — usually 7 to 14 days. If you're sending RFIs on Friday at 4pm and you need an answer by Monday, that's not an RFI problem. That's a scheduling problem. But if you're routinely letting RFIs sit unanswered past their contractual deadline without following up, you're leaving leverage on the table.
The fix: Track every RFI you send with a due date. If it's not answered by the deadline, send a single follow-up email referencing the contract clause. Document everything.
Mistake 5: Not Documenting the Impact
An RFI isn't just a question. It's a record. If the answer to your RFI results in a scope change, a schedule delay, or additional cost, that RFI becomes part of your change order documentation. If you didn't write it clearly, if you didn't track the response, if you didn't note the timeline — you just made a future change order fight a lot harder to win.
The fix: Every RFI should include a note about what's at stake if the question isn't answered promptly. Even if it's just "work on [location] cannot proceed until this is resolved." That one sentence turns a question into a record of impact.
The best project managers treat RFIs like legal documents — because in a dispute, they often are. Every word matters.
Writing good RFIs is only half the battle. The other half is finding the information you need to write them in the first place — and that's where most of the time actually goes. If you're spending more than 15 minutes searching specs and drawings before you can even start an RFI, we're building something that might help. Check out buildmind.pro.