Hut 12 is designed to help businesses discover new relationships and fortify existing ones.…
Is it time to reconsider using email for project communications? What about the issues of price, ease of use when using a dedicated project communication platform? Are the benefits real or perceived?…
On April 25th we remember the Anzacs.…
Right now Hut12 is in beta test mode…
…and everything is FREE!
Projects are by their very nature, complicated. Thus, it is almost impossible to prepare in advance all of the information that will be required for the project. Furthermore, during the life of the project there will be many more potential opportunities for misalignment between the project stakeholders (Owner, Architect, Engineer, Contractor and Subcontractor etc.).
To successfully execute a project, delivering it on time, to the right quality, and on budget, the people and organisations involved in the project, need to ensure that they remain aligned. This is best managed by maintaining clear lines of communication between the project stakeholders, with phone calls, regular meetings, and rapid transfer of new or emerging information.
The two greatest area of need lie in the rectification of project documentation, and in addressing previously unknown or unidentified problems as they come to light.
Because of the immense level of detail required in modern projects, it is highly likely that project documentation will be missing information or contain some form of error or contradiction. For example, the person who drafted an electrical drawing for a building may have inadvertently forgotten to document the type of light fitting to be installed in a room. Or the location of a power point in a bathroom may be specified to be placed too close to a bath – conflicting with government legislated requirements.
As a project progresses new issues will emerge. A software programmer may discover that that the specified approach is now redundant due to recent changes in a third parties software platform. A contractor excavating a site may find buried concrete from an old structure that no one knew existed.
No matter how carefully prepared the project documentation, or confident a person may be that there will be no surprises in the future; There will always be changes during the planning, bidding, and execution phases of the project that will require ongoing adjustments to be made throughout the life of the project.
Informational gaps and subtle ambiguities are common in the project process – from concept design, through to engineering, design and finally execution of the end product.
This is where a Request for Information (RFI) is needed.
What is a Request for Information?
A Request for Information or RFI is a formal document designed for the purpose of documenting questions, clarifications, and generally seeking additional information for projects. RFI’s are commonly used in the building, construction, engineering and IT industries.
In construction, the RFI is typically written by the general contractor or subcontractors hired for the project and is sent to the engineer, architect, or owner. Whether documented on paper or email, the RFI is designed to acquire information that is either not contained in the contract documents, or is otherwise not readily available. It serves as an augmenting tool to resolve any conflict, gap, or unclear information early in the project process to avoid the need for expensive corrective action later on down the track.
An RFI is a formal document that requires the appropriate level of detail so that the person receiving the RFI can understand the information being sort and, in turn, provide a fully informed answer to the sender.
Request for Information vs. Request for Proposal & Request For Quotation
With the many different types of documentation and abbreviations used, and the specialized nature of organizational nomenclature it’s easy to get confused between RFIs, RFPs and RFQs.
While we already know that Request for Information is a document designed to seek answers and additional information during the life of a project, let’s go deeper to see how RFIs differ from Request for Proposal (RFP) and Requests for Quotation (RFQ).
The terms Request for Proposal (RFP) and Requests for Quotation (RFQ) can be, and are, used interchangeably. Typically, organisations use an RFP to put an enquiry into the industry marketplace to obtain quotations from potential contractors and agencies to undertake a particular scope of work. For instance an architect may issue an RFP or RFQ to general builders to obtain quotations for the construction of a new building.
Contractors and agencies receiving such an enquiry will then submit quotations for the work back to the relevant organisation, with their bid pricing, particulars and any qualifications where they wish to elaborate on the requirements of the RFP.
RFIs are specifically designed for highly targeted question and answer situations. Thus, a contractor that has received an RFP/ RFQ will likely seek additional information during the tender period by submitting RFIs to the organisation that issued the RFP/ RFQ in order to acquire more information.
How to Write an RFI
When writing a Request for Information, it is important to remember that the primary objective is to obtain accurate information that will resolve an outstanding issue.
Before writing an RFI, it is crucial to identify the crux of the issue at hand – what is the missing information?
An RFI should be clear and concise, but at the same time the enquiry needs to contain sufficient clarity and detail as to fully inform the responding party of all of the pertinent facts pertaining to the issue.
To that end its worth employing the crucial questions of What, When, Where, Why, How and Who, although the order may vary.
It is also worth considering the sort of questions that the recipient will likely ask themselves:
- What do the project documents say about this?
- What are the possible solutions?
- How will this impact the project?
One method that can be used is to prepare a list of all of the questions that need to be asked. Then from that list generate the possible recipient queries. Once the recipient queries have been generated, address those queries by modifying the original set of questions and adding appropriate drawings, sketches and photos to describe the problem and any possible solution.
Another excellent method is to run the proposed RFI past a colleague, who is not well acquainted with the issue. Their lack of direct knowledge means that they, like the intended recipient, will be largely reliant on the content of the RFI. If they can understand the RFI, it is good to go, if they cannot then the RFI needs to be redrafted!
At the conclusion of this process, the RFI should contain a clearly articulated question (or set of questions) along with appropriate attachments, sufficient for the recipient to fully understand the issue.
Make sure that your RFI is clear, direct and to the point.
Focus on one topic only
Some people make the mistake of putting all the issues at hand in to one RFI. This is poor practice.
Instead, limit RFIs to only one topic at a time. This not only reduces the chances of overly complex and ambiguous RFIs, but also makes future use and reference to the RFI much easier.
By limiting an RFI to one topic, it helps both the sender and the recipient. For the sender, it makes it easier to track a particular issue, enables more rapid location in future, and helps both parties to be clear in their minds as to what the issues are in each instance.
A well-focused RFI will likely lead to a faster response from the recipient, and in turn a faster turnaround overall.
The goal of the RFI is to resolve gaps and clarify any unsettled issues. Thus, it is important that your message is clear, direct and to the point.
Use the subject line (field) to clearly communicate the essence of the issue. Additionally, make sure that your message is clear and unambiguous. Break long paragraphs into small ones, use bullet points if needed to make it easier to read and understand.
To be able to communicate well, make sure to provide context as needed. Attach relevant information such as documents, photos, sketches, and/or drawings that will assist both the recipient and readers in future.
Propose possible solutions
To help speed up the RFI process, voice out any possible solutions that you may be aware of. The more options you can share, the faster both parties can resolve the problem.
When proposing possible solutions, consider the following questions in mind:
- Is it doable within the given timeframe?
- Is it within the budget constraints?
- How much more manpower and/or hours are needed?
- What other materials should be utilised?
- Will it impact on other aspects of the project?
It is quite useless to propose solutions that are unfeasible or overly difficult to accomplish within a given timeframe. So, make sure to recommend reasonable options.
How to Respond to an RFI
If you are on the receiving end of an RFI, here are some good pointers on how to respond.
Don’t be afraid to ask questions
If there is any part in the RFI that is unclear or ambiguous, don’t be afraid to seek clarification from the sender. It is better to ask questions than to assume something.
Promptly deal with an incoming RFI
The purpose of RFIs is to obtain much need answers to project roadblocks. Thus it is important to give proper attention to incoming RFI’s, as failure to do so may result in delays to the project.
Respond as accurately as you can
Naturally, a poorly drafted response is of almost as little use as no response! When drafting a response the central issue is whether or not the response fully addresses the issue at hand. Before sending a response, take the time to review the question(s) again, along with the proposed answer to determine as to whether or not the response has in fact fully addressed the RFI.