RFI handling and response The question decides the answer.
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.
What the work covers
- Identifying what genuinely needs an RFI
- Not every gap does. Some are answerable from the specification, some are a shop decision, and some stop being ambiguous once the drawings are read properly.
- Writing the question so it can be answered once
- State the condition, cite the drawing and specification references, describe the conflict precisely, and propose an option where a proposal is appropriate.
- Including what the reviewer needs in order to decide
- Usually a sketch or an extract, because a written description of a geometric problem rarely lands.
- Tracking to closure
- Open items logged and dated, chased on your instruction.
- Feeding the answer back
- Into the drawings and into the affected schedules, take-offs and production data, so the response does not sit in an inbox while the set stays wrong.
Why a proposed answer changes the response time
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.
Where RFIs actually come from
- Conditions with no detail at all
- Details that conflict between drawings, or between a drawing and a reflected ceiling plan
- Specification clauses that contradict the drawn design or the finish schedule
- Specified products that are unavailable, discontinued or unsuitable for the condition
- Dimensional impossibilities, most often where millwork meets structure or services
- Junctions with other trades where responsibility for the tolerance is unstated
What does not need an RFI
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.
Who this suits
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
RFIs, written to get an answer once
The quality of the answer depends almost entirely on how the question is asked.
FAQ
Frequently Asked Questions
Do you issue RFIs directly to the architect?
No. RFIs are prepared for you to issue through your own contractual route, because the contractual relationship is yours. What you receive is a question ready to send.
How many RFIs is normal on a package?
It varies enormously with the completeness of the design documentation rather than with the size of the package. We report the count and the themes back to you.
Can you handle RFIs on drawings we produced ourselves?
Yes, though the first round takes longer because the set has to be understood before it can be questioned. This is a common way accounts begin.
What if the answer never comes?
Open items are logged and dated and chased on your instruction. Where an answer is blocking production, we say so in writing rather than letting it sit.
Send a package where the documentation is incomplete
What comes back is the list of questions worth asking, and the ones that are not.
- Questions written to state a reading and propose an interpretation
- Open items logged, chased on instruction, and dated
- Answers fed back into the drawings and affected schedules
- One named contact, not a general queue
