When to keep, upgrade or replace enterprise software

Suppose needs have changed and existing software is no longer a good fit. Maybe the current software version is getting too old. Perhaps it’s time to consider the cloud. How do you decide if enterprise software should be kept, upgraded or replaced? Ultimately, it boils down to how well the current software meets organizational requirements, compared to how well the upgraded or replacement software would meet those same requirements.

Like any enterprise software project, properly defining requirements is key to satisfying needs. Ultimately, a comprehensive requirements analysis is the foundation for success when deciding to keep, upgrade or replace that software.

Develop Requirements

The first step in any enterprise software project is defining requirements. There are two parts to this: creating a list of requirements, and then rating those requirements for importance. Together they form the requirements profile, which is unique to any organization.

There are two aspects to the list of requirements, namely breadth and depth. Breadth refers to the functional areas covered by the software, and can be adjusted as the project proceeds. Depth refers to how much detail the requirements contain. A comprehensive requirements profile has both adequate breadth and depth.

Typically, when considering replacing an existing enterprise software product, that software covers much of the desired functionality. Use the technique of reverse engineering features from the existing software to create the initial requirements list. Then use this same reverse engineering technique on the updated version of the software and potential replacement products to round out the requirements list. This essential step captures the latest innovations on the market, and requirements you don’t know you need.

Once you have a comprehensive list of requirements, rate them for importance to the organization. Here you gather who wants each requirement, why they want it and how important it is to them. This crucial step creates a requirements profile unique to the organization. An inadequate requirements profile is possibly the largest single cause of problems when selecting enterprise software.

The RFI

Once a comprehensive requirements profile is complete, it is used to create the RFI. The purpose of the RFI is to discover how well potential products meet the requirements profile, and compare them with the existing software. This is the core of deciding if, and when, enterprise software should be replaced.

From a vendor perspective, RFIs can be a lot of work with little chance of business because at this stage a decision to replace the software has not even been made. However, vendor input is needed to make the decision. To ensure a better response from vendors, make things as easy as possible for them. 

For example, write requirements so they can be answered by selecting from a drop down list. See product rating scale below. At this stage, vendor comments on each requirement are not necessary so don’t ask for them. To further reduce vendor work, limit the RFI to just showstopper requirements, usually about 10 percent to 20 percent of all requirements. RFIs based on showstopper requirements allow potential software products to be shortlisted; the detailed analysis can wait for the RFP. The less work for the vendor, the more likely they are to respond.

Wayferry

When vendors return RFIs, capture that information in a system that can measure how well software meets the requirements profile in one number. We call this number the Fit Score and use it to rank the different software products. For a more meaningful comparison of RFIs, the scoring system should be designed so that software that “fully meets” all requirements scores 100 percent.

The Decision

Once you have Fit Scores for each product, including the existing software, you have reached the point where you can answer the keep, upgrade or replace question. Here you compare products against the Requirements Profile, each other and the existing software. For example, If existing software scores 65 percent, the upgraded version 75 percent and the best replacement 85 percent, you have a good case for replacing the existing software. Alternatively if the existing software scores 75 percent and the best replacement product 80 percent, you may conclude that the existing product will be adequate for a few more years. By then continuing improvements should have widened the gap.

The keep, upgrade or replace question is answered by measuring and ranking the existing software, the upgrade, and potential replacement products against the organization’s unique requirements profile. If the decision is made to replace, this is an opportunity to maximize ROI by selecting best-fit software. Note that if you decide to keep the existing software for a few more years, make sure the evaluation is saved so that when the process is restarted, only an update is needed.