Rarely an engineering and construction project is ever delivered that did not have Request for Information (RFI) issued by the contractor, subcontractor or suppliers who are responsible for delivering the project. The RFI is a project communication management process that is used to request for the interpretation of work not sufficiently described or reasonably inferable from the contract documents including drawings and specifications. In addition, RFI is also used for changed or unforeseen site conditions. Nevertheless, RFI should not be used for requesting information readily found in the contract documents.
RFI are usually are the result of incomplete contract documents, inconsistency or conflict between more parts of contract documents, insufficient amount of detail to determine design intent, inability for contractor to provide specified product or system, unforeseen site conditions encountered among others.
What Data Should a RFI Have?
The RFI document templates should be designed to capture the needed data to be able to close it without affecting the project scope, schedule or cost. The RFI should provide details on who is issuing the RFI, which project, RFI reference ID, when it was issued, which WBS level of the project scope does it relate to, which specification section it relates to, work category, priority of the RFI and if it was sent via a transmittal, the reference of the transmittal.
The RFI should also have the query or the question that the issuer has along with the needed response date. It should be noted that on some projects, there could be an agreement on the time limit to respond to RFIs depending on their priority. In addition, many of the new construction contracts require the RFI issuer to be proactive and propose a solution for the raised RFI.
From the Engineer side or the party who is responsible for responding to the RFI, there will be a section called “Answer” or “Response”. The response to the RFI query could have an impact on the project scope, cost and/or schedule. Should this be the case, then this needs to be highlighted along with the ID of the activity that could be impacted.
Should the RFI has relevance to other project communications like meeting minutes, daily reports, drawings, submittal, transmittal or even other RFI, then project records need to be linked to the RFI to provide a complete description of the RFI under question.
For the RFI reviewer be able to respond in a complete and prompt way, the RFI should have all relevant documents attached to the RFI. Those could be drawings, specification section, material catalogue, pictures and/or videos of current site conditions. This will enable the reviewer to access those documents to better understand the question raised in the RFI.
Building Information Modelling (BIM) and RFI
With the growing trend of projects using BIM to develop the project design, installation shop drawings and as-built documents, clash detection issues identified in BIM can be also managed using the RFI. In addition to the RFI details explained earlier, the RFI should also include reference of the BIM model for which the RFI is issued for.
The project management procedures manual will detail the workflow steps and responsibilities for submitting, reviewing, sharing and approving RFI. It is possible that there could be multiple versions of the RFI workflow depending on the RFI category, whether the RFI has an impact on the project scope, cost and/or schedule.
Project Management Information System (PMIS) like PMWeb are used to map the workflow steps for submitting, reviewing and approving the RFI. For each step, PMWeb will allow setting the actions that the step owner needs to do, duration allocated to the step and the RFI fields that he/she have access to. In addition, PMWeb allows creating what is known as “Conditional Workflow” where different or additional reviewers will become involved in the review process depending on the RFI attributes. Those for example could be the category such as mechanical, structural, etc., whether the RFI has impact on the project scope, schedule or cost, project location affected by the RFI among many others. The conditional workflows help in removing the guess of who else needs to be involved in the review process.
Project Owners should be aware when projects have excessive RFIs as this could indicate different things that need to be investigated. For example, it may be an indication of incomplete contract documents: where the Contractor has to make many RFIs to obtain necessary info to construct project. Or it can be an indication of incomplete study of the contract documents by the contractor for which the contractor uses the RFIs to ask questions rather than study documents. Regardless what is the reason for the excessive RFIs, the project could be negatively affected as they could result in project delays due to the time to respond those RFIs as well as additional cost as the Contractor might claim that as a result of the clarification, additional out of scope work needs to be done.
It is no wonder that most PMIS applications like PMWeb allows generating change events from RFIs as this is that has high likelihood to happen.
Tabular and graphical reports are important to communicate RFI status and performance details. Tabular reports are usually developed to provide a log of submitted RFIs. The report can be grouped by category, type, status among others. The report will usually show important information of an RFI including Reference Number, Subject, Date Submitted, Date Answered, Status among others. The Report can be filtered to show only pending RFIs or RFI that are talking more than 7 days to close.
In addition, graphical reports and dashboards are produced to analyze RFI growth trends, RFI response time, source of RFI among others. This data will help the project manager to identify unfavorable trends in the RFI process as well as benchmark and compare the RFI performance on a specific project with other projects that the organization are managing.