The backward way of gathering enterprise software requirements

Imagine you were moving to a new city and wanted to buy a house. You contacted a local architect and asked him to design your dream home. He interviewed each member of your family to discover needs and wants and eventually produced a set of plans. Then you took your plans and started looking for a house that met those specifications. Absurd isn’t it? And yet that is exactly the way organizations approach major software purchases like ERP.

It’s easy to see why this happens: Building software starts with user requirements and then creates the code to meet those requirements. That is how organizations have always acquired software, and the behavior has been learned. But when buying enterprise software, a better approach is to start with the products on the market and work back toward the users. If there is a need that no software product satisfies, that won’t make any difference to the selection, although it may change the scope of the project.

Returning to the example of buying a house, the right way to proceed is to contact a Realtor, give them your high-level needs and then start looking at properties. As you do this, you learn how far your budget will go, what areas you like and a host of other details. For example, if you are moving to the southwest U.S., it is relatively easy to get a home with three garages. If you are shopping around Washington, D.C., that is not so easy. When you buy a house, you use your high-level needs to select a range of properties for viewing, which forms your initial list. As you look at those properties, you learn what matters to you and you refine your requirements. For example, do you want a place with a view, or do commuting times and local schools matter more? Eventually, you narrow the range down to a shortlist and make the purchase.

When purchasing enterprise software, organizations would be wise to follow a similar approach. Start with an initial list of software products that could potentially meet the needs. Examine the features of those products and write them as requirements. This technique is like running the software development process backward and is called reverse engineering requirements from features.

Doing this across multiple products allows you to build a comprehensive set of requirements. Most important is that this technique helps you find requirements you don’t know you need. For example, a few years ago, we were working with a client in the civil engineering space who was considering project management software. At that time, some of the newer cloud vendors had software that worked on smartphones, and when the client saw this, their eyes lit up. Field access was something they had never considered. Previously, they needed to run internet connections to their site offices in the field, and that was not always practical. And then, when on site, project managers had to go back to the site office to get the information they wanted. However, with the project management software available on smartphones, they had immediate access to the information needed on the building site, and that had immense value for the client.

If requirements are not found during the initial analysis phase, they are usually found during the software implementation phase. Dealing with those “new” requirements takes time and causes schedules to slip. To reduce slipping schedules, some things get left for later. When requirements are left for later, or they are found when going live in production, it is those unmet requirements that disrupt normal business operations. The cost of not meeting those “new” requirements can be considerable. Just look at Finish Line, an Indianapolis-based athletic shoe and apparel maker who went live with supply chain software at the end of 2015. Problems cost them $32 million in lost sales, the CEO his job, and they are closing about 150 out of 617 retail stores. As a rough guideline, for every $1 not spent on requirements analysis:

• $10 is spent on extra implementation cost and delayed ROI.
• $100 is spent in business disruption costs when going live.
• $1,000 is spent in hidden costs of not meeting expectations over the life of the software.

When it comes to gathering requirements, the most cost-effective approach is to capture all significant requirements before the implementation, and the technique of reverse engineering is a powerful way of doing this. Also, requirements need to be written in enough detail so they can be implemented, which results in a much larger number of requirements than people expect. However, more detailed requirements are much faster for users to weight for importance than high-level requirements, which tend to be debated endlessly by those users. This detail will be collected anyway, whether it is done in the requirements analysis phase or the implementation phase; it just costs a lot less when collected earlier. See: “The four costs of poor software purchasing exposed!” 

Most organizations do a poor job of documenting their requirements when purchasing enterprise software. Part of the reason is they start with the users and work toward the products. Change this around and start with the products and work toward the users, and the risks of not meeting expectations with that major software purchase will go down dramatically. Not only is this good for your organization, but it is also good for your career.