Diaxion is frequently involved in the creation and review of Request for Proposal / Tender (RFx) documents and review of the responses to these documents. This article examines some of the issues we encounter from the perspectives of:
- Creation of a quality RFx document &
- Responding well to an RFx document
RFx Creation
RFx documents will usually be created by a team or group of people. This leads to the usual issues within projects:
- People not supplying promised information on time (as creating the document with its list of requirement will be in addition to people’s regular tasks)
- People being unaware of what is required from them
- Lack of required information
Approach the creation of the RFx document as you would a normal project. Be sure a plan is in place with clear deliverables with dates and that the required people are assigned and available. There will be a mix of governance items, functional and non-functional requirements. The writer should take care in detailing how prescriptive each item is along with their individual importance.
Diaxion’s experience with RFx documents shows us that mandatory response items should be strictly enforced, i.e. if a vendor response does not address a mandatory item then the vendor’s response should be disqualified. This means that a careful balance is required between mandatory and all ¬¬other criteria. Be sure to ask, “Do we absolutely require this functionality?” or “If vendor X cannot provide it, are we willing to exclude them?” If the answer is “yes” then it deserves to be a mandatory item; if the answer is “no”, then the importance may best be described as “highly desirable”, “desirable” or even “optional”.
Requirements that are too prescriptive will force respondents in a certain direction, which may carry the risk that you may miss out on other – and possibly better – options. There are areas where items will need to be prescriptive, e.g. “needs to provide bandwidth of larger than X”, but there are others where it will not matter how things are done; what is important is that they are being done – e.g. “Describe the available monitoring options” instead of “Needs to be monitored by Z.”. Note that a less prescriptive requirement will make a reply more difficult for respondents, as it requires creating a proposed solution and not just knowledge of their marketing material or product specifications. The strength of the response to less prescriptive items is often a good measure of a respondent’s capability and confidence in their solution.
When creating the RFx document find a balance of how detailed, the requirements are – Diaxion recommends to err on the side of caution and rather include more items than leave out requirements, which common sense would assume to be implicit. You may be surprised what respondents will come up with if given free rein. It will not be as horrible as a respondent offering a 12V DC power solution for a new data centre switch environment, but even so, it might be a good idea to include a requirement like “Describe the available power options” or “Must be 240V AC power, single-phase with plug Y”.
Ensure the document is reviewed by all parties before its release to confirm that everything essential is included.
If your tender/proposal process permits, be generous in granting – reasonable – extensions. Respondents asking for an extension is a good sign, as it shows interest and a desire to deliver a good response. Granting an extension can improve the quality of responses, which in turn is likely to increase the competition amongst respondents.
The document should be written in a way that it makes it easy for respondents to understand the requirements and expectations for the response. Try and group requirements together in meaningful ways and be sure it is clear how the responses will be evaluated.
RFx Responses
Responding to RFx documents is straightforward when the RFx clearly demonstrates:
- What format responses should be in,
- Which sections must be responded to, and
- The relevant importance of each criteria
Diaxion’s experience shows that the first item in many cases will be ignored, i.e. although an editable format may be requested, responses may only be submitted in a read-only format. Even the second area (i.e. response to all sections) may be lacking sometimes, which may be due to:
- Respondents not thoroughly reading the RFx document
- Several disjointed teams responding to the various sections (“I thought you would do this section”)
- Respondents rushing the response due to insufficient time or poor planning
The above three items will also decide how well a response will address all other criteria and requirements. It may result in responses like “tbc” or “?”, which complicates the evaluation of responses – does one score a response like this based on the written response or on information referenced elsewhere (be it somewhere else within the document, based on “common” knowledge or freely available within other documentation)? In Diaxion’s experience it is best to ensure that the response does not contain any missing information.
It is in a respondent’s best interest to make the evaluation of the response as easy as possible – again a logical and concise structure of the response will help significantly. Ensure that the response items align with the structure of the RFx and ensure the response items are clearly relatable to RFx information and requirements. Be sure the requirements are all addressed, especially the mandatory and highly important ones. Ultimately responding well to an RFx will come down to:
- Reading the document,
- Spending the time to answer all questions, and
- Addressing requirements based on their importance as outlined in the document.
An effective RFx approach and process will benefit both the requestor and the respondents. Clear information about requirements and importance ensures that respondents will be able to submit the best response that addresses the requestors needs.
