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:\nThe 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.\nThe issue here is that enterprise software products are compared relative to each other, rather than being compared\u00a0against organizational requirements. Relative comparisons between enterprise software products will lead to the following problems:\n1) Unknown requirements\nEvery enterprise software selection is a journey where the organization discovers what they truly need. You can see the journey hinted at in the phrase \u201c\u2026 determine the optimum direction for our organization.\u201d Done properly this discovery of needs happens before the purchase. It drives the product selection\u00a0and maximizes ROI. Done badly, after the implementation the organization finds they bought the wrong software, and then they pay the price.\nDiscovering 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.\n2) Vested interests\nThe 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.\nAnother 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.\n3) Poorly defined scope\nAt 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.\nThe 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\u2019s 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.\n4) Missed opportunity to maximize ROI\nIf an organization compares software products against each other, they can\u2019t identify the best match for their particular needs because they have not yet discovered, defined and documented those needs. After all, if you don\u2019t really know what you want, how will you know when you find it?\n5) Benefits, not features\nSoftware 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.\n6) Unclear objectives\nWhen 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\u00a0is not nearly as well-defined, which makes it easier to head in the wrong direction, and select the wrong software.\n7) Lack of vendor response\nThere 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.\nHow to solve these problems\nBy 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.\nStarting 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\u00a0of an enterprise software purchase, an organization must start with a comprehensive requirements analysis. Comparing\u00a0software products against each other just does not cut the mustard.