Six qualities of a well-written RFI

It’s a rare project that can be built without the constructor asking the designer some questions. These questions – typically called technical queries (TQs) or requests for information (RFIs) – are important and, while it seems the writing of these should be straightforward, there are a few key qualities that influence their value.

Three types of RFIs

Before we get to those, at CEA, we say there are generally three types of RFIs:

The overlooking constructor RFI
The forgetful designer RFI
The good idea RFI

Let me explain.

The overlooking constructor RFI goes like this: the constructor writes to the designer to say that some dimension, quality or quantity is unknown. The answer comes back with the designer referencing a document that has already been issued to the constructor (ie “constructor, please read the information that has already been supplied”).

The forgetful designer RFI is easy to pick…when the answer comes back, the information it contains was not included in the information previously supplied to the constructor.

The good idea RFI is simply one where the constructor understands the current design but believes there is merit in making a change. These are great RFIs, but only if they are completed early in the process, recognising that changes take time.

Six qualities of a well-written RFI

Here are our top six qualities of a well-written and productive RFI:

Searchable name – name your RFI correctly. Instead of something generic, like ‘design clarification’, use something that can be found in a future search, like ‘clarification of PSP widths’.
Single-minded question – try to limit your RFIs to one question at a time. Dumping multiple questions into a single RFI typically leads to delays in getting answers back, as multiple questions may well combine the three types above, requiring different types of responses, or requiring multiple discipline experts to contribute, in turn requiring more time to pull together an answer.
Thorough context – be very clear on your question and give sufficient references to drawings and specifications. If you make a responder’s life easier by giving them clear leads, it’s likely they will be able to respond faster – and that means works can begin or continue sooner.
Thorough recommendations – if you have a suggestion, be comprehensive about it in your request. For example, instead of asking “can this section be replaced with road base”, a better request would be asking “can this section be replaced with road base installed in accordance with Drawing 123 and Specification XYZ”.
Realistic timeframe – don’t cry wolf! If every RFI you submit has a response time of ‘ASAP’ or status of ‘urgent’, you’ll soon get a reputation you don’t want. Save your urgent status for a time you really need it.
Whole-of-project consideration – be comprehensive. Don’t have one question and then jump straight into your RFI writing. Consider the relevant construction process as a whole so you can identify whether there are connected questions that can be issued in a similar timeframe. This will make the designers’ lives easier and you’ll be more likely to get a fair hearing.