9 ways front-loading requirements can reduce enterprise software risk

An adequate requirements analysis is the foundation for a successful enterprise software implementation. However, it can take hundreds or even thousands of hours to develop requirements for large software projects. Is it worth spending that time on the requirements analysis up front?

Surprising as it may seem, there are at least nine different ways to use a thorough requirements analysis when purchasing enterprise software. This article makes the case for properly developing requirements up front. It considers the different ways requirements can be used to reduce software selection risks and accelerate implementations leading to successful software deployments.

1) Develop business direction

Today, while software is an engine that drives business, organizations have become constrained by that same software. Replacing it can open up new avenues of business previously unavailable due to limitations of the old system. After an organization decides to replace software, they start with a view of their problems framed in terms of their experience. Their challenge is to “think outside the box” to avoid losing the opportunities opened up by new software.

When it comes to selecting enterprise software, one of the best ways to “think outside the box” is to use potential products to expand the understanding of what is available. For example, a feature set from the new software can open up a whole line of business that was not practical before. The most effective way to break through limitations imposed by experience is to reverse engineer features from multiple software products back into requirements. As the organization examines features from potential products, they see new possibilities. After identifying those possibilities, they are evaluated and factored into business plans.

2) Answer the build or buy question

Many organizations face the build or buy dilemma. They are tempted to code software themselves, but continually underestimate the effort, risk, and cost. If an organization writes software, they bear the entire cost. With off-the-shelf or cloud software, development and maintenance costs are amortized over multiple customers. If you can find software that has a good enough fit with your needs, that is always cheaper than writing the software yourself. The question boils down to measuring the fit of potential software products to answer the build or buy question.

First, develop a comprehensive requirements profile, and then do the gap analysis. Where a fit score of 100 percent indicates all requirements are fully satisfied:

• If several products have fit scores of over 80 percent, then buying is the correct decision.
• If fit scores are in the 60 percent to 80 percent range and nothing higher, consider combining several software products or reducing the project scope (or both). This can dramatically boost fit scores although there are always costs for getting different software packages communicating with each other.
• With scope reduced, and combinations of products considered, if nothing has fit scores over 60 percent, consider developing the software (or not doing the project at all).

Building software is an expensive and risky proposition, especially when that software is not in your core line of business. It is always better to buy software if you can. A gap analysis based on a comprehensive set of requirements can provide a quantitative, data-driven answer to the build vs. buy question.

3) Build user buy-In

One cause of enterprise software failures is a lack of user buy-in. An effective way to get buy-in is to involve users with developing requirements. Traditionally this starts with interviews of the appropriate people. Unfortunately, most people only know their immediate pain points, and few think far enough “outside the box” when trying to come up with new requirements. Developing requirements with a team is also an excruciatingly slow process.

After all the usual requirements development approaches have been exhausted, use the technique of reverse engineering to flesh out a comprehensive list of requirements. Ensure you capture requirements in enough detail. Once your requirements list is complete, have users rate the requirements for importance to them. Capture who each requirement is important to, why it is important and how important it is. When users see their details written on the requirements, they feel they have been heard, and that builds the buy-in so essential for a successful deployment.

4) Select best-fit software

Requirements are to software selections as foundations are to buildings. If they are inadequate, there are always problems. The most significant use of requirements is to select the best-fit software for your particular needs, which is critical to maximizing ROI. Instead of a rational data-driven decision, an inadequate requirements analysis leads to software selection decisions driven by skilled sales teams, emotions, vested interests, etc.  When it comes to something as complicated as selecting enterprise software, this is a sure recipe for failure.

To avoid this problem, develop an adequate list of requirements in enough detail. Score software products against your requirements profile to rank them by fit score. Use this to select the software that best fits your particular needs. A rational decision based on a quantitative, data-driven analysis leads to software purchases where the expected ROI can be met or exceeded.

5) Validate vendor responses

To collect the information needed for evaluating enterprise software, organizations ask vendors to respond to RFIs or RFPs. The software buyer is relying on realistic responses, but aggressive vendors can be “over-optimistic”. During implementation, the buyer finds the software can’t do what was promised, and workarounds must be developed, which are a prime cause of delays and cost over-runs. Unfortunately, by this stage it is too late to do anything about it.

These wrong vendor responses must be found and corrected before purchasing the software. This problem is solved by auditing the RFI or RFP of the selected software to validate it against the requirements profile. If the fit score drops too far and the validation fails, a different software product can be selected, and a huge problem will have been avoided.

6) Set user expectations

We have all experienced buyer’s remorse when a highly anticipated purchase turned out to be a major disappointment. The same thing can happen when buying enterprise software. While the selected product may excel in most areas, it will be weak in a few places. No system is a perfect fit, and if expectations are too high, end users experience buyer’s remorse.

When the project team signs off against the selected product gap analysis, their expectations are aligned with what the software delivers. Realistic expectations help with user buy-in because nobody is unpleasantly surprised during implementation and subsequent production. Users can always go back to the evaluation to see that the selected product was indeed the best fit for the organization, even if it is weak in a few areas. Knowing these weaknesses before the purchase helps set realistic user expectations.

7) Accelerate software implementation

Outright or partial failures occur regularly with both cloud and off-the-shelf software, and sometimes these disasters surface in the technical press. When reading between the lines of these news reports, a lack of adequate requirements seems to play a large role.

Software requirements are a primary means of detailed communication between the future system users and the team implementing that new system. For example, if a requirement calls for a particular kind of report, knowing what the report will be used for is vital for correctly configuring it. Knowing how important it is to the organization helps estimate time. If more detail is needed, knowing to whom the report is important allows the consultant to reach that person for clarification.

When the implementation consultants know what is required, who wants it, why they want it and how important it is to them, they have the basis needed for a successful implementation. An adequate requirements specification provides vital input to the software implementation plan, accelerating the implementation process and reducing risks and costs.

8) Reduce implementation surprises

Possibly one of the biggest causes of delays when implementing software is discovering that certain requirements are not adequately met. These surprises mean workarounds must be developed, which leads to delays and increased costs.

If the software selection is backed by a detailed enough requirements analysis, those weak areas are known before the purchase and can be planned for in the implementation. When that planning is done up front, unpleasant surprises are reduced or eliminated. Implementations are on time and within budget.

9) User acceptance testing

Software failures occasionally end up in court where the software purchaser sues the vendor. Usually the basis of the lawsuit is that the software did not meet the requirements.

An adequate requirements profile is the basis for functional and user tests. As part of the customer acceptance, the software is tested against these requirements. If it passes and still can’t be used then the requirements were at fault. The software purchaser must pay to fix the problem. They are at the vendor’s mercy, and things get very expensive. The only way to avoid this problem is to develop adequate requirements in the first place. On the other hand, if the software fails customer acceptance testing against requirements, the vendor is at fault and must remedy the situation at their cost.

When things go wrong with software implementations, an adequate set of requirements puts the customer in a much stronger position when trying to resolve problems with the vendor. Adequate requirements can also help avoid the costs of an expensive lawsuit.

Conclusion

When implementing enterprise software, requirements will be fleshed out in detail whether this is done at the start of the project or during the implementation phase. Given that the work will be done sooner or later, we have made the case that front-loading the requirements development significantly reduces project risks and improves the probability for a successful software deployment.

Acknowledgment

This article is an updated version of a white paper originally published by Wayferry.