How to select enterprise software that maximizes ROI
The primary goal of an evaluation and selection project is to identify the software that best meets the needs of the organization. By definition, this has the greatest ROI. Also, the evaluation should provide the information necessary to drive down risks in the software implementation phase of the project.
The opportunity for new enterprise software doesn’t happen too often, and yet it presents a real chance for an organization to make significant improvements. With so much at stake, how do you find the cloud or off-the-shelf software most closely aligned with your particular needs This article answers that question.
Before a software selection project even starts, the first task is to estimate the ROI of the software purchase. When there are multiple projects and limited resources (sound familiar), projects with the greatest ROI can be tackled first to deliver maximum benefit to the organization. If the ROI is not estimated, there is the danger that “hot” projects of marginal value can be started. These are the first to be cut when times get difficult, wasting all the effort put into them up to that point.
Also, you need the right tools for the job. Specifically, you need a system to manage requirements, and then evaluate potential products against those requirements. Spreadsheets just do not scale up to the task of enterprise software evaluations.
Just as a building needs a good foundation to last, a successful software selection needs a thorough requirements analysis. Developing requirements that adequately capture organizational needs is critical to identifying best-fit software and maximizing ROI.
Start by meeting stakeholders, process owners, and other relevant employees to gather known requirements and any software products they want to be considered. While you can’t expect too much because most people are only aware of their pain points, these initial meetings build rapport, user buy-in and let the organization know that the project has started.
Next, search for other software that may potentially solve the problem. Although you can end up with an extensive list, those products with a poor fit are quickly eliminated later on in the process. Capturing all potentially suitable software also prevents somebody from playing politics and stalling the project by asking “Did you consider…” because you did include that product.
When developing requirements, ensure they are well written. If you can find them, existing lists of requirements from public RFPs or purchased lists can be big time savers although quality can be dubious. A critical step that captures unknown requirements is to reverse engineer features from potential products back into requirements. It is well worth the effort of front-loading requirements development. Unlike software development, when developing requirements for purchasing software you can identify all requirements before the project starts. Remember that every requirement missed at this stage will be discovered during implementation where it adds costs and delays.
The final step of this phase is to rate requirements for importance to the organization by interviewing the appropriate users. Typically, this takes the form of meetings with user teams where the requirements are presented. Here you capture how important each requirement is, to whom it is important, and why it is important to them. When users see their names and details being captured on the requirements, this continues to build buy-in.
More senior employees have a broader view of needs while those employees at lower levels are more narrowly focused. Both are important. Employees with recent experience at other companies often provide valuable input with different perspectives. If employees have been with the organization a long time, they can struggle to “look outside the box”, so you may want to consider using outside experts with experience in those areas.
Once all requirements have been rated for importance, you have a comprehensive requirements profile that adequately describes organizational needs. Potential software is evaluated against this unique standard.
Evaluating software is the step of objectively measuring how well the software meets the needs of the organization as articulated in the requirements profile. Usually, this is done by having the vendors respond to an RFI or RFP based on the requirements profile. In the evaluation phase, you are gathering information, so an RFI is better than an RFP. Take advantage of these techniques to maximize the value of RFIs or RFPs.
When the vendors return completed RFIs or RFPs, that information must be captured and then used to score the various products against your requirements profile. This step is the gap analysis, and the output is a fit score that measures how well each product meets the requirements profile.
Based on the gap analysis, rank the software by fit score and choose up to three finalists for demonstration. Using the showstopper requirements, create a demo script, and insist the vendors stick to it if they want the business. Make sure you collect feedback from demo attendees before they leave each demo.
Software demos are a tour of force through the very best the software has to offer by very persuasive sales people. Always use a software demo to confirm your decision, not to make it. After the demos are completed, make your provisional selection. To eliminate "over-optimistic" vendors, audit the RFI or RFP for the provisionally selected product to validate that the software truly does meet your requirements profile.
The final step is to check references supplied by the vendor. You can also identify other references, for example by looking for LinkedIn profiles that mention the software and reaching out to those people. For a more detailed explanation of these three steps, see this previous article.
If the provisionally selected product passes these steps, the software selection decision is confirmed. You can purchase the software confident you know exactly how well it meets your particular needs.
Information gathered in the software evaluation should be passed over to the implementation team to be used for project estimating and planning. This reduces risks and helps keep the implementation project on budget and on time.
Following this process eliminates poor purchasing caused by things like slick sales, internal politics, strong personalities, bias, groupthink and so on. Use it to find the best-fit software for your organization’s particular needs using a data-driven and auditable decision-making process. Set expectations by knowing how well the software will work for your organization before the purchase. Use the information gathered in the selection process to reduce the risk of implementation delays and costs increases.
Above all, make the most of the opportunity afforded with new enterprise software to improve the organization. If this is business-critical enterprise software, selecting the best-fit product really can make a difference to the bottom line.