An RFI Is Open. What Is It Really Holding Up?
An open RFI is not just a design query. It may be blocking labour, material release, subcontract scope, inspection or a whole workfront. The real priority should come from operational impact, not age alone.
The short answer
An RFI should be prioritised by what it is stopping, not simply by how long it has been open.
A young RFI can threaten tomorrow’s pour, material release or subcontract mobilisation. An old RFI may relate to an area that will not be built for months.
The most useful RFI register therefore shows operational consequence: which workfront, procurement decision, inspection or commercial issue depends on the answer.
The oldest RFI is not always the most urgent
Age is attractive because it is objective.
An RFI has been open for ten days. Another has been open for twenty-five. It is easy to sort the register and chase the oldest item.
But construction does not experience delay in chronological order.
One query may be sitting harmlessly because the affected work is months away. Another may have been raised yesterday because the site just discovered a clash in the next workfront.
The newer issue can be far more dangerous.
This is why a good RFI process asks one additional question: what is this query preventing the project from doing?
That answer makes the register operational.
Some RFIs block work directly; others block decisions that later block work
The impact of an RFI is not always obvious.
A query about a detail may directly stop installation.
But an RFI can also stop a material approval, a shop drawing, a subcontract scope decision or an inspection.
The workfront may continue today while the real consequence appears two weeks later.
That indirect effect is one reason RFIs can be underestimated.
The project sees “design query”.
Procurement sees “cannot release”.
The subcontractor sees “cannot fabricate”.
The planner eventually sees “activity slips”.
By the time those effects converge, the answer is already late.
The RFI should therefore be linked to the chain of decisions behind the workfront, not treated as a standalone correspondence item.
A good RFI explains the decision the project needs
Poor RFIs often contain too much history and too little decision.
Long descriptions, screenshots and background can obscure the exact point requiring response.
The best RFIs make the decision clear.
What condition has been found?
Why does the current information not resolve it?
What decision or clarification is required?
What work depends on the answer?
That final question is especially valuable.
It gives the responder context and helps the project decide how aggressively to escalate.
The aim is not to make every RFI short. It is to make every RFI useful.
The real RFI backlog is the work at risk, not the number of open queries
A project with fifty open RFIs may be healthier than a project with ten.
The count alone says very little.
What matters is the concentration of impact.
If several open RFIs affect the same workfront, subcontract package or milestone, the project may have a serious information bottleneck even though the total number looks manageable.
This is where the wider workfront-readiness view becomes valuable.
The project can see whether the next two weeks of work are genuinely supported by complete information, rather than relying on a global RFI count.
That is a much stronger management signal.
Escalation should follow programme consequence
Not every RFI deserves senior attention.
Escalation becomes useful when the consequence exceeds the normal review process.
If an answer is beginning to affect a critical workfront, major procurement release or contractual milestone, the project should elevate the issue with that consequence clearly stated.
This creates a better conversation than simply saying the RFI is overdue.
“Overdue by five days” is administrative.
“Blocking fabrication needed for the 20 October installation” is operational.
The second statement gives management something to act on.
Closing the RFI is not the end if the answer changes the work
A response can close the query while opening several new actions.
The answer may change a drawing, material, subcontract scope, programme sequence or cost.
If the project treats the RFI as complete the moment the response arrives, those downstream consequences can be missed.
The closure should therefore ask whether another project record needs to change.
Does the drawing require revision?
Does procurement need new information?
Does the subcontractor need a formal instruction?
Does the programme need resequencing?
The RFI closes only when the project has absorbed the answer, not when the reply is received.
The same discipline can improve design-team relationships. Designers are more likely to respond constructively when the contractor explains the real decision and programme consequence rather than simply escalating a long list of overdue queries.
That turns the RFI register from a blame mechanism into a production-control tool.
The quality of prioritisation becomes especially important when a project has more open RFIs than the design team can answer immediately.
At that point, every request for “urgent response” is meaningless.
The contractor needs to distinguish the queries that protect production from those that can wait without consequence. That requires planning and site teams to contribute context, not just document control.
A useful RFI priority can change over time too.
A query raised six weeks before the work may initially be low risk. If it remains open and the workfront enters the two-week lookahead, the same RFI becomes much more important.
Priority should therefore follow proximity and consequence, not be fixed on the day the query is raised.
There is a commercial side as well. An unanswered RFI may force the contractor to choose between waiting and proceeding on an assumption. Both choices can create cost.
Waiting may cause idle resources or delay. Proceeding may create rework if the assumption proves wrong.
When that decision point is visible, management can make a conscious choice rather than allowing the site to absorb the risk informally.
This also improves the record. If the project later needs to explain why a sequence changed or why additional cost arose, it can show the unanswered decision and the operational consequence at the time.
The RFI process then becomes more than technical correspondence. It becomes part of the evidence chain connecting design uncertainty to programme and cost.
That is why the best RFI dashboards are often simpler than the biggest ones. They show the few questions that matter now, what each one is holding up and the latest practical date for an answer.
There is also a behavioural benefit when the project stops rewarding quantity.
Teams sometimes raise RFIs defensively because creating a formal query feels safer than making a decision. That can flood the process with low-value questions and make genuinely critical issues harder to see.
A consequence-based review encourages better judgement.
Could the issue be resolved through existing information? Does it genuinely require design clarification? What happens if the answer waits?
Those questions can reduce unnecessary traffic without discouraging legitimate technical concerns.
The goal is not fewer RFIs for the sake of a metric. It is a cleaner signal between site uncertainty and the decisions only the design or client team can provide.
When that signal is strong, both sides spend more time resolving the questions that actually protect the work.
The project should also learn from repeated RFI themes.
If the same interface, dimension or specification issue appears across several areas, the problem may not be a series of isolated questions. It may point to an incomplete design assumption or coordination gap.
Recognising that pattern early can prevent the project from raising the same question multiple times and discovering the same answer one workfront at a time.
That is a more mature use of RFI data: not simply tracking responses, but identifying where design uncertainty is recurring and addressing the underlying cause.
Where Epicor Saturn fits in RFI impact control
Epicor provides the enterprise-grade ERP foundation for approvals, purchasing, finance and governance. Epicor Saturn adds the construction and engineering project context that links design questions to workfronts, subcontract packages, procurement and project cost.
That connection matters because an RFI is rarely just a document. It can affect multiple project decisions at once.
Epicor Saturn provides the industry layer that helps keep those effects connected while Epicor supplies the enterprise-grade transactional backbone. Explore Epicor Saturn for construction and engineering.
Frequently asked questions
Should RFIs always be prioritised by age?
No. Age matters, but operational impact should drive urgency.
What is the best way to show RFI impact?
Link the query to the workfront, procurement decision, inspection or package that depends on the answer.
Does an RFI end when a response is received?
Not always. The answer may require drawing, programme, procurement or commercial updates.
Why can a small RFI create a large delay?
Because one unresolved detail can sit on the critical path of a much larger workfront.