Many organizations still issue RFP’s for selection of software products. Issuing and RFP is an extremely poor way of evaluating software in today’s world, particularly end user software such as budgeting software. RFP’s are generally a generic wish list of historical features and functions that are also normally equally weighted. The process is outdated and the results often disappointing leading to poor choices that focus on past processes not new and better ones.
There are two fundamental problems with RFP’s.
The first problem is that RFP’s totally miss functionality that might make one vendor’s solution unique. That functionality could turn out to be hugely valuable and lead to a better future way of conducting business, but unknown and completely ignored in the RFP. Since the capability or philosophy is unique to that vendor, the general marketplace may be unaware of it, and therefore it is not given consideration in the RFP process. RFP’s offer a historical perspective, not a forward thinking one.
Think about it. An RFP for a portable music player 12 years ago, for instance would have asked, how many CD’s can be loaded into the device at one time? The answer, of course, is/was zero. With new functionality and innovative design introduced on a regular basis, the technology world moves way to fast for RFP’s to remain effective.
The second problem is that many of the features requested in the RFP either go unused (they were on a wish list, but not necessarily needed) or they turn out to be unusable in practice.
In the first case, wish lists tend to put too much emphasis on things that are checkmark items. These are nice to haves, not required. In the second case, an RFP has no way of determining whether any requested feature can be used by the company issuing the RFP. A brilliantly designed user interface that was developed specifically for a given market and a given user, is not identifiable in the RFP process since all vendors would state that they have a great UI.
Many times RFP’s are issued by either consultants attempting to justify a large contract for a selection of a product, or by a purchasing department that has no vested interest in the success of the solution and is normally wedded to a historical process for selecting products. Neither of these situations are good for the company.
Often times, consultants can charge an exorbitant fee to select a software product. They will then select a software product that also has exorbitant fees. Who in their right mind is going to pay an external consultant $50,000 to select a $20,000 product?
The best way to select software products is to open up your mind to what is happening in your industry right now. Listen to a vendor’s pitch and see if it matches your vision of the problems that you are trying to solve. Focus on your top 4 to 5 issues, not your top 100. Then, determine which vendor is truly effectively serving your industry. Mitigating the risk of a potential failed implementation or a disappointing one is far more important than a generic checklist of items that may, or may not have been extensively used in your industry. Ask for references and case studies and choose the vendor who has the best track record of success.
Your RFP checklist went the way of the Sony Walkman.
