If you have decided to implement new software – be it a best-of-breed tool or a full-suite ERP – the next step will be to select your software vendor.
In most cases, the primary tool used to govern the vendor selection process is the Request for Proposal (RFP). And it goes without saying that writing an effective RFP is a critical step towards project
success, as this document is integral to the process which selects both the software to be implemented and the vendor who will lead its installation. Conversely, writing a poor RFP could have dramatic (negative) impacts on your project, as a bad RFP may very easily lead you to purchase the wrong tool, or engage the wrong vendor. Either of these outcomes would put your project well along the path towards RIP!
WHAT IS AN RFP?
A Request for Proposal (RFP) is a formal method of receiving detailed and comparable proposals from different suppliers for a defined product or service. It is a comprehensive document that should contain all the information needed so that the vendor can provide a useful, focused response. Such a response would then allow the customer to make an informed purchasing decision.
COMPONENTS OF AN RFP AND THR RFP PROCESS
We will shortly describe the various topics which should be included in the RFP document itself. Before doing so, however, I would like to introduce some steps you might consider taking before you actually release the RFP.
The NDA
Before engaging with a vendor in any capacity, you may wish to have them sign a Non-Disclosure Agreement (NDA). In essence, the NDA legally obligates the vendor to keep confidential any information gleaned from the customer, either during the RFP process or later in the relationship. Many Procurement Departments mandate that an NDA be signed in advance of any vendor discussions, but even if they do not, I strongly advise that one be put in place.
Pre-Release Interview
Before they release an RFP, some companies engage all their potential vendors (separately) in a ‘Pre-Release Interview’. Basically, this ‘interview’ provides customer and vendor with an opportunity to meet and discuss the project at a high-level, in order to confirm that both parties feel the vendor’s participation in the project will be worthwhile.
The interview usually lasts about an hour, and typically covers the following topics:
- Company Overview – Customer
- Project Overview – Customer
- Company Overview – Vendor
- Solution Overview – Vendor
- Project Timeline
- Confirmation of Participation*
*The Confirmation of Participation should be formalized by having the vendor complete and submit a short form, which indicates they wish to participate in the remainder of the RFP process.
COMPONENTS OF THE RFP DOCUMENT
The following are some of the more standard components of an RFP document. However, companies may choose to add other sections to suit the purposes of their specific project.
- Company Overview: The company overview provides a brief history of your company, its products and services, and its markets.
- Project Overview/Problem Statement: In this section you should articulate, at a high-level, the
problem you are trying to address and how you expect the project to address it. (Again, you do not need to go into great detail here, but you should provide enough information so as to ‘paint a picture’ for the vendor.) - Requirements: As I have stated in some of my other blog posts, I firmly believe that any time spent documenting requirements will pay significant dividends down the road. And, even though the requirements contained in an RFP are not has refined as they will be later in the project, making the effort to include as many requirements as possible, in as much detail as possible, will benefit the project tremendously. With that said, I recommend separating your requirements into two groups:
- Must Haves: As you may have guessed, these are the requirements that the project absolutely must deliver in order for it to be successful. (To refer back to a previous blog, these are the requirements necessary to provide the Minimum Viable Product (MVP).)
- Nice-to-Haves: These are the bell-and-whistle requirements. It is not necessary that they be delivered by the project, but including them will enhance the solution and could promote user adoption.)
- Evaluation Criteria(?): It is a matter of some debate as to whether you should include the evaluation criteria in an RFP. While I am OK with including some guidance as to how the vendor’s RFP response will be evaluated, I feel that including too much detail will lead to the vendor ‘tailoring’ their response to fit the criteria, even if they do not necessarily meet those criteria. I would prefer they provide a more generic view of their solution, without their response being influenced by highly-specific evaluation criteria.
- Budget (?): Some companies will go so far as to include the anticipated project budget in the RFP, as they feel this will help set vendor expectations. However, in my opinion, this is akin to showing your hand in poker. (From repeated losses at the table, I have learned that this is a BAD idea!). I prefer to let the vendor respond with their best price, and the customer can then evaluate the cost-benefit proposition.
- Timelines/Next Steps: The last section of an RFP is the section which contains such things as:
- the RFP schedule (i.e. Q&A period, deadline for filing RFP response, period when vendor demos will take place, date when vendors will be advised of the outcome, etc.)
- an outline of how (and when) the parties will communicate going forward
- the format and method for submitting the RFP response, and
- a general project timeline.
EVALUATION PROCESS
In conclusion, I would like to make a few points regarding the process for evaluating the RFP responses.
Firstly, there are many ways you can conduct your evaluation, but the process and criteria should be 
agreed to (and documented) well in advance of the RFP responses being received from the vendors.
Secondly, you have to decide if a vendor not providing all of the ‘must haves’ will eliminate them from the competition. (NOTE: It is unlikely that vendors will be able to provide all of your ‘must haves’. If a requirement really is a ‘must have’, you will need to discuss potential alternatives and work-arounds with the vendor in question.)
Thirdly, you should have decided if all ‘must haves’ and ‘nice-to-haves’ carry the same weight, or if some more important than others. If the latter, then you should assign appropriate weights to each requirement prior to evaluating the responses.
Lastly, you should determine in advance if all evaluations will have the same level of influence. (i.e. will the evaluations of more junior evaluators carry the same weight as those of executive-level evaluators).
Hope you found the post informative. Speak with you next week, when the blog topic will be centred on project management strategies for implementing systems.
