We often find ourselves in a situation where new software is being introduced or an existing system is being replaced. The problem areas are known, but a concrete solution has not yet been found. When researching the market, many solutions are quickly offered, but how and according to what criteria are they best compared?
The following article describes a best practice method that we at doubleSlash have used in a customer project. There is rarely an ideal approach due to changing conditions. The selection of methods and tools will almost always depend on the General conditions of the project adapted.
Prioritized requirements as the basis for a software evaluation
The prerequisite for a software evaluation is the right Prioritization of requirements. Particularly in a time-limited process step, not all requirements can be checked for fulfillment. One Categorization according to importance (e.g. in cat. A, B and C) helps to narrow down to the most important requirements. Of course, there is a risk that a requirement is not currently fulfilled and checked, but will be required at a later stage of the project. This can be particularly serious in the case of a standard solution if no Subsequent adaptation of additional functionalities is possible. In this project, we have set ourselves the goal of Limit requirements to a number of 25 to 30. This ensured that all requirements were evaluated even in a tight timeframe. It was important to us, all "must" requirements to be included. However, the containment should always be reasonable measure to the project volume otherwise the aforementioned risk of rework increases significantly. Our project experience has shown that a solution selection Limiting the requirements to around 40 to 50 percent of the total number was found to be a healthy level.
With the selection of requirements narrowed down, the Search for a suitable software solution. In addition to the results of a Search engine it also makes sense, Market analyses (e.g. at Gartner) or the Demand within a corporate group or structure can be used. Another source is Systems already in the company. These are often preferred, even if they are inferior to purchased solutions (e.g. it is better to use Sharepoint because it is already available).
An online market search usually delivers a large number of results and should therefore be carried out in a structured manner. You can vary the search terms a lot in order to find the Examine the market from different perspectives. At the beginning a Limitation to industry, area of responsibility or functional requirements can be carried out. In a further run non-functional requirements (e.g. open source solution) to exclude possible products. We recommend first creating a collection of many providers without going into all the requirements in detail and then successively adding further requirements until you have a number of four to seven providers to reduce.
For a final evaluation of the possible solutions, we rely on a Evaluation matrix. This creates a Structured approach, maximum transparency and traceability. The Requirements are weighted against each other and the potential solutions are checked for compliance with the requirements. As a rule, the costs do not play a role in the first step, but can also be included in the comparison. In the end, however, a Detailed cost/benefit analysis This is because the best system may be significantly more expensive than the second-best system. With this approach, decisions for further action can be made successively for or against a solution.
If there is still time at the end of the evaluation phase, the solutions can be assessed on the basis of further requirements. This allows the existing result to be checked and the aforementioned risk of possible improvements can be minimized. The individual evaluation stages must be precisely defined so that the requirements can be compared at all.
Finally, two comments from the field:
Experience has shown that a standard solution never covers 100 percent of requirements. You should therefore already consider the following when selecting possible alternatives ready for compromises be. Otherwise a Individual software may be the right choice for your system requirements.
On the other hand, too many individual requirements for standard software can lead to other problems. These are usually not included in the standard support and maintenance and must be covered by special agreements. To this end, you should include maintainability, updatability and support follow-up costs in the requirements and check their fulfillment at an early stage of the project.
You can find out more about requirements analysis here
