Five ways inadequate requirements wreak havoc with enterprise software purchases

There are multiple reasons why major software purchases fail, but one of the most common is that of an inadequate requirements analysis. The problem is caused by people being unfamiliar with requirements gathering techniques, and by grossly underestimating the amount of work involved.

Requirements are to software selection as foundations are to a building. Get them wrong or leave things out and there always will be problems. This article examines the consequences of missing requirements in the analysis phase and describes how to avoid the problem in the first place.

1) Inadequate functionality

If the initial analysis misses significant requirements, there is a risk of purchasing the wrong software. If this happens, missing functionality is discovered during implementation or early production use, but at that point contracts have been signed and it is too late to do anything about it. Your only hope is that the functionality gap is not too serious, but as some of these examples show that may be a vain hope.

2) Discovering “new” requirements

Even if best-fit software was purchased, if there was an inadequate requirements analysis at the start of the project, significant “new” requirements will be discovered during implementation. This triggers meetings to rate those requirements for importance to the organization. These meetings take time to organize; they consume time, and they slow down decision-making. This exerts pressure on implementation project deadlines.

3) Implementing “new” requirements

If the organization decides the newly discovered requirements must be satisfied and the software does not meet them out-of-the-box, the implementation team must find a way to resolve the issue. Typically, they start exploring if the software can be configured to meet the requirement. If that does not provide acceptable functionality, they consider writing small amounts of code (e.g. event triggered macros or scripts), re-engineering business processes to fit the software, or purchasing add-on modules or third party products. Discovering too many “new” requirements is the primary cause of implementation delays and cost overruns.

4) Business disruption

Too many missed requirements exert pressure on project schedules and may cause some requirements to be skipped to save time. When the software goes into production this functional mismatch can seriously disrupt the business. An example of this happened at athletic shoe and apparel retailer Finish Line’s botched supply chain software implementation which resulted in a $32 million decrease in sales and cost the CEO and Chief Supply Chain Officer their jobs.

5) Unmet expectations

When new software goes into production and significant functionality is missing, users must scramble to resolve the problems. Typically, this takes the form of ad-hoc business process reengineering and it imposes significant extra work on employees. Buy-in evaporates and users start to push back against the new software. Management sees the problems and thinks “Oh no! Not again!” The CFO realizes that the ROI used to justify the software purchase will never be achieved, and will be even more skeptical of future software projects.

What can you do about it?

Requirements will be discovered during the initial requirements analysis, during the implementation or in early production use. An implementation project that starts with a comprehensive list of ALL significant requirements, who wants them, why they are wanted and how important they are, enables the project manager to create a realistic implementation plan. When no significant new requirements are discovered, the implementation is on schedule and within budget.

This begs the question: How do you discover all significant requirements? The answer is to use the technique of reverse engineering requirements from the features of potential software products, and any currently used software. Essentially it is examining the features of multiple software products and rewriting them as requirements. It is the most reliable way to discover all requirements, including unknowns.

The secret of successfully painting a building is a thorough preparation. The actual painting is only a small part of the work. Likewise, a successful enterprise software purchase requires a thorough requirements analysis. Enterprise software usually has thousands of requirements and it can take months to develop a comprehensive list. However, if this preparatory work is inadequate, you are putting the entire project at risk. If you think this is too much work, just think of how much work a failed software project entails, and what it can do to your career!