The Request for Proposal (RFP) is a sacred cow of software selections, but West Monroe now believes they create a lot of work for all parties and provide limited value to the final outcome. We recommend removing the RFP from your selection process and instead focus on the below alternatives, which you will find improves the functional evaluation of the software, accuracy of the cost estimates, understanding the vendor’s implementation methodology, and increases the overall efficiency of the selection process.
|Typical RFP Area||Recommended Alternative|
|Using the RFP to conduct a software gap analysis: RFP’s typically include a list of requirements and vendors are requested to respond with a “Gap” or “Meets Requirements.” The problem with this exercise is that it is open to interpretation and experience shows that vendors inflate the capabilities of their software. Our experience shows that vendors will respond affirmatively on paper to get to the demonstration stage and in front of the customer with their well-trained sales team. Then once the functional evaluations begin, they aren’t able to meet a couple of key requirements with out-of-the-box features and the evaluation team has wasted time and effort in coordinating the demonstration.||Short demos to see the software meets knockout criteria:
Conduct brief, 1.5 hour demos against the top 25 knockout criteria during your vendor research to arrive at your shortlist of 3 vendors. Knockout criteria should be the major software capabilities that the business model requires such as product lifecycle management (not individual requirements within a single business function). You will begin to understand how tailored the product is to your industry and when third-party solutions may be needed that increase complexity.
|Total cost of ownership (TCO): The vendor is asked to provide an estimated cost to acquire the software licenses/subscription and implement the software. The problem with this approach is the estimates are based on assumptions around project scope, timeline, and resources. These three key factors must be mutually understood by both parties, and we often find inaccurate assumptions are made by both parties. The result is iterations of submitting questions by a deadline and back and forth Q&A, which isn’t productive and is open to interpretation.||During your selection process, develop an “implementation estimate outline” deliverable that provides a detail on project scope, resources your organization will be able to commit to the implementation, and expected timeline. The scope should include functional modules (e.g. Inventory Management), key capabilities within those modules (e.g. Lot Controlled inventory), as well as technical scope (reports, interfaces, data conversion, customizations, form or user interface updates, and workflow objects). Then, meet with the top three vendors to answer questions and walk through assumptions made. This includes a review of the full team structure, clarifying assumptions on roles and responsibilities of technical activities (e.g. data conversion, interface development, etc.), the project management requirements, and most importantly agreeing on the scope to be delivered. Spending time in-person with each vendor following demonstrations on this activity will result in a much more accurate implementation services proposal and in the end a project budget that is realistic.|
|Understand the vendor’s implementation methodology: The vendor is asked to describe their implementation methodology and why they are different (e.g. provide best practice, industry process models that will “accelerate” the implementation, etc.) Again, this is largely open to interpretation and vendors will overstate their capabilities and methodology.||There are three key project activities we recommend to get you comfortable with the vendor’s implementation methodology, rather than reviewing a great amount of written detail in a RFP: