A request for information is the formal question a contractor raises when design information is missing, ambiguous or contradictory: which detail governs, what is the finish here, where does this service route, what happens at the junction the drawings never quite reach.
Well-run projects manage RFIs through a numbered log with dates raised, dates needed, dates answered and the answers themselves. The log looks administrative, and that is precisely its power: it is a dated record of when the contractor asked, when the information was needed to keep work moving, and how long the answer actually took.
Late or missing information is a delay event under the standard forms. JCT contracts treat failure to provide information in due time as a Relevant Event and potentially a matter for loss and expense; under NEC, information not provided by the date shown on the Accepted Programme is a compensation event. The RFI log, cross-referenced to the programme, is core evidence for both.
Answers deserve as much attention as questions. An answer that resolves an ambiguity within the existing design costs nothing; an answer that changes the design is a variation in disguise, and it should be captured through the change machinery rather than buried in the log. A surprising amount of unpaid change enters projects this way, one reasonable-looking RFI answer at a time.
The discipline that makes RFIs pay is linkage: each RFI tied to the work fronts it affects, any stand-still or out-of-sequence working recorded on the day, and photographs of the condition that prompted the question. An RFI noting that a gang was relocated while the detail was awaited, backed by a dated photo, is delay evidence. An RFI that just sits in a log is a number.
On most sites the first version of an RFI is a photo and a question in the WhatsApp group; Construction Metric captures and dates that trail automatically: see how it works.