Why most enterprise software projects should start with an evaluation

Sometimes organizations assume their business needs are so specific that no software on the market will adequately satisfy their requirements. They jump right into software development, but this can be a huge mistake as it always costs far more than expected. There is also a substantial risk with no way to ensure that homegrown software will adequately satisfy the business needs.

Here are a number of reasons why it is best to start such a project by investigating what is available on the market, even if the ultimate outcome is a decision to develop the software.

Complete requirements

When it comes to software, business users are very good at saying what they don’t want, especially when new software is put in front of them. At that point, it is usually too late to do anything about it, and money may have been wasted (this applies to both bought and custom software). Unfortunately, apart from immediate pain points, users generally have very little idea of what they do want. This is one reason why agile software development works so well, namely that it provides a framework for users to see what they do want.

The last thing an organization needs is to develop software based on user requirements, only to find that when the software goes into production there are other areas of the business problem that are not addressed. The users didn’t say anything about those areas because they weren’t asked.

One of the most powerful techniques for developing a comprehensive list of requirements is by reverse engineering features from several potential products. Essentially this is running the software development process in reverse. Using this technique, you can develop a complete list of requirements for that problem space. Examining the features of potential products also provides a framework to define the structure of the list of requirements, saving you from creating this from scratch.

Then get the users to rate the requirements for importance to them, which creates the requirements profile. For each requirement, capture who wants it, why they want it and how important it is to them on the requirements themselves. Ensure the users see their names and details recorded on “their” requirements because this builds buy-in, which helps tremendously with the ultimate rollout to production. Also in more regulated environments, this provides the traceability matrix.

Business process analysis

While process analysis and optimization are critical when developing software, it is not necessary when buying software because the processes are already built into the software that will be purchased. When you use the technique of reverse engineering and analyze potential software, you are looking at processes developed by others, rather than having to analyze and optimize your own processes. Looking at several potential products provides an idea of typical processes. This means critical parts of those processes are not missed when developing the requirements specification, something that is all too easy to do.

Another benefit is that you see features and requirements that your organization may not have otherwise considered, but still reflect very real business needs. These can be captured in the requirements list, ensuring you completely cover the problem space.

Terminology

Organizations are very fond of developing their own terminology, acronyms and so on that eventually morphs into an internal language. New employees must learn this language adding to onboarding costs. If you develop requirements based on potential products, you can adopt the terminology used in industry, and there is no need to invent your own. Using standard terminology can reduce new employee onboarding costs and communication errors with customers and vendors.

Conclusion

Once you have a comprehensive requirements profile, you can do a gap analysis between the software products and that profile. If you use a rating scale where a 100 percent fit score means a perfect fit with the requirements you will know precisely how well each of those products will work for you. For example, if you have a few products that have a fit score of greater than 80 percent, they will adequately satisfy your needs.

On the other hand, if no software products score more than 60 percent, there are questions to ask:

• Is there a reasonable combination of products that would give you a fit score in the region of 80 percent?
• By adjusting the scope and removing certain requirements, could you push the fit score close to 80 percent?
• Could you increase the fit score to near 80 percent by writing a small add-on module that is combined with one primary software product?

If the answer to these questions is negative, then you know that writing the software is a realistic solution in this particular case. Now here is the really nice part: you already have an extensive list of requirements. You may need to flesh out a few areas, especially in terms of process analysis and optimization, but the project will start with a very comprehensive list that the business analysts can use. Remember that starting with an extensive list of requirements keeps the cost of software development under control because this decreases the number of change orders later on in the project.

Some time ago, Marc Andreessen said that software is eating the world. One aspect of his observation is that the rate of innovation is steadily increasing. Even if you looked as recently as 2 or 3 years ago and didn’t find any suitable software, there is a very real chance that something now exists, especially in the cloud. All you need do is to find that software, and measure how well it meets your needs. For these reasons, it makes sense to start any enterprise software project with an evaluation of potential products, even if your organization does end up writing the software.