How to keep requirements wish lists from crippling software purchases

When an organization recognizes they have outgrown their software or that it has become obsolete, they may decide it is time to replace it. When these projects start, there is only a fuzzy picture of the general needs. The purpose of the requirements discovery process is to bring those needs into sharp focus where they can be expressed as specific requirements. In particular, the discovery process must uncover requirements the organization does not know they need. Significant requirements missed during discovery can cause sub-optimum software to be selected. Even if best-fit software was purchased, too many “new” requirements uncovered during implementation can cause project delays and unexpected costs.

It is good practice to start these projects by asking users for their requirements because this develops a rapport with them and helps create buy-in. Some consultants believe that users are the only true source of requirements, but this fails because although users know their pain points with the existing system, most don’t know much beyond that. When purchasing software (as opposed to coding it) a better process is to develop a comprehensive list of requirements for that problem domain, and then get the users to rate those requirements for importance. This process creates the Requirements Profile, the unique organizational standard against which potential software products will be evaluated.

While several approaches can be used to develop a comprehensive list of requirements, one of the best is to use the reverse engineering technique. Here the features of multiple potential products are examined, and requirements are written that will be satisfied by those features. This is essentially running the software development process in reverse and is the best way of discovering unknown requirements when purchasing software.

Managing wish lists

The thought of new software can cause some users to seize the opportunity to satisfy their wish list. They start with “Wouldn’t it be great if…” , and sometimes want features that do not exist in any software product. Wish lists can lead to scope creep which is particularly common in larger software projects like ERP. How are user “wish lists” best managed, especially if they are the wishes of Executive VPs?

Very often requirements on the wish lists are “nice to have”, but sometimes there are valid business reasons behind them. To eliminate the “nice to have” requirements, users must rate them for importance. For each requirement capture who wants it, why they want it and how important it is to them. Forcing somebody to articulate why they want a particular requirement is often enough to make them realize it isn’t that important. After rating all requirements, those that are less than “important” can be ignored when selecting the software.

Unsatisfied requirements

If you did a thorough job reverse engineering requirements from features, you can know when you have captured all requirements relevant to that particular problem domain. What happens when there are valid requirements that no product satisfies? If you are going ahead with the purchase, those requirements are not going to make any difference to the product selection. Enterprise software often has thousands of requirements, and there is always going to be some compromise.

It is possible that those unmet requirements may cause the organization to reconsider the purchasing decision. After all, the existing software may not be that bad, and replacing it without satisfying those requirements may not deliver enough value to justify the project. To answer that question you need to estimate the ROI of the project with and without those requirements being satisfied. There always is some compromise; the question is just how much you are prepared to tolerate.

What happens when some products satisfy different requirements, but no one product does all of them well enough? You want to avoid purchasing software that does everything but isn’t particularly good at anything. This is why you must score RFIs / RFPs against your requirements profile. If you find no product scores well enough, then you need to reduce the project scope. For example, if you were looking at ERP systems and found none of them had an adequate CRM module for your particular needs, you would reduce the project scope to exclude CRM, and then use a different product for the CRM.

Coding instead of purchasing

Even if you think you need to code software because nothing will adequately satisfy your particular requirements, it is usually a good idea to start a major software project with an evaluation. Rather than relying on feelings and opinions, you will make a data-driven build or buy decision. If you do indeed decide to build, you will already have a comprehensive list of requirements (although they will need expanding because you are coding the software.)

As a rule of thumb, you should only develop code if it will give you a competitive advantage in the marketplace. Take Netflix as an example. They developed custom code for users to manage and play movies. However, when it came to things like accounting, HR, etc. they purchased software because that was a more economical solution. If you do decide to build rather than to buy, consider writing the new software on a platform product, as opposed to creating it from scratch. For example, FinancialForce ERP demonstrates the versatility of the SalesForce PaaS.

Wrap up

When it comes to enterprise software, no one product will satisfy all needs, and some users may have requirements not satisfied by any software product. The art is in selecting the best compromise for your organization’s particular needs, which is why the evaluation process is so important. Instead of asking users what they want, keeping them focused on requirements that can be satisfied by software products in the market is an effective way of keeping wish lists under control.