Software Selection Decisions

Software selection decisions are not literally “regular” for managers and their employees in supporting functional areas, but they certainly occur from time to time. For example, a self-made IT solution should be transformed into a solid standard. Or paperwork produced with office solutions on a “network drive” is to be abolished. Newly created management and technical concepts should be automated and, above all, implemented “digitally”. Or the “actually good” solution introduced many years ago, which more or less covers current requirements, is no longer being developed or maintained by your manufacturer – a situation that is unacceptable, especially for important business processes.

Let’s stay with decisions on business processes that are critical for success, such as solutions for the management of online shops, for personnel management or corporate control. In order to be able to make the “right” decision for the automation of such processes, a mature set of methodical instruments should be available in-house or on the market. In fact, numerous standard software selection processes can be researched without any problems, which as a rule are at least not dissimilar to the one shown here as an example:

Typical standard software selection process

To the textbook-like software selection process:

In the example process shown, a “longlist” is initially assumed, which in principle can include all products available on the respective market. To reduce the longlist, specific criteria are now defined and weighted to represent the requirements of the product in its intended state. The degree to which these requirements are met is determined in the next step. This can be done for example by means of

• Online research on the products in focus
• Questionnaires that are sent to the providers
  
• Use of studies or involvement of experts from specialised institutes and service providers
  

From the determined degrees of fulfillment and weightings of the requirements, a ranking of the products is calculated as the result of a basically “mathematical approach”. The products “in the top positions of the hit parade” are still “in the running” and are therefore also present on the new shortlist. For this smaller number of products, live demo dates (often called “show cases”) are now held in which the vendor or a service provider with specialized implementation know-how demonstrates the respective product with a view to the customer-specific requirements. Based on the impressions gained from these live demonstrations, a “winner” is now chosen, with whose manufacturer hopefully successful negotiations on licenses, etc. will finally be held.

Limits of standard processes:

So far – so good. And in principle certainly conclusive. But what if one or more of the following points apply:

• There is already a clearly favored product at the beginning, e.g. because the IT strategy focuses on a certain provider or exchange partners in other companies recommend it – but at the same time, value is placed on a clean, documented and comprehensible selection process (because of compliance, internal inquiries, etc.)
• Research results to reduce the longlist do not cover the own criteria, i.e. important information is not available for all products
• Questionnaires that were sent out are answered very “sales motivated” by some suppliers or are not answered in sufficient detail
• In the end, no satisfactory commercial agreement is reached with the actual “winner” of the process on licensing costs or similar
• It becomes clear that the provision of a suitable external implementation team is a challenge
• There is simply not enough time to execute the complete standard process without endangering the time planning of the entire project

The solution – A pragmatic, individually defined selection process:

The standard processes described – but also other standard processes – do not always deliver the desired results here (in terms of decision quality and time required) or are not really efficient in generating the results. It is therefore advisable to take a look at the elements of typical standard processes and to combine them in a situation-specific and meaningful way to create a selection process of your own that fits the situation. The elements are already known from our example process:

•  Longlist and Shortlist
• Requirements, represented by a catalogue of weighted criteria
• Catalogue of questions to the providers
• Showcases, i.e. live presentations of the products
• Negotiations on the product itself, but also on the required design and implementation services

Longlist and Shortlist:

In many cases it is reasonable and legitimate to dispense with a long list. Often, even in mature markets, companies in certain industries or of certain sizes can only consider a number of products, or there is a qualified presumption as to which products might suit their own requirements. In such cases, the process can already be started with a shortlist. Even the consideration of only one product can be useful in individual cases, if the compliance rules allow this. However, all parties involved must be aware that a subsequent extension of the scope of the analysis may be necessary if no suitable product could be identified via such an abbreviated process – with all the consequences, especially for the time planning of the overall project.

Requirements, represented by a catalogue of weighted criteria:

It is advisable to document the requirements for an IT solution efficiently during the concept phase as a “derivative” of the concept work in a criteria catalogue. For example, in a final workshop the final polish can then be put on the project. In the structure of such a catalogue, not only functional requirements should be considered. Also commercial aspects, fit to the own IT strategy, roadmap of the product provider (and therefore investment security) etc. are important criteria.

Special attention should be paid to criteria that have a “knock-out character” for your own project (e.g. availability cloud or on-premise, mature market for implementation consultants to be able to act autonomously, global online availability of input and operating front-ends, etc.). Knock-out criteria are suitable for filtering out products on the long or short list more quickly and can thus contribute to an acceleration of the selection process. At the same time, real “knock-out criteria” logically elude the weighting of criteria that is otherwise often used. Knock-out is simply knock-out.

Catalogue of questions to the providers:

Especially if the reduction of a larger number of products from the longlist to a shortlist is aimed at, a questionnaire sent to the providers can be helpful.  Gaps in the available product information can thus be closed and a first filtering of the longlist without physical presence dates can possibly be done on this new information basis. Experience has shown that when sending out questionnaires to several providers, returns with a very heterogeneous answer structure and correspondingly different meaningfulness will be returned. In this respect, one should refrain from making the collection of information via a catalogue of questions the central focus of a selection process. In order to evaluate the competence of a future implementation partner or to find out about important “best practices” for the solution, recommendations or statements of the provider can also be asked in such a questionnaire on individual topics.

Showcases:

In principle, showcases can already be carried out towards the end of a concept phase if the requirements have been raised in parallel with the concept work as described. It has proven to be a good idea to integrate the requirements in a briefing that is sent to the providers as a “script” for the showcase. For your own benefit, it is recommended to send the briefing with a fair lead time to the showcase dates in order to give all providers the opportunity for a clean preparation that is focused on the specific requirements. Otherwise, “standard demos” threaten to cause disappointment, as they only reflect your own requirements to a limited extent.

In the showcases themselves, the business/specialist side and your own IT should be represented in order to come to a joint decision. The original criteria catalogue can serve as a template for a document in which all participants can document their impressions for later consolidation and discussion.

The “demonstration” in showcase meetings is in some cases carried out by the IT provider itself, in others by a specialized implementation service provider. Ideally, the demonstration is carried out by designated members of a later implementation team, so that there is an opportunity to get an impression of the later partners in the implementation phase.

Negotiations:

The licensing models of IT providers in one and the same solution segment differ considerably. They are based on different parameters such as the number of users, the sales volume of the respective customer or the amount of data to be processed. This information has to be compiled internally, sometimes at great expense, or estimated in a qualified manner, which can considerably delay the negotiation process. It is therefore advisable to deal with this topic at an early stage, e.g. as soon as the level of a shortlist has been reached and accordingly only “a handful of providers” need to be contacted. Experience has shown that it is detrimental to the decision-making process if essential commercial information is only available weeks after the showcases have been carried out.

Conclusion:

Good standard software selection processes only contain the concrete elements needed to go from “overall market” to “winner”, but in a sensible sequence and timing. So it is usually worth thinking about how the standard can be modified for your own situation in such a way that decisions can be made more quickly and with better quality from your information base. In addition, there are a number of proven “best practices” that can be used to achieve a very good decision quality in an efficient process.