How to optimize requirements scope when purchasing enterprise software

Organizations buy enterprise software for the benefits that accrue from using it, and those benefits are realized from the features of the software. Requirements are used to define the desired features, and there is always the temptation to expand the list of requirements so the new software will do more. However, this increases costs and risks.

When buying enterprise software the question becomes one of defining an optimum set of requirements that can be realistically satisfied by software available on the market. This article explains a method of doing this.

Requirements scope

When buying enterprise software defining the scope of requirements can be very challenging. For example if an organization is thinking of an intranet, what should they include? Possibilities are content management, collaboration tools, file sharing, corporate directory and many others. When looking at something like ERP, should the proposed new system include HRIS, Supply chain management, CRM and so on?

All enterprise software systems have edges or boundaries to their functionality and need to interface with other systems. The difficulty is deciding where those boundaries should lie. Often existing systems can help you decide. For example if a company already uses Salesforce, it is unlikely that CRM functionality would affect the selection of a new ERP system.

The first step in a new software project is to develop a requirements profile that adequately defines organizational needs. The key to doing this is using the technique of reverse engineering features from potential products into requirements, which also discovers requirements the organization does not know they need.

Next is the gap analysis to measure how well potential products meet the requirements. If you use a scoring system where a fit score of 100% means every requirement is fully met out of the box, you can verify the requirements scope of the project. If there are:

• Several potential products with a fit score of over 85 percent, this means the requirements scope is well matched to what the market can provide.
• No potential products with a fit score of 65 percent or more, this means the requirements scope is not aligned with the market.

Bear in mind, when you are buying software, you are restricted to what the market can provide. By using a system that measures how well potential software products meet requirements, you see how closely those requirements are aligned with what the market can deliver. If the fit scores are high enough, you can proceed with the purchase. However, if the fit scores are too low, the scope of the requirements needs adjustment.

Adjusting requirements scope

When there are no products on the market close enough to the desired requirements, you need to find a way to boost fits scores relative to those requirements.

1) More expensive software

It may be that to stay within budget, more expensive software products were not considered. If those products do adequately meet needs while cheaper ones do not, then they are worth considering. For example, if a midsized organization was considering mid-range CRM software, but nothing scored well enough, they could find that a high-end product like Salesforce would be a better choice. To help decide if it is worth spending the extra, they need to estimate the ROI.

2) Versions

Very common in the cloud, a vendor may have multiple versions of a product, e.g. basic, business and enterprise accounts. Evaluating versions that are more expensive may increase fit scores to acceptable levels.

3) Add-on modules or products

Very often, a vendor has their own or 3^rd party modules that can be added to the product, for example, think of adding something like Crystal Reports. Adding one or more modules or 3^rd party products may increase fit scores to acceptable levels.

4) Combinations of software

You may find that no one product adequately meets requirements, but a combination of two or more products does. If you decide to go this route, verify that the product interfaces are up to the task of seamlessly exchanging information.

5) Reduce scope

Here you eliminate requirements to reduce scope, which can boost fit scores. For example, one of our clients was looking at Clinical Trials Management Systems and wanted the solution to include document management software that met FDA requirements. All the products they considered included rudimentary document management, but none was good enough. The solution was to remove document management requirements from the scope.

6) Reduce scope with code

Sometimes no software on the market meets needs because of a few showstopper requirements. By writing a small amount of code, these requirements can be satisfied. For example, take construction cost estimation software, which typically gets item costs from industry databases. In one case, a client wanted their estimators to use historical cost information from RFPs rather than using the industry databases. Since code had to be written to import the cost information, adding functionality to that import code to manage the historical price information was worth considering.

Conclusion

New enterprise software project risks are significantly reduced when the scope of the requirements are well matched to potential software on the market. To achieve that match, it is sometimes necessary to adjust the scope of the requirements.

With appropriate communication, employee expectations of the new software are well matched to what the software actually delivers, which also improves user buy-in.