The payoff from a rigorous software selection

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?

The 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? This article provides some answers to that question.

Reduced implementation costs

Whether 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.

One of the biggest causes of delays and corresponding cost overruns with major software purchases is discovering “new” 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 configuration, add-on modules, 3rd party products, developing code or even business process re-engineering. All this extra work takes time, and discovering too many “new” requirements is what causes a 9-month implementation project to turn into a two-year nightmare.

Build end-user buy-in

If 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:

Project kickoff meeting which formally alerts the organization that the project has started.

Initial user meetings to 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.

Rating 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.

Software demonstrations typically have up to three products selected. When you capture and summarize user feedback and comments, again they feel the organization is listening to them.

Executive sponsorship

A 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’t 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:

Opponents 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.

Set expectations

No 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’s remorse.

Set a realistic scope

It 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’t 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.

Buy on value

Buying 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.

Handover

The handover primes the implementation team for success. If the requirements analysis was done properly, no significant new requirements are uncovered during implementation. When the implementation project managers sees, for example, all the requirements that need configuration, it helps them to plan the software implementation accurately.

User acceptance testing

A thorough and comprehensive requirements analysis can provide the basis for developing user acceptance tests.

Traceability

Sometimes 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.

After 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 and 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).

Conclusion

A formal software evaluation & selection project is a lot of work up front, and you may be accused of “analysis paralysis”. 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 and maximizing the gains.