Rigorous software evaluations are a lot of work, and the payback only comes once the new software has been in production for a while. With a major software purchase, that can be months or years in the future. So what are the benefits of doing all this work?\nThe primary advantage of a rigorous evaluation and selection process is that you identify the software that best meets your particular needs. By definition, this software will return the greatest ROI. However, although a rigorous process minimizes the risk of selecting the wrong software, it is possible to select best-fit software by experience or even sheer luck. What, then, are the other benefits of doing all this upfront work?\u00a0This article provides some answers to that question.\nReduced implementation costs\nWhether it is done during requirements analysis, implementation or even early production, eventually all requirements are discovered. The difference is that the earlier they are found, the less they cost to satisfy.\nOne of the biggest causes of delays and corresponding cost overruns with major software purchases is discovering \u201cnew\u201d requirements during implementation when they should have been found during the requirements analysis phase. If these requirements can't be met out-of-the-box, then the implementation team attempts to satisfy them with system\u00a0configuration, add-on modules, 3rd party products, developing code or even business process re-engineering. All this extra work takes time, and discovering too many \u201cnew\u201d requirements is what causes a 9-month implementation project to turn into a two-year nightmare.\nBuild end-user buy-in\nIf users resist the new software, the project is in serious trouble. The best time to nurture buy-in is to involve users in the selection process. There are four touchpoints where users can be converted into project advocates:\nProject kickoff meeting which\u00a0formally alerts the organization that the project has started.\nInitial user meetings\u00a0to gather requirements and potential products for consideration. Unfortunately, few users have any idea of what they want beyond their pain points so don't expect too much. However, the real purpose of these meetings is to build rapport with those users.\nRating requirements for importance. You convene meetings with appropriate groups of users and for each requirement ask who wants it, why they want it and how important it is to them. When users see their names and comments captured on requirements, they feel the organization is listening to them, and that is key to building their buy-in.\nSoftware demonstrations\u00a0typically have up to three products selected. When you capture and summarize user feedback and comments,\u00a0again they feel the organization is listening to them.\nExecutive sponsorship\nA common problem with failed software implementation is a lack of involvement from executive sponsors. Even when those executives know the new software is critical to the organization, if they don\u2019t take an active interest the project is doomed. If there is no executive stomach for a rigorous evaluation and selection process, you will have exposed a serious risk early on, which can allow the project to be halted before the purchase is made. For a real life example of this problem with an unhappy ending, see this article written by Michael Krigsman under the heading Understanding the numbers:\n\nOpponents to the [new] SAP-based system implemented at Marin County are clearly aligned around getting rid of it as quickly as possible. But it appears the County may never have accepted responsibility for making it work in the first place. In fact, my reading of the agreement with Deloitte seems to indicate the County was trying to cede its responsibilities to Deloitte. Responsibility without authority, however, always yields outcomes similar to what we see here [i.e. failure] in complex systems projects.\n\nSet expectations\nNo product is perfect, and all software purchases involve compromise. When users know those compromises before the purchase is made, their expectations are aligned with what the software delivers, and there is no buyer\u2019s remorse.\nSet a realistic scope\nIt is tempting to buy a product that meets all your needs, but the question is how well does it meet those needs? You want to avoid buying a product that can do everything but isn\u2019t very good at anything. Measuring how well multiple products meet your particular requirements allows you to make a data-driven decision about what should be in and out of scope.\nBuy on value\nBuying the cheapest software or the favored product can be tempting. When you measure how well competing products meet your particular needs, you can purchase the one with the highest value to the organization, which might not be the originally favored product.\nHandover\nThe handover primes the implementation\u00a0team for success. If the requirements analysis was done properly, no significant new requirements are uncovered during implementation. When the implementation project managers sees,\u00a0for example, all the requirements that need configuration, it helps them to plan the software implementation\u00a0accurately.\nUser acceptance testing\nA thorough and comprehensive requirements analysis can provide the basis for developing user acceptance tests.\nTraceability\nSometimes the board, regulatory bodies, taxpayers, etc. may question why a particular software product was purchased. A data-driven decision allows full traceability from the product selection all the way back to the requirements, who wants them and why they were wanted.\nAfter going live, some users might claim the wrong software was bought. Very often these people didn't bother to take part in the selection process\u00a0and think their favorite software would have been a better fit. When this happens, you can point them to a data-driven software evaluation and selection (and even ask them how they would have improved the process).\nConclusion\nA formal software evaluation & selection project is a lot of work up front, and you may be accused of \u201canalysis paralysis\u201d. That charge is certainly not true if you follow a well-defined process. As this article shows, the up-front preparation before making a major software purchase has numerous benefits, ultimately reducing risks, minimizing the pains associated with software purchases\u00a0and maximizing the gains.