The Request for Proposal (RFP) is the single most important pre-award project document. A well written RFP, supported by a well managed RFP process, greatly increases the likelihood of a successful project. The key word here is process. When the client issues an RFP, whether for open tender or to a closed group of pre-qualified providers, it sets in motion a scheduled chain of events culminating in the project being awarded to the most compliant bidder. The client should trigger the RFP process only when ready and able to manage it end-to-end, fairly, efficiently and professionally.
The ‘meat’ of the RFP is the requirement specification in which the client sets out expectations. The commonest mistake is to present this as a Bill of Quantities (BoQ), effectively a shopping list. The pressure to do this has two sources – purchasing departments still tend to favour an outdated model of ‘things they can see and touch’. And, more subtly, engineers tend to employ equipment names as shorthand for the functionality they believe the equipment can provide. The results of this approach are all negative –
- The RFP becomes almost impenetrable except to its authors who then don’t understand why the submissions miss the mark.
- By pre-selecting equipment, the client leaves little room for the bidders’ design teams to bring their creativity and market insight to the solution.
- If the client’s shopping list is flawed or outdated, there will be lasting consequences.
Far better to write the RFP around a set of required functionalities and standards that the project must achieve. These can be called the Project Imperatives. They are agreed by negotiation with the key stakeholders, a process that further helps end user ‘buy-in’ to the project. As always, the aim is to deliver performance to users, not parts to the racks.
This ‘functionality first’ approach has never been more important than it is today. If the RFP requests functionality, a bidder might come back with, “Have you considered a cloud-based solution?” This will not happen with a shopping list RFP.
Of course, while it is good to maximise the bidders’ scope for creativity, there will always be some constraints that should be made clear. For example, the entire organisation might be a ‘Cisco house’, with special pacts already in place between internal IT and Cisco. This should be stated in the RFP as a necessary compliance.
The RFP process is the other vital section of the document. The client expects the bidders to commit to substantial unpaid work up front and is therefore duty-bound to facilitate their efforts by providing a clear, unambiguous roadmap. At the very least, this should include –
- The client’s business name, contact details, and a summary of activities.
- The closing date and procedure for requests for clarification and related enquiries.
- The closing date and procedure for submitting the technical RFP response. Stipulating an unrealistic submission date will simply result in requests for extensions.
- Details of what must be included in the submission, for example – a compliance statement referencing each of the Project Imperatives, a provisional high level design and BoQ, a provisional Statement of Works.
- The closing date and procedure for submitting commercial information. (Commercial and technical evaluations are normally parallel processes.)
- Details and schedule of any required presentation of the solution.
- Schedule of post-submission milestones, such as award, contracts, mobilisation.
As well as the proposed solution and quotation, the client will require full company information from each bidder. This should be requested through a purpose-designed submission form, allowing like-for-like comparison between bidders. This also renders promotional literature inadmissible to the selection process.
Finally, and this is most important to avoid costly disputes, the client must make absolutely clear in the RFP what is being awarded. In particular, awarding the project to a bidder does not necessarily constitute acceptance of the provisional design. It means the client has confidence in the bidder’s ability to design and build the system on receipt of contract. The work starts now, for real…
Note: Your next RFP could be 50 times longer than this article and won’t write itself. It’s OK to ask TriMedia to help!