In capital construction projects, a request for information (RFI) is a formal business process in which the contractor seeks clarification of plans, specifications, bill of quantities, and agreements from the consultant. While this process sounds straightforward, RFIs could be abused and become a source of delay, expense, conflict, and even legal claims and disputes. Therefore, project owners should ensure having a robust solution to manage, monitor, evaluate and report on RFIs to prohibit contractors from abusing this business process.
Contractors can abuse the RFI process when they ask for information that is contained in, or is reasonably inferable from, the contract documents, or create the ground to necessitate issuing a change order by exposing consultant errors or omissions. Another form of abuse is when contractors submit so many urgent RFIs that the consultant cannot respond to them in a timely manner or when they submit RFI at the end of the day before the weekend starts. In addition, some contractors abuse the RFI process by using it to create the ground for material substitutions. To overcome those threats, project owners should ensure that the RFI business process is automated. This would require having a template to communicate RFIs which is properly designed to force contractors to provide all possible details on the submitted RFI. The template should eliminate the threat of submitting ambiguous RFIs that could be used by the contractor to claim for additional expenses and delays. In addition, each RFI should be promptly communicated to the individuals who will be responsible for providing answers in accordance with the project’s Delegation of Authority (DoA) matrix. Finally, there should be real-time reports to provide details of delayed responses to the issued RFIs as well as reports to provide an overall understanding of issued RFIs, their reasons, their time and cost implications, their trends, and how efficiently they are managed. Using Project Management Information System (PMIS) solutions like PMWeb, the Request for Information (RFI) is one of the many default modules available to be used. Nevertheless, the default RFI module needs to be properly configured to ensure that this business process will not be abused by contractors. To start with, the project owner should ensure that all submitted RFIs are well defined to enable a timely response that protects the project owner’s interests. For example, each RFI should be assigned the Work Breakdown Structure (WBS) level that it is associated with. In addition, the contractor needs to select the reason for issuing the RFI using a predefined list of 20 possible reasons why an RFI is needed. Further, the contractor needs to identify which project schedule activity this RFI could impact if there was no timely response to the raised query. The RFI will also include a field to identify which building system the raised query relates to and the priority of the RFI. Of course, the RFI should also include the query to be answered which must be stated in full. In addition, each RFI should include the response due date for which the duration to respond to an RFI is usually defined in the contract agreement.
In addition, using the checklist tab, the RFI template will be designed to include confirmation from the contractor that the submitted RFI (1) is not for information that is contained in, or is reasonably inferable from, the contract documents, (2) is not to create the ground to necessitate issuing a change order by exposing consultant errors or omissions, (3) is submitted before noontime on the day before the weekend starts, (4) is the ONLY RFI that has been issued today and (5) is not submitted to create the ground for material substitutions. Of course, other confirmations can be added to the checklist to prohibit actions that a contractor might use to abuse the RFI business process.
In addition, PMWeb allows defining who will be having access to what fields in the RFI template. For example, the fields of the proposed response and answer will be completed by the consultant team. Similarly, the fields if the RFI could have cost and/or schedule as well as if it was for work in scope or out of scope will be completed by the consultant team. This will ensure that each assigned role group has access to their assigned data fields in each business process including the RFI business process.
In addition, for providing the data for the fields assigned to the contractor to complete in the RFI, the contractor must attach all drawings, specifications, bill of quantities, pictures, snapshots of the BIM model, and other documents that are associated with the submitted RFI. The contractor needs to add comments on each attached document to explain what is being submitted to enable expediting the required RFI response.
PMWeb workflow will be used to map the tasks needed to review and approve an RFI. For each task, PMWeb allows defining the user or role assigned to the task, duration of the task, task type, and actions available for the task. In addition, it will define to whom the transaction needs to be returned and to whom it needs to be resubmitted. The data fields for the reason of the issued RFI as well as the building system the RFI relates to are very important to improve the communication of RFIs. Those fields will be used to add conditions to the workflow so they can be forwarded to the assigned design consultant, project management consultant, and project owner team depending on the values captured in those fields. In other words, to enable full compliance with the approval authority levels set in the Delegation of Authority (DoA) matrix.
When an RFI is submitted by the contractor, the workflow tab on the RFI template will be automatically updated to capture the actual review dates and actions taken by the assigned project team members. The log will also detail comments made by the reviewers and other team input if it was requested.
Output forms and transactions registers for the RFI business process can be designed in different forms and formats to match every project owner’s reporting as well as branding requirements. Nevertheless, the project owner needs also to have access to a report that details the status of submitted RFIs workflow tasks. The workflow report can be also designed to report on the workflow tasks for other business processes managed on a project along with those of the RFI. The workflow report can also be designed to show the status of the workflow tasks on a single project or a portfolio of projects that the project owner has. The sample out-of-the-box workflow report shown below can be fully customized like for example adding color coding for delayed, due, and on-time workflow tasks.
The RFI Use Abuse Analysis report can be designed to include a visual to show the growth trend of RFIs and Potential Change Orders (PCO) that were RFI-related. The report will also include an analysis of the reasons why the RFIs were submitted by the contractor. In addition, the report will include other visuals to summarize the current status of RFIs, which specification section they are associated with, and which building system to relate to.
