The enterprise software acquisition funnel

In science, everything that is observed to happen must have a cause. Although the root cause of most problems with major software purchases can be traced to inadequate requirements, what is the cause of that problem? Why do so many organizations have inadequate requirements?  The answer is that few know how to evaluate and select enterprise software. While it looks deceptively easy, in practice it is anything but.

Anybody who has worked with sales & marketing would be familiar with the sales funnel which describes the steps needed to sell a product or service. The software acquisition funnel is similar but views the process from the perspective of the buyer rather than the seller. Note that the volume of each of the four buying phases corresponds to the amount of work in that phase, and shows that most of the work in a successful software selection is in the requirements analysis. This article looks at each part of the funnel.

Wayferry

Pre-funnel pain

Most enterprise software purchases are driven by pain:

• Growth pains: Outgrowing existing software, functional limitations, processes with too many manual steps, too many spreadsheet workarounds, too many bolt-on software products to fix specific problems.
• Obsolescence:  Increasing software support and maintenance costs, end-of-life software,  the vendor milking the product for revenue but not doing any development, the product is discontinued e.g. after the vendor is purchased by another company.
• Increasing complexity: Different silos in the organization selecting different software to solve similar problems, software functional overlaps, rogue IT, duplicated systems, e.g. after a merger or acquisition.
• Software mismatch: The software originally selected was not the best choice, and the shortcomings have become apparent with use, e.g. functional limitations, bugs, inadequate vendor support, difficult to use
• Competition: Competitors using much better software products which is giving them an advantage in the market.
• Emotion:  The perception inside the organization that current software is the cause of many business problems.

These pains drive a growing awareness that the current software has a negative impact on the business. The organization begins quantifying the problem, perhaps estimating the ROI of new software or the cost of doing nothing. This investigation may take as long as a few years, or, if urgent, as little as a few weeks. The output is a decision to replace the software, and this is where the organization enters the software acquisition funnel.

1) Requirements phase

The first phase is to decide what is needed and express this as requirements. It is the most time-consuming part of the process by far, but it is vital to get it right. The root cause of most of the pains encountered when a major software purchase goes wrong can be traced back to an inadequate requirements analysis. A comprehensive requirements analysis contains the following:

• Initial user interviews. These interviews build rapport with employees, uncover their pain points and any software products they would like considered.
• Product & vendor research identifies potential software alternatives and, where appropriate,  implementation vendors.
• Requirements libraries, especially requirements related to things like support, license terms, security, usability and so on. These requirements tend to be the same for most enterprise software purchases.
• Reverse engineering requirements from the features of potential products. This vital step helps an organization discover unknown requirements, which forces them to think through things they would otherwise have missed.
• Rate requirements for importance: document who wants each requirement, why they want it and how important it is to them. This step is critical for building employee buy-in for the new software. Eliminate requirements rated as less than important.

The output of this phase is a comprehensive requirements specification that describes what the organization is looking for. It is the standard against which competing software products will be measured.

2) Evaluation phase

This phase evaluates how well alternative software candidates meet requirements.

• Use showstopper requirements to eliminate unsuitable products.
• Use the RFI or RFP process to capture how well products meet requirements.
• Do the gap analysis and rank products by fit score. Note that spreadsheets are not suitable for the gap analysis. You need a tool like Wayferry’s app or SelectHub.
• Use the requirements scope check to verify you are not asking for more than the market can deliver.

The output of this phase is a list of software products ranked by how well they meet your particular requirements.

3) Selection phase

This phase focuses on the selection decision and verifying that everything is as expected.

• Factoring in price, select the top 3 products for demo.
• View the demonstrations. Note that the analysis makes the selection decision, and the demo confirms that decision.
• Make the provisional product selection decision.
• Audit and validate that the selected vendor was not “over-optimistic” in their RFI or RFP response.
• Check references for the product and implementation consultants or system integrator.
• Negotiate and purchase the software

The output of this phase is the purchase of the selected software product.

4) Post-purchase phase

This phase primes the implementation team for success.

• Handover the purchased product evaluation to the implementation team.
• User acceptance testing

Wrap-up

While software evaluation and selection looks deceptively easy, success remains elusive. Follow the process outlined in the software acquisition funnel above to reduce purchase risks. In addition to selecting the best-fit software, this process also builds user buy-in and ensures organizational expectations are aligned with what the selected software delivers. Best of all, you will minimize the pains so prevalent with major software purchases.