How to Eliminate the Risk of Selecting the Wrong Software Product

In forums, you may stumble on statements like this: "I have not found a way to do this either. This seems like such a basic function of a CRM. [...] I didn't even look into this before choosing over . I think we may be switching to if I can not find a way to do this."

Learning by experience is not always a good thing. Sometimes, it involves waste of time and money.

More often than not, the need to perform a systematic software evaluation is not recognized. There is no defined evaluation process and no systematic decision making method is used. To a large extent, the outcome of a software evaluation is based on subjective judgement. While this approach may produce reliable results, the risk of having to revise a decision sometime later is considerably high.

Is there an approach that allows you to achieve maximum results with least effort? Yes, there is.

To minimize effort, the recommendation is to perform the evaluation process twice. In the first instantiation of the process, your focus will be on the most critical requirements. You identify the requirements that MUST be fully satisfied in the following domains:

• Business partner-related requirements;

• Functional (behavioral) requirements;

• Non-functional (non-behavioral) requirements.

Business partner-related requirements encompass requirements that you expect software vendors to meet (e.g. vendor shall have been in business for at least one year, vendor shall be able to offer 24/7 first level support, etc.).

Functional requirements focus on features, while non-functional requirements primarily address quality aspects (they are often called qualities of a system).

The requirements that you have identified make up the core of your evaluation specification.

Supporting Tools

Your first goal is to come up with a list of software products that are worth more serious consideration when it comes to actual software evaluation.

You may want to use an Excel spreadsheet to support product comparison. Now, you would need to devise requirements that any software product that you will consider for serious evaluation is expected to meet.

A tool would be very useful, which lets you create an evaluation specification by importing ready-to-use requirements from a repository via drag & drop. Furthermore, the tool should be able to generate an Excel spreadsheet with aggregation formulas already in place. Ideally, you would only need to assign points to software product characteristics.

The Evaluation Specification Editor (ESEdit) – Content Provider Edition meets those needs. You create an evaluation specification and import requirements from the repository. Of course, you can manually add requirements in case a requirement does not exist in the repository.

When you are finished with your evaluation specification you can generate an evaluation spreadsheet. You can open it in any spreadsheet tool that can understand Microsoft's Excel file format.