RFI (Request for Information)

An RFI — a Request for Information — lands in your inbox as a head contractor's question about the drawings, the specification or the contract itself. As the client-side project manager or developer receiving it, you are not expected to answer every one yourself. Your job is to recognise what the query actually needs, route it to the right consultant, and make sure the answer goes back formally and on time. Ignore that discipline and an RFI stops being a request for information and starts being evidence of a delay you didn't manage.

This is general information, not legal, tax or financial advice.

What is an RFI in construction, and what does RFI stand for?

RFI stands for Request for Information. It is a formal written query the head contractor raises during construction, asking the client side to clarify something the design, the specification or the contract documents do not make clear enough to build from. An RFI is not a casual email or a phone call — it is logged, numbered and answered in writing so both sides have a record of what was asked and what was decided.

The trigger is always a gap between what is on paper and what the site actually needs to proceed. A drawing that shows two different floor levels. A specification that references a product that has been discontinued. A structural detail that clashes with the services drawing. The head contractor cannot guess and keep building — they stop, raise the RFI, and wait for you or your consultant to close the gap.

What typically triggers an RFI on a project?

Most RFIs fall into a handful of predictable categories. Design conflicts, where two consultants' drawings contradict each other — the architect shows a window, the structural engineer shows a shear wall in the same spot. Missing information, where a detail simply hasn't been issued yet, often on a fast-tracked programme where documentation trails construction. Site conditions that don't match the documents, such as an existing service in a location the survey didn't record. And genuine ambiguity, where the wording of the scope of works or specification can honestly be read two ways.

None of these are the head contractor's fault, and none are automatically yours either. The RFI's job is to establish which party's document caused the gap, before anyone talks about cost or time.

What should a good RFI contain?

A properly drafted RFI states the precise issue, references the drawing or specification clause it relates to, and — critically — proposes what the contractor believes the answer should be. That last part matters more than most client-side teams realise. An RFI that simply says "please advise" gives the consultant nothing to react to and invites a slow, vague reply. An RFI that says "we believe the correct detail is X, please confirm or direct otherwise" gives the consultant a yes or no decision, which is a much faster thing to answer.

A good RFI also states the date a response is needed by, tied to an actual construction activity that will stop or continue depending on the answer. Without that date, every RFI looks equally urgent, and none of them are.

Who receives an RFI on the client side, and what happens next?

On most projects the RFI arrives at the superintendent or the client-side project manager, not directly at the consultant who can actually answer it. Your role is triage, not authorship. You read the query, work out whether it belongs with the architect, the structural engineer, the services consultant or the principal directly, and forward it with enough context that the consultant doesn't have to re-read the whole drawing set to understand what's being asked.

This is also where a developer running several projects at once starts to feel the pain of a manual process. An RFI sitting in a shared inbox, forwarded by email, is easy to lose between the head contractor, the superintendent and three separate consultants. The volume is rarely large on any single day — the risk is that a handful of the ones that do arrive get buried.

Who is allowed to answer and close an RFI?

The consultant whose document raised the ambiguity is usually the only party qualified to answer it — the architect answers a drawing query, the structural engineer answers a structural query, and so on. But answering is not the same as closing. A well-run RFI process keeps those two actions separate: the consultant who wrote the response should not also be the one who marks the RFI closed, because that removes the client side's chance to check the answer actually resolves what the head contractor asked before it becomes the basis for construction.

Where a project is administered under general conditions such as AS 4000-1997 or AS 2124-1992 — both published by Standards Australia — formal correspondence of this kind normally passes through the superintendent, who administers the contract on the principal's behalf. Exactly how your project handles RFIs, who signs off and what evidence is required, is set by your own contract, not by a general rule.

How long should an answer take, and what happens if it is late?

There is no industry-standard number of days for an RFI response — it's whatever your contract specifies, and it's worth checking that figure before the project starts rather than during a dispute. What matters more than the exact timeframe is that everyone treats it as binding. If the head contractor genuinely cannot proceed with a work sequence until the RFI is answered, a late response can support a claim for additional time or cost, in the same way a late instruction can.

That's why the date-needed-by field on the RFI itself matters so much. A contractor who states a real, activity-linked date and doesn't get an answer by then has a stronger case than one who submitted a vague query with no deadline at all. Track that date on your side too — you want to know you're late before the contractor tells you.

How does an RFI differ from a variation, a site instruction and a defect?

These four terms get used loosely on site, but they mean different things and trigger different obligations. An RFI asks a question — it does not, by itself, change the scope, cost or programme of the works. If answering the RFI requires the contractor to do something different from what was originally documented, that answer should trigger a formal variation, priced and approved before the work proceeds, not just folded into the RFI response.

A site instruction is different again — it's a direction, usually issued by the superintendent, telling the contractor to do something, rather than a question the contractor is asking you. And a defect is neither a question nor a direction; it's a finding that completed work doesn't meet the standard required, dealt with separately from both. Confusing an RFI answer with a variation approval is one of the most common ways scope creeps onto a project without anyone formally agreeing to pay for it.

What is an RFI register, and why does it matter in a dispute?

An RFI register is the running log of every RFI raised on the project: who raised it, when, what it asked, who it was routed to, when it was answered, and when it was closed. On its own it looks like housekeeping. In a dispute, it is often the single clearest record of who knew what, and when.

If a head contractor later claims an extension of time because a design gap held up the works, the RFI register — read alongside the site diary — shows exactly how many days passed between the query being raised and the answer landing back on site. A register with gaps, or one that was never really kept, leaves you defending a claim with nothing but memory. A complete one lets you agree or dispute the claim on the actual dates.

Why do RFIs matter for cost and programme, not just paperwork?

It's tempting to treat RFIs as an administrative chore that runs alongside the real work of the project. In practice they sit directly on the critical path. Every day a genuinely blocking RFI goes unanswered is a day the head contractor isn't building the thing it relates to — and on a project running to a fixed completion date, those days accumulate into holding costs the same way any other delay does.

The developers who manage this well don't try to eliminate RFIs; that's not realistic on any project of size. They make sure every RFI has an owner, a due date and a visible status, so a query that's been sitting unanswered for a week shows up before it becomes a programme problem, rather than after.