An RFI is a request for a decision, and the quality of the answer depends almost entirely on how the question was asked. A vague RFI produces a vague response, or an answer to a different question, or two weeks of silence followed by a request to clarify the clarification. Meanwhile the drawing waits and the programme does not.
An RFI that asks "please advise" invites deliberation. An RFI that states the reading of the specification, describes the drawn condition, proposes an interpretation and confirms that detailing has proceeded on that basis invites a yes.
That is not a presentation trick. It is the difference between asking a design team to solve a problem and asking them to approve a solution. The second is faster, and it produces fewer follow-on questions.
The judgement of what to propose comes from specification analysis and constructability review, which is why all three sit under the same service line rather than being sold separately.
Raising an unnecessary RFI costs credibility with the design team, and credibility is what makes the necessary ones move quickly.
Questions answerable from the specification are answered from the specification. Questions that are a shop decision are returned to you as a decision, not forwarded to the architect. Questions that dissolve once the full set is read are not asked at all.
The count and the recurring themes are reported back to you. On a badly documented project that report is often the most useful thing in the package.
Shops working from incomplete design documentation, which is most shops. Project managers tracking open questions across several packages at once. Contractors whose millwork RFIs are stalling procurement.
Selected work
The quality of the answer depends almost entirely on how the question is asked.
Answers
Send a package where the documentation is incomplete
Connect with us!
Let's Talk
"*" indicates required fields