Last month's column described the information needed to make a request for proposal (RFP) useful to both the company issuing it and the vendors who must respond. But RFPs and the formalized process they represent are not needed in all purchasing situations. Several other approaches are available. Which approach is chosen depends mostly on two factors: how well the company understands its requirements and how familiar it is with the potential vendors. These are summarized in Figure 1.

Figure 1: Factors Determining Chosen Approach to Purchase

When requirements are well known but vendors are not, it's sometimes possible to replace a formal RFP with a "bake-off" during which several potential vendors demonstrate how they would solve an actual problem. The trick here is selecting the right problem: it must include the critical issues facing the buyer but be contained enough to address them in a reasonable amount of time. This approach most often makes sense when buyers are replacing an existing system because they will know exactly what to look for and suitable test data will probably be available. Of course, some preliminary due diligence is still required to identify the most appropriate vendors, and some additional research will be needed after the bake-off to ensure that the apparent winner is suitable in other ways as well.

One additional caveat is that this approach can favor vendors with quick deployment times. Sometimes the most suitable solution will do poorly in a quick test because it takes more initial tuning to reach its potential. If the tuning is just done once, it should not be overweighted in the final decision.

When requirements are poorly defined but the vendors are known, it may be worth postponing the final decision and instead setting up a trial or prototype to gain some additional experience. Many analytical and business intelligence vendors in particular offer these sorts of programs. The goal is to get a clearer picture of how you might actually work with the system, what it can and can't do for you, and what nonsystem issues you'll face, such as data quality, staff skills and end-user expectations. It may be necessary to invest in a little staff training on the trial product, but this itself adds knowledge that can later be used in defining general requirements.

There's some danger that you'll fall in love with the trial system and never get around to considering other alternatives - but if you do find something that works well on the first try, what's so bad about that? A more likely outcome is you'll learn what's hard, what's easy and what's important, and use that to guide your assessment of the competitive products, possibly using the bake-off approach described above.

When requirements and vendors are both well known, you may be able to skip much of the structured process and make a choice after limited interaction with the leading candidates. This may seem like such a risky strategy that you would never employ it. But consider several situations:

  • You have such simple needs that any major vendor is certain to meet them. This might apply to near-commodity products such as a small business accounting package or email broadcast system.
  • The risk is low enough that you can afford to make a mistake. Risk includes the investment in the product and the cost of having it not work. Open source technical utilities often fall into this category: they're nearly free, and if they don't work, you'll find out right away and try another. It can be cheaper to work this way than to conduct a lengthy, formal evaluation.
  • You have access to detailed information based on a previous experience. You may have hired a consultant who specializes in this area or knows someone who has recently evaluated similar systems and is willing to share the information they gathered. You have to make sure they were looking at the same requirements, but assuming they were, their information should let you form detailed judgments of candidate vendors without gathering it again yourself.

In each of these cases, you'll still need some research to be sure the selected vendor can really do what you want. But with enough pre-existing knowledge about vendors' capabilities and your own needs, you can move directly to very specific questions to resolve your uncertainties and then make a sound decision.
When both requirements and vendors are not known, you might still be able to use a trial or prototype to improve your understanding of your requirements. But for projects that exceed a certain threshold of complexity, a trial won't teach you enough to be useful. In these cases, your best bet is the traditional structured process and a formal RFP.

When deciding which method to choose, bear in mind that running a great selection project is not an end in itself. Your object is to find a system that works. Do that as quickly and efficiently as possible, and then you can move on to the real goal, which is deploying a system that benefits your organization. 

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access