I’m not sure what the reason for this is, maybe it’s the “Free RFP Templates” for e-Sourcing (RFPs & e-Auctions), Supplier Management, Contract Management, and Spend Analysis brought to you by Procuri & Co., maybe it’s an over-inflated sense of technical knowledge, or maybe it’s just plain stupidity – but more and more I’m hearing about buyers looking for spend and supply management solutions that are putting together ridiculously over-specified and complex RFPs that are often eliminating all but the worst solution one could possibly imagine before the first response is even received.

The fact of the matter is that, when you are looking for a solution, there’s more than just one correct architecture, the number of features isn’t important, multiple deployment models may be satisfactory, advanced payment models and complex SLAs may not be necessary, and the processes you assume you need may not be the right processes for your business.

If the solution works on your current platform, does it really matter if its written in J2EE, C++, or Ruby on Rails (as long as it was put together properly)? Does it really matter if one solution has 800 “features” and another solution has 1000 “features” if all you need to support your processes are 200 “features”? And more importantly, do the features even address the critical functions you need to get the most out of the solutions? Although on-demand SaaS has advantages over ASP, and ASP has advantages over localized deployments from TCO perspectives, from a security and control perspective, assuming you have a crack IT team in house that knows what they’re doing, arguments can always be made in the other direction. (However, most non-technical companies don’t have crack IT teams, regardless of what they think, and that’s why I’m such a proponent of the on-demand SaaS model.) Not everyone uses the complex payment models pioneered by Oracle and SAP – some vendors use very simple pay-as-you-go models – especially on-demand vendors who charge you one fixed fee a month for the license, including maintenance, and one variable fee a month for how many days of consulting you utilize, easily calculated as number of days * resource rate. Finally, have you taken the time to evaluate your current processes from an efficiency and effectiveness standpoint? Maybe they are not optimal – in fact, if you haven’t reviewed them lately – chances are they are not optimal and a good time to change them might be upon implementation of a new system that can support the processes you should have, versus the processes you have today.

Thus, when constructing your RFP, if you’re not an expert in technology, and unless you’re an IT company – you’re not, don’t pretend you are. If you’re not an expert in what today’s solutions can do – and unless you’ve spent a significant amount of time researching large and small vendors alike – you’re not, don’t assume feature function lists, and definitely don’t assume that one vendor’s template is the best feature function list that’s out there. And definitely don’t use a template provided by a vendor being invited – that template was written to make them look good from a comparison perspective with their primary competition – which may not have any correlation to the solution you actually need.

Leave the technical and feature specifications open-ended. Instead of describing a proposed solution, describe the problems you’re having and the problems that you expect the solution to solve and let the vendors describe how their solution could meet your needs. And if you’re worried about the responses being too apples-to-oranges to make a decision, do a two-stage RFP. Issue a preliminary, open, RFP that describes the type of solution you’re looking for, the problems you want it to solve, and asks the vendors to describe how their solution meets this need and what key functions it offers and tell them that the best submissions will be invited back for round two, which will be closed.

Review the submissions to the initial RFP, invite clarifications and demonstrations (on the grounds that price and terms will not be discussed), flesh out your requirements, and then issue a closed RFQ with more detail on any architecture or deployment restrictions, the core functions you desire, your minimum SLA requirements, and your criteria for scoring the responses and selecting a solution. (For example, saying you can’t do on-premise Linux because you don’t have the tech resources is good, unlike saying that only on-premise Windows works when in fact you could consider on-demand with Windows Thick client. Saying you need a centralized contract repository as part of your CM solution, once you understand what that is, is fine, whereas saying you want a repository that uses Oracle 10.X, because that’s what you have a license for, when in fact the solution might come with a built in database or license for the database it uses, is overly restrictive.)

If you’re smart about the RFP process, then the solution you end up with will surprise you in its effectiveness and efficiency. However, if you just follow the herd, then you might find that you add to the statistics that say at least 70% of all IT-based projects are at least partial failures, because the system will likely not live up to your expectations of it. I guess what I’m saying is, don’t be an RFP-lemming. (As a reader of this blog, I know you’re smarter than that – but I need you to help spread the word!)