What a Good RFI Process Actually Looks Like in Construction

The site engineer is standing over the structural drawings on a Tuesday morning. The penetration shown for the main services run clashes with a beam that is about to be poured. He needs an answer from the engineer before the formwork goes up, and he needs it today. So he raises a request for information, drops it into an email to the design team, copies the project manager, and gets on with the rest of his morning.

Three weeks later, that email is still sitting in someone's inbox. The beam was poured. The services now have to be re-routed, the trade has been back on site twice, and nobody can quite agree whose fault it is. This is the construction RFI process working exactly as it usually does, which is to say, not working at all.

The RFI is not the problem. The process around it is.

A request for information is one of the most ordinary things on a construction project. A detail is unclear, a drawing conflicts with another, a specification leaves a gap. Someone asks the question, someone answers it, the work proceeds. On a healthy project this happens hundreds of times without incident.

The villain is not the question. It is what happens to the question after it is asked. The RFI leaves the site as an email, joins a thread that grows by the day, and quietly loses its place in the queue. Nobody owns it. Nobody can see its status. There is no due date that anyone is accountable to. By the time it surfaces, the window to answer it cheaply has closed.

This is a document control failure, not a competence failure. The information exists. The people who can answer the question exist. What is missing is the system that connects the two before the concrete is poured.

796 RFIs

The average number of RFIs raised on a single major construction project, with a median response time of 9.7 days and a typical processing cost of around US$1,080 each. Navigant Construction Forum, Impact & Control of RFIs on Construction Projects (2013)

Why RFIs stall

The scale is the first thing most teams underestimate. The Navigant Construction Forum studied more than 1,300 projects worldwide, containing over a million RFIs, and found an average of 796 RFIs per project, or roughly 9.9 RFIs for every million dollars of construction cost. On a $30 million Australian commercial build, that is several hundred separate questions, each one needing to reach the right person and come back with an answer.

When that volume is managed through email and a spreadsheet register that someone updates when they remember, things fall through the cracks by design. The same study found a median response time of 9.7 days, and that roughly one in five RFIs in the data set received no formal response at all. An RFI that is never answered does not disappear. The work still has to happen, so someone on site makes an assumption and keeps going.

The deeper issue is that an email-based RFI has no owner and no clock. A question raised by a subcontractor sits between the builder and the consultant with no agreed turnaround. The same coordination gap that drives subcontractor management failures shows up here: when accountability lives in an inbox, it belongs to nobody. The RFI is urgent to the person who raised it and invisible to everyone else.

Fragmentation makes this worse. A typical Australian project might run correspondence across email, a shared drive, a scheduling tool, and a separate register that the contract administrator updates by hand. Each tool holds part of the picture and none holds all of it. An RFI raised against the wrong drawing revision, or answered by someone who could not see the latest markup, creates a second problem on top of the first. The question gets answered, but against information that has already moved on.

What a slow RFI actually costs

A late answer is not a neutral event. It forces a decision. Either the site waits, which costs programme time, or the site proceeds on an assumption, which often costs rework.

Both outcomes are expensive, and the expense compounds with time. An RFI answered in week two changes a line on a drawing. The same RFI answered in week six changes a beam that has already been poured. The clash in our opening scene started as a five-minute conversation between two engineers. Left to sit, it became a re-route, a return visit, and a dispute over who carries the cost.

Rework is where this lands financially. Australian research by Love and Edwards, surveying construction professionals across completed projects, found the mean direct cost of rework was around 6.4% of contract value, with indirect costs adding several percent more. Not all of that traces to RFIs, but a meaningful share of avoidable rework begins with a question that was asked in time and answered too late.

6.4% of contract value

The mean direct cost of rework on Australian construction projects, before indirect costs are counted. A slow or unanswered RFI is one of the quiet ways rework gets started. Love & Edwards, Calculating Total Rework Costs in Australian Construction Projects

There is a schedule cost too. A single unanswered RFI on the critical path behaves exactly like a hold-point delay. As our post on why construction schedules fail sets out, a short slip mid-sequence pushes every following trade by more than the original delay, because the recovery window is narrow and the trades have moved on. The RFI that sat for three weeks did not just lose three weeks. It lost the sequence.

What a good RFI process looks like

The teams that manage construction information requests well are not asking fewer questions. They are running every question through a process that makes it visible, owned, and time-bound from the moment it is raised.

A good RFI process has a few non-negotiable traits. Every RFI is logged the moment it is created, not retyped into a register later. Every RFI has a single owner and an agreed due date, so the clock is visible to everyone, not just the person waiting. Status is live, so the project manager can see at a glance which questions are open, which are overdue, and which are sitting on the critical path. And every RFI is linked to the drawing, the trade package, and the cost code it affects, so the answer lands where the work is.

When the process works, the change is concrete:

• The clash is flagged, answered, and closed before the beam is poured, not after.

• Every open RFI is visible on one register, with an owner and a due date attached.

• Overdue questions surface automatically, instead of being remembered by the person they hurt.

• An RFI that turns into a variation carries its full history into the variation workflow, so the commercial conversation starts with a record, not an argument.

• The audit trail for an extension of time claim builds itself, because the delay was logged when it happened.

• Nobody spends Monday morning reconstructing who asked what, and when.

The Australian context

This matters more in the current market than it did a few years ago. QBE's 2024 Australian Construction Sector Outlook found that 74% of Australian builders experienced project delays in the preceding year. On margins that are already thin, a programme slip caused by a stalled RFI is not a paperwork problem. It is a profit problem, and it connects directly to the pressure on construction margins that Australian builders are feeling across the board.

Documentation is also a contractual safeguard. Extension of time claims under AS 4000 and similar contract conditions depend on a contemporaneous record of the delay cause and its programme impact. An RFI register that captures when a question was raised, when it was answered, and what it held up is not just an administrative nicety. It is the evidence that protects the claim.

When a dispute does arise, the side with the better record usually prevails. A reconstructed timeline, assembled months later from scattered emails, rarely holds up against a register that logged each event as it happened. A disciplined RFI process is, in the end, the cheapest insurance a builder can hold against a contractual fight nobody wanted.

Where Plexa fits

Plexa's Correspondence module turns the RFI from an email into a tracked item with a name, a clock, and a place in the project record. Every RFI, submittal, and design issue is logged in a live register the moment it is raised, with sender, recipient, due date, status, and attachments captured automatically.

Because the register sits inside the same platform as Document Control, each RFI links straight to the drawing or specification it questions, and the latest revision is always the one in view. When an answer changes scope, the RFI flows into a variation workflow with its history intact. When it affects the programme, it is visible against the milestone it threatens, not buried in a thread.

Return to that Tuesday morning. The site engineer raises the RFI, and it lands in a register with an owner and a due date, not an inbox. The design team sees it the same day. The clash is resolved before the formwork goes up. The beam is poured once, correctly, and the question that could have cost three weeks costs an afternoon.

That is the difference a real RFI management construction process makes. The question still gets asked. It just no longer gets lost.