It’s not hard to draft an unbiased RFP, even though you might think otherwise when you consider the truly large numbers of RFPs that hit the wire every day. Many of them are biased toward a specific provider. The fact of the matter is that it doesn’t take much to bias an RFP, and it often happens without the intent of the author. But it doesn’t have to happen to you. Here are some tips to keep your RFPs unbiased.

• Don’t use a (free) RFP template
  I’ve told you again and again. These are created by vendors to achieve one goal, and one goal only: to make their product, and only their product, look good.
• Ignore the feature lists
  This is a free RFP template favorite; namely, features selected for their “differentiating” capability, that you’ll never use. It’s not the features that matter, it’s the functions. Specifically, the functions you need the product to perform for you.
• Don’t use an interested party.
  That means no vendors, no solution providers who’ll be bidding on the business, no consultancies with partnerships or known relationships with vendors or solution providers who’ll be bidding on the business, and no one with an obvious agenda that’s not yours.
• Describe the process you need to automate or support in your own words.
  The minute you use a vendor’s terminology is the minute you give them the edge to exploit the RFP and, in the public sector, ramrod the solution down your throat, whether or not it’s right for you.
• Describe the goal state, not the current state
  You get what you ask for, and if you ask for a solution that supports the current state, which you presumably want to improve, you’re not going to end up with much of an improvement.
• You’re probably not a technology expert, so don’t put technology in the RFP.
  Don’t make the error of assuming that you know what technology would be best.
  If it’s software you’re buying, be wary of opinions from your IT department.
  IT people are most likely not
  software developers, so they have at best a limited understanding
  of the technologies that software developers use. Even software developers tend
  to know only the technologies with which they are currently working, and they are
  often deeply biased toward a particular technology, for no rational reason. You are looking for a solution, not
  a technology. So spend your time focusing on the solution and what it does for you.
• Make sure you control your data.
  If it’s software you’re buying, then no matter what solution you choose,
  make sure part of your RFP includes a requirement to get
  the data that you pumped
  into the product, back out of the product, easily and quickly, in a format that’s understandable to you (not
  XML or a proprietary database file, or some other idiosyncratic format that will cause pain — rather, an ordinary flat file,
  or set of related flat files). Your relationship with the vendor is not likely to be “until death do us part.” The
  software world moves extremely quickly, and a much better solution could present
  itself down the road. You want the ability to jump on it without a backwards glance.
• Unbundle all the extras.
  Vendors will almost always muddy the water by “including” A with B, proposing some special deal that’s available
  for a limited time only, and so on. Make sure that your RFP unbundles maintenance from license fees or purchase price; clearly spells out the cost to upgrade; and clearly disambiguates services from product.
• Demand multiple sources for services.
  Just because you’ve committed to Oracle ERP, for example, doesn’t mean that you have to use Oracle resources to
  implement the system. The same is true for other software products, and for many other commodities as well.
  The cost of services can dwarf the cost of the product; and the best deal for services is achievable
  when there are multiple services providers. When vendors are bundling services, and no matter who you choose it’s a one-stop shop,
  you will be helpless the moment you sign the deal. Would you buy a car that could only be serviced at one
  dealership?