The RFI Process in Construction: How to Raise, Track and Close a Request for Information

Short answer: An RFI is a written question that creates a dated record of what you needed to know, when you asked, and what you were told. Raise it early, make it answerable in one reply, link it to the drawing and the programme activity it affects, and close it with the answer attached. The register is the asset, not the individual question.

What an RFI is actually for

On a well-run job, an RFI does three jobs at once.

It gets you an answer. The obvious one, and the reason people raise them.

It creates a dated record. Six months later, the question of who knew what and when will be argued from the RFI register rather than from anybody's memory of a site meeting.

It transfers the question formally. An informal question to a design team member is advice. An RFI is a request that the contract expects to be answered, within a period, by someone with authority to answer it.

The third point is why "I asked him on site and he said it'd be fine" is worth nothing when the detail turns out not to be fine. The answer was never captured, was possibly given by someone who could not give it, and started no clock.

When to raise one

Raise an RFI when any of these are true:

• The drawings, specification or schedules conflict with each other.
• Information needed to build is missing — a dimension, a specification, a setting-out point, a fixing detail.
• What is drawn cannot be built as shown, or cannot be built to the tolerance required.
• Site conditions differ from the assumed conditions.
• A decision is required from the client that has not been made — a colour, a fitting, a location.

Do not raise an RFI to ask for something the contract already gives you, to chase a variation instruction, or to record an opinion. Registers full of rhetorical RFIs get ignored, which reduces the answer rate on the ones that matter.

Writing an RFI that gets answered first time

The response time on an RFI is mostly determined by how much work the recipient has to do before they can answer. A vague question travels around a design team for a week; a precise one is answered by the person who opens it.

A good RFI contains:

A reference and a date. Sequential, per project.

A one-line subject that identifies the issue without opening the body: "Blockwork lintel bearing at Grid C/4 — conflict between S-201 rev C and A-114 rev E."

The precise location. Grid reference, room number, level, drawing number and revision, and the detail number. Attach the drawing with the area marked.

A statement of the conflict or gap — what each document says, quoted.

The question, answerable as written. "Please confirm the lintel bearing to be used" beats "please clarify."

Your proposal. This is the highest-leverage part of the whole document and the most commonly omitted. Offering the answer you believe is right converts a design exercise into a yes/no. Most answers come back as "proceed as proposed."

The impact if unanswered — the activity affected, its planned start, and the date after which the answer is too late to avoid disruption.

The required response date, consistent with the agreed period.

Item 7 does two things: it tells the recipient which questions to answer first, and it builds the delay record contemporaneously rather than retrospectively.

The register is the point

Individual RFIs are useful. The register is what protects the job.

A functioning register tracks, for every question: reference, date raised, who raised it, subject, drawing and revision affected, activity affected, required response date, actual response date, the answer, and whether the answer generated a variation.

That last column is the one that converts contract administration into commercial recovery. An RFI whose answer changed the works is a variation waiting to be valued, and jobs routinely lose money because the answer was implemented on site and never priced.

Two derived numbers are worth reviewing weekly:

• Open RFIs past their response date, sorted by the start date of the activity they block. This is the list you take to the progress meeting.
• Average response time by responder. Not to start a fight, but because a design team consistently running at three weeks against an agreed five days is a programme risk that needs raising while it can still be fixed.

How RFIs turn into delay claims

The chain that makes an unanswered RFI compensable looks like this:

The information was necessary to carry out a specific activity.

It was requested in time, allowing the agreed response period before the activity's planned start.

The request was clear enough to answer.

The response was late, or absent.

The activity was actually delayed as a result, and that activity affected completion.

Every link has to hold. In practice claims fail at links 1 and 5 — the RFI was real but nobody can show which activity it blocked, or the activity was not on the critical path and the delay absorbed float.

This is why linking the RFI to the programme activity when you raise it is worth the thirty seconds. Reconstructing that link a year later, from a register that records only "drawings", is a forensic exercise with an uncertain outcome.

Common failure modes

The RFI raised too late. Sent the week the activity starts, leaving no room for the agreed response period. The record then shows the contractor created the urgency.

The compound RFI. Six unrelated questions in one document. It is answered when the slowest of the six is resolved, and partially answered forever.

The RFI answered on site, verbally. The work proceeds, the register still shows it open, and nobody can say what was agreed. Close the loop in writing, even when the answer arrived in a conversation.

The register that lives in one person's spreadsheet. When they are on leave, nobody knows what is outstanding. When they leave the company, the register leaves with them.

No link to the drawing revision. The answer is given against rev C, rev E supersedes it, and nobody checks whether the answer still applies. Recording the revision at the point of raising is what makes that check possible.

Making it survive contact with a site

The reason RFI registers rot is that they are maintained in the office by someone who did not encounter the problem. The person who found the conflict is a site manager standing in front of a wall that will not build.

What works is raising the RFI where the problem is: from the job, against the drawing, with the photograph attached, and with the affected activity picked from the programme rather than typed as free text. Everything after that — the register, the response times, the link to a variation — assembles itself from records that were correct at the moment they were created.

ScopeKit works this way: an RFI is raised from the job, linked to the drawing it concerns, and tracked with a full audit through to the answer, with an RFI tab on every project so the register is the same object everybody is looking at.

Related reading

• Taking off quantities from PDF drawings — checking revisions before they become RFIs.
• Dayworks explained — pricing the work an RFI answer creates.
• Cost value reconciliation explained — where unvalued variations show up as lost margin.