The increased pressure to get more value out of IT and to reduce related costs has pushed many companies to deliver business systems and applications by acquiring commercial-off-the-shelf (COTS) products and packages. This shift from “build” to “buy” has produced good results for many companies. However, this change has also adversely affected how some organizations make decisions about which products to acquire.

Because of this shift, some organizations aren’t familiar with the IT product decision-making process, and as a result, can end up making the wrong buying decision. In some cases, they find hidden costs necessitated by unexpected hardware or operating system upgrades. In other cases, the organization realizes that they are unable to share or integrate data captured by the product with other systems they have in place. Still other companies discover, after the fact, that they have to implement and maintain excessive customizations in order to make the product work.

So, how do organizations get smarter about making IT product decisions? Perhaps the best way is to avoid treating product decisions as a one-time event. Just as most business decisions are made with a certain amount of due diligence, so should IT product decisions. This article presents concepts and a toolkit to improve the quality of making IT product acquisition decisions.


The toolkit has two pieces: a decisionmaking framework and an evaluation and selection process that puts the framework into action. The framework represents a set of screens and hurdles that IT acquisition candidates need to navigate. While we can’t prescribe a set of screens and hurdles that will fit every situation, you can adapt our framework to meet your specific needs.

Figure 1 shows the framework for four key and complementary components that should be considered whenever making an IT product decision:

  • Strategic: Does the product fit and support the overall strategic direction of the organization? If yes, how well?
  • Technical: Does the product fit into existing or planned technical infrastructures?
  • Business: To what extent does the product fit the business’s functional requirements?
  • Marketplace Viability: To what extent have other companies adopted the same product? How many installations are currently in production?

Each of these four components will have one or more stakeholders. For example, the stakeholders for the Business component may be represented by a business unit looking for a product to provide dashboard reports on the effectiveness of your firm’s sales force.

The stakeholders for the Technical component may be the shared service IT group who need to ensure that the selected product conforms to the Enterprise Technology Architecture or other technology standards. What if the selected product satisfies the needs of the business stakeholders but requires hardware platforms and system software that are not supported by IT? This can mean that the collected evaluation and selection criteria from all of the stakeholders may be in conflict.

This is where a standard product evaluation and selection process needs to be applied. In addition to ensuring that all IT product evaluations are treated equitably and follow a defined and repeatable set of steps, the process can serve to balance the needs of the stakeholders through trade-offs, increased understanding, and prioritization in order to achieve buy-in.

5 Pages