The request for information (RFI) also known as requests for clarifications (RFC) and requests for interpretation (RFI) is the communication process that will always exist on construction projects regardless of where they are located, size or type. An RFI is usually initiated by the contractor, asking for an interpretation of an item in contract documents that could be for work that was not sufficiently described or reasonably inferable from contract documents or for a changed or unforeseen site condition. On the other hand, RFIs should not be used for requesting information readily found in the contract documents.
The project control team needs to report on the status of the requests for information submitted on the project and in particulate those that are pending a decision by the Engineer so they can be closed. In addition, the project control team needs to categorize the submitted RFIs by the reason for their submission. Those could be for example incomplete contract documents, inconsistency or conflict between more parts of contract documents, an insufficient amount of detail to determine design intent, the inability of the contractor to provide a specified product or system, unknown conditions encountered like hazardous materials, unforeseen subsurface soil conditions different from those in the geotechnical report, changed existing conditions beyond contractor’s control or concealed conditions different from conditions anticipated by contract documents.
This will also help the project control team if the volume of submitted RFIs was excessive or not. Projects with excessive RFIs may be an indication of incomplete contract documents where the Contractor has to make many RFIs to obtain the necessary information to construct the project, incomplete study and comparison of contract documents: where the contractor uses RFIs to ask questions rather than study documents, ineffective use of project meetings to resolve issues that could be addressed in meetings and instead use RFIs to address and resolve those, and of course they can be used by the contractor as the ground for issuing change orders and request extension of times.
The PMWeb out-of-the-box ready-to-use RFI module allows the project team member to capture all details needed to manage the RFI. The default form has fields for Project, Stage (Design, Tender, Construction), WBS Level, RFI Reference ID, RFI Subject or Description, Status, Revision, Revision Date, RFI Date, Trade (Substructure, Superstructure, etc.), CSI Specification Section, Category (Structural, Mechanical, or Electrical, etc.) and Priority (High, Normal, or Low). There are no limits to the additional custom fields that may be added as attributes to the RFI using the specification section.
In addition, each RFI must have fields for the query or clarification, the proposed solution by the issuer or other, and the response to close the RFI. If the RFI response impacts the project’s SoW, cost, or schedule, this must be highlighted. The project schedule activity that this RFI response could impact needs to be provided for the schedule. In addition, if the RFI is related to other project management processes, the relevant documents must be linked to the RFI so as to provide those involved in responding to the RFI with complete details on the RFI.
The Request for Information should have all drawings, specification sections, contract agreements, BoQ, pictures, videos, and all other supporting documents attached to the RFI submission. Although these can be uploaded directly into the RFI, it is recommended that all these documents be first uploaded to the PMWeb document management repository and then attached to the RFI. In addition, PMWeb links project-related emails imported to PMWeb to the relevant RFI. Further, hyperlinks to external websites like those for seismic activities, and building codes, among others, can be added.
The PMWeb Workflow will detail the different roles involved in submitting, reviewing, and responding to RFIs. What is essential in the PMWeb workflow is that all possible workflow scenarios can be mapped using the conditional workflow rules and branches. These rules could be specific to the RFI category, CSI specification section, location, WBS level, reason, impact on scope, cost, and schedule, among other RFI attributes or fields. This will ensure that the RFI is properly distributed and circulated.
The wealth of knowledge that the PCS team can have from capturing the RFIs’ BIG DATA in a trustworthy format can be of great value to them. Since PMWeb is designed to capture data from an unlimited number of projects, whether active or completed, the PCS team can utilize this data to analyze and identify trends in RFI growth patterns.
In addition, there is an option to visualize RFIs using BIM to improve the visualization of the project elements associated with submitted RFIs. For example, associating the BIM model with the RFI process data captured in PMWeb enables stakeholders to monitor, assess, report, and visualize the RFIs associated with each building system. These could be structural, MEP, or architectural systems.
For each BIM Model discipline, there is a separate RFI report. This makes the BIM model less congested and enables individuals to access the RFIs specific to the discipline they are responsible for (for example, structural, MEP, and architectural). These reports include a table of all received RFIs, with their complete details, such as subject, who it was received from, when received, the query and its answer, when the response was sent, and days withheld, among others. The report also includes three donut visuals to summarize the RFIs by Status, Reason, and whether the response to the RFI is out of the project’s SoW or not.