What Is a Request for Information (RFI)?

RFIs turn up at two distinct stages of a project, and the process works slightly differently at each.

During tendering, a bidder raises an RFI to clarify something needed to price the job accurately — an ambiguous specification, a missing drawing, or a discrepancy between the architectural and structural sets. Because fairness between competing tenderers matters, the answer to a pre-tender RFI is almost always issued to every bidder as a formal addendum, not privately to the contractor who asked. During construction, RFIs shift to site-level detail — a dimension not shown, a service clashing with structure, a finish not specified, or confirmation of how two trades interface at a junction.

• Pre-tender RFIs — raised during the tender period, answered to all bidders via an addendum to keep the process fair and pricing consistent.
• Design clarification RFIs — resolving an ambiguity, omission or conflict between drawings, specifications or schedules.
• Coordination RFIs — resolving a clash between trades or services discovered once construction is under way.
• Substitution RFIs — proposing or confirming an alternative product or method where the specified item is unavailable or impractical.

A clear RFI gets a faster, more useful answer, and it is easier to rely on later if a dispute arises about what was actually agreed. At minimum, an RFI should be numbered, dated and precise enough that anyone reading it later, including someone who wasn’t involved in the original conversation, understands exactly what was asked and why.

Most RFI processes run through a register or log, whether that is a dedicated field, a spreadsheet, or a construction management platform, so every question, response and outstanding item is visible in one place rather than scattered across emails.

A typical RFI follows the same broad sequence whether it’s raised on a small residential job or a major commercial contract, though the timeframes and formality scale with the size of the project.

• The contractor identifies a gap, ambiguity or clash and drafts a numbered RFI referencing the specific drawing or specification clause.
• The RFI is logged in the register and submitted to the relevant party — architect, engineer, superintendent or client’s representative.
• The recipient reviews the query and issues a written response by the requested date, or proposes a later date if genuine investigation is needed.
• The response is logged against the RFI, and if it changes the scope, cost or program, the relevant variation or extension of time process is triggered separately.
• The RFI is closed out once the answer has been actioned, keeping the register as a running record of every open and resolved query.

The real risk in an RFI is rarely the question itself — it is the time spent waiting for the answer. If a trade genuinely cannot proceed until a query is resolved, and the response is late, that delay can sit on the critical path of the program just as surely as any other hold-up, and it is one of the more common grounds for an extension of time claim.

Equally, the answer to an RFI can itself reveal extra cost — a substitution that costs more than the specified product, or a coordination fix that adds work. When that happens, the RFI response becomes the supporting evidence for a variation, but the variation itself is a separate, priced and approved document; the RFI record simply shows where the change came from and why.

An RFI is typically raised by whoever is closest to the gap in information — an estimator pricing a tender, or a site manager or foreman who has hit a genuine ambiguity on site — and lodged through whoever administers the contract, whether that is a project manager, a superintendent or the builder’s own document control process.

The response comes from whoever actually holds the answer: the architect for a design intent question, the structural or services engineer for an engineering clash, or the client directly for a decision only they can make, such as a product selection. On larger projects, a superintendent or contract administrator often coordinates the RFI process so nothing gets answered informally or falls through the cracks.

RFIs are easy to confuse with the documents that often follow them, but each serves a distinct purpose:

• RFI vs variation — an RFI asks a question to clarify the existing scope; a variation is a priced, approved change to that scope, which may be triggered by an RFI’s answer but is a separate document.
• RFI vs site instruction — a site instruction directs the contractor to do something specific, often issued by the superintendent; an RFI is the contractor asking a question, which may or may not lead to an instruction.
• RFI vs addendum — an addendum formally amends the tender documents before contracts are signed, often issued in response to one or more pre-tender RFIs so every bidder prices the same updated scope.

Most RFI-related disputes trace back to a handful of avoidable habits rather than genuinely difficult questions.

• Raising a vague RFI that doesn’t reference a specific drawing or clause, which slows down the response and can produce an equally vague answer.
• Proceeding on an assumption instead of waiting for the answer, then trying to claim a variation after the work is already done.
• Not logging RFIs in a register, so there is no clear record of what was asked, when, and how long the answer actually took.
• Failing to link a late RFI response to a formal extension of time claim, leaving a genuine delay unclaimed.
• Treating every RFI response as automatically approved extra scope, when a genuine variation still needs to be priced and agreed separately.