Comparing enterprise software is like apples and oranges

Many organizations start an enterprise software selection project with a Request For Information (RFI). Sometimes the RFI preamble will contain language along the following lines:

The purpose of the RFI is to solicit information that will allow us to compare and evaluate products and solutions, and determine the optimum direction for our organization.

The issue here is that enterprise software products are compared relative to each other, rather than being compared against organizational requirements. Relative comparisons between enterprise software products will lead to the following problems:

1) Unknown requirements

Every enterprise software selection is a journey where the organization discovers what they truly need. You can see the journey hinted at in the phrase “… determine the optimum direction for our organization.” Done properly this discovery of needs happens before the purchase. It drives the product selection and maximizes ROI. Done badly, after the implementation the organization finds they bought the wrong software, and then they pay the price.

Discovering the real needs of an organization requires a disciplined methodology that actively uncovers unknown requirements, for example by reverse engineering features from competing products into requirements. Comparing products against each other is a haphazard approach to uncovering unknown requirements.

2) Vested interests

The organization is requesting vendors help them with their software decision. The problem is that vendors have a stake in the outcome and put their interests ahead of the buyer. You can hardly expect vendors to point out weak areas of their products. The hope is that when multiple vendors respond to the RFI, vendor biases will cancel each other out. However, there is no way to know this.

Another problem is that vendors do the minimum amount of work needed to secure the sale. That can cause difficulties for the buyer when the software implementation runs into snags, and unanticipated requirements remain unmet.

3) Poorly defined scope

At the start of an enterprise software selection, the scope of the problem being solved is always poorly understood. Fortunately, it is far easier to define scope when purchasing software than when writing it. Simply put, a requirement not met by any product being considered will not influence which product is selected. Thus, the scope of the problem is determined by the software that can solve it. While this may be one or a combination of software products, simpler is always better.

The step many organizations miss is to adjust the scope of the problem based on software available. Skipping this step increases the risk of purchasing the wrong software. (Think of buying a Swiss Army Knife when you really need a screwdriver.) Exploratory RFI’s like the one above are too early in the evaluation process to adjust the scope. An organization needs multiple vendors to respond to a comprehensive requirements analysis before they can properly finalize their scope.

4) Missed opportunity to maximize ROI

If an organization compares software products against each other, they can’t identify the best match for their particular needs because they have not yet discovered, defined and documented those needs. After all, if you don’t really know what you want, how will you know when you find it?

5) Benefits, not features

Software is purchased for the benefits that flow from using it, e.g. improved revenue, reduced costs, easier to use, etc. However, when comparing products, they are always compared on features. Enterprise software should be bought on benefits, not features, and those benefits flow from requirements satisfied. This goes back to measuring how well the software meets requirements.

6) Unclear objectives

When an organization compares software products against their requirements, there is a well-defined and measurable objective in mind. When comparing products against each other, that objective is not nearly as well-defined, which makes it easier to head in the wrong direction, and select the wrong software.

7) Lack of vendor response

There are many reasons why a vendor might not respond to an RFI, and when that happens an organization may overlook enterprise software that is truly best-fit. An organization needs to do the research to identify alternative products themselves.

How to solve these problems

By definition, buying best-fit enterprise software will maximize ROI. However, organizations perpetually seem to underestimate the work required to identify best-fit software. They are always tempted to take short cuts, for example, by omitting parts of the process, trying to get vendors to do some of their work and so on.

Starting an enterprise software selection with an RFI does get the project underway, but comparing products against each other is not the way to identify best-fit software. There is no getting away from it: to maximize the ROI of an enterprise software purchase, an organization must start with a comprehensive requirements analysis. Comparing software products against each other just does not cut the mustard.