Instead of extensively testing and evaluating numerous products, IT buyers can draw up a shortlist of suitable tools and then flip a coin. This method must be used with great care, but can save managers time and money.
By 2010, the amount of effort devoted to product selection will drop by at least 75 percent (0.7 probability).
Product selection has traditionally been a major task for IT departments, as well as for IT analysts like Gartner. Product purchases represent a large investment, so IT managers take the selection process very seriously. Gartner's Magic Quadrants, which compare products in a particular market, are among the most popular documents we publish. And most of the inquiries we receive are for product and vendor recommendations.
However, rigorous product selection processes increasingly work against overall efficiency. Most of the time, any one of several products (that is, all the products on a shortlist) are good enough to meet a project's needs. Some may be better than others, but often the differences are so small that it is not worth spending significant amounts of time or money to ferret them out. Far too much effort goes into the extensive product selection and technology "shootouts" we frequently see customers putting themselves through. Evaluation efforts can easily last several months, with dozens of employees examining every last capability from a list of vendors. Technology that is easily found and implemented, yet capable enough to meet minimum requirements, will be preferable to products with superior capabilities, but which are more obscure. In other words, good enough really is good enough. Of course, this abbreviated selection process is not appropriate for all selection decisions (see Note 1).
IT managers undertake these extensive product evaluation and selection procedures at the cost of other efforts. These include strategy development and communication, change management, training, selling the new system internally, understanding user requirements, iterative prototyping and integrating business processes. The overall project would be far better served by focusing on these kinds of activity, rather than making heroic efforts to determine which offerings are marginally better than the alternatives. If the organization has developed an effective enterprise architecture, then these fast-track decision-making processes will be easier to implement, as the available options will be clear. If not, efforts to define such an architecture will be more beneficial than many of the large-scale evaluations we have seen.
The first part of the process should narrow the long list of potential products to a shortlist of those that could meet user requirements, fit into the organization's technical architecture, and are available within the estimated budget. This triage process is already common practice in most selection projects. The goal is to arrive at a list of products that could meet all important requirements.