Why capturing enterprise software requirements is so difficult

When purchasing enterprise software, most project failures can be traced back to faulty requirements. As we often say, requirements are to software selection as foundations are to a building. Get them wrong and there always will be problems.

Why is it so difficult to gather requirements when selecting enterprise software, and what can be done to improve the situation? Why doesn’t asking users provide all the requirements? This article attempts to answer those questions.

Why gathering requirements is so difficult

Although software development includes requirements gathering, in this article we focus on gathering requirements for the purposes of selecting cloud or off-the-shelf enterprise software.

Work underestimation

Suppose an organization has decided to replace a major software system, for example, ERP. The first item on the plan often looks something like “Gather requirements.” These two words can contain 50 percent to 75 percent of the work of selecting software. Identifying requirements for an ERP system can take anything from 6 to 24 months, and people simply underestimate the amount of work. They do not realize how important requirements are to selecting and implementing software, and why it is so important to front load requirements development.

Unknown requirements

If requirements are missed during the analysis phase of the project, they get discovered during the implementation phase. Missed requirements have significant consequences:

• When they are discovered during implementation, they cause delays and cost increases.
• Software that is not best-fit may be selected, which means the expected ROI will not be realized.
• Occasionally, missed requirements will cause outright failure, leading to the project being abandoned.

Relying on users

Some consultants contend that users are the only legitimate source of requirements, but this is simply not true. Most users know only their pain points and not much else. When an organization relies mainly on users for requirements, they are guaranteed to miss many of them.

Analysis paralysis

Analysis paralysis usually happens when the decision makers don’t have confidence in the process for identifying and selecting the software. They keep going back to the requirements, looking at the problem from different angles, and wondering what they have missed. They are afraid of making a mistake, which can damage their company and their careers. So rather than commit, they keep extending the requirements analysis.

Inadequate requirements

Sometimes in their rush to complete underestimated projects, organizations take shortcuts when developing requirements. To select best-fit software, requirements need to be specified in enough detail and to be well written.

Gathering requirements

There are essentially four ways to gather requirements, each with its strengths and limitations. Of these, three apply when selecting software. Typically, requirements gathering tasks proceed in the order listed below.

1 – Asking users

Broadly speaking there are two types of enterprise software users, each with different perspectives on requirements. Both perspectives are necessary, and some employees are a blend of each.

• Hands-on users. These are people who use the software on a daily basis, and it forms a critical part of their job. They will often have strong and detailed opinions, but a narrow focus. The best-fit software can make them much more efficient in their jobs.
• Management users. These people tend to have a broader perspective of requirements, especially future requirements, and how the requirements relate to the organization.

If there are any employees who have used one or more of the potential software products while at previous jobs, they can provide valuable input, particularly if that experience is relatively recent.

While asking users for their requirements is important, it is very slow and for most people limited to their pain points. A far more efficient process is to present those users with a pre-developed list of requirements and ask the users to rate them for importance to their jobs.

The primary benefit of asking users for their requirements is that it lets the organization know the software evaluation and selection project has started. If external consultants are used for gathering requirements, this is also an opportunity for them to build rapport with the users.

2 – Business process analysis

Business process analysis is a critical source of requirements when designing software, and usually it is followed by business process optimization. After all, this is the time to eliminate unnecessary steps in getting the work done. When developing software, only the most efficient business processes should be coded.

However, when buying software, business process analysis and optimization are unnecessary. Gathering requirements is already painful enough without this added burden. The analysis and optimization should rather be done in the implementation phase of the project.

Also, the purchased software may have best practices that, if followed, would make the business process analysis and optimization unnecessary in many cases. Because best practices are often software specific, you won’t know them until the software is selected. For the purposes of buying software, all you need to know is how well the potential software can perform those business processes (i.e. fully meets, mostly meets, partly meets, etc.) If you need to know how the processes should be performed, you have not specified your requirements in enough detail.

3 – External sources

External sources of requirements range from finding RFPs on the web, getting requirements from colleagues who have done similar projects or buying requirements libraries from vendors. Included in external sources are experienced consultants who already have lists of requirements that they have used for similar projects. In all cases, the quality of external requirements can vary tremendously, and it should be verified that they are well written. If you can buy requirements, do so, because that is the fastest and most economical way to develop a list of requirements.

4 – Reverse engineering

This is the process of taking features from potential software products and reverse engineering them back into requirements. Essentially, you are running the software development process backward. It is a very robust process because it finds requirements the organization does not know they need. It also ensures the latest innovations on the market are considered. Typically, this information comes from software product user documentation and software demo videos.

Business-critical enterprise software is usually used by multiple departments in an organization, and this means requirements can number in the thousands. Reverse engineering requirements is slow, for example, it can take between 150 to 250 hours of work per thousand requirements generated.

Conclusion

Once a comprehensive list of requirements has been gathered, they must be rated for importance to the organization. This essential step documents who wants each requirement, why they want it and how important it is to them. Asking users to rate requirements for importance and capturing their names on those requirements builds tremendous buy-in to the project. Rating them also allows requirements that are less than important to be eliminated, e.g. those that are “nice to have,” “useful” or of “no interest.”

After completing this step, you have a comprehensive requirements profile that describes the organization’s particular needs in adequate detail. This is the organization’s unique standard, and all potential software products are compared against it. This gap analysis is the key to identifying the best-fit software that will maximize ROI. When you think that the TCO of enterprise software often runs into the tens of millions or more, maximizing that ROI will make a significant difference to the bottom line.