Selecting Software: Requirements, Trial Phase, Decision

Why software selection so often ends in a bad purchase

The trigger is usually an annoyance. The order spreadsheet has become confusing, time tracking runs on slips of paper, or a customer demands a portal. Someone looks at two vendors, a demo convinces, the contract is signed. Six months later half the team does not use the program, and the old spreadsheet lives on.

The mistake rarely lay in the software. It lay in the selection: nobody had written down what the program must do, testing was done with demo data instead of real cases, and the decision was made by whoever saw the demo, not by whoever will work with it.

This article answers the question: how does a small company select software so that it is actually used afterwards and improves the work? To answer, we first clarify the terms, present a thinking model from information systems research, examine the findings on selection in small companies, weigh two ways of deciding, and describe the process in three phases.

A demo shows what the software can do. A trial shows what your team does with it.

Terms: requirement, must criterion, trial phase

A requirement describes what the software must achieve in a particular workflow, from the perspective of whoever works with it. It is well phrased when it can be checked: 'A quote can be created from a template in under five minutes' is checkable, 'user-friendly' is not. A must criterion is a requirement without which software is ruled out, such as issuing e-invoices in the German XRechnung format. Should and could criteria are desirable but negotiable. The trial phase is a limited period in which selected candidates are tested with real cases.

Before requirements are written, the workflow must be settled. Anyone looking for software for a workflow that does not yet exist describes wishes instead of requirements. The sequence record, simplify, select from the article on why process comes before tool applies here unchanged. Which workflow is up first is described in the article on digitalization in the right order.

Selecting software resembles buying a company car. Comparing brochures leads to the car with the most features. Driving your own route for a week, with tools in the trunk and the colleague who will use it daily, shows whether it fits.

The thinking model: fit between task and technology

In 1995, the information systems researchers Dale Goodhue and Ronald Thompson presented a model that is particularly useful for selection: task-technology fit. According to it, a technology improves a person's performance only under two conditions. It must be used, and it must fit the tasks it is meant to support. Software that is used but does not fit costs time. Software that fits but is not used achieves nothing. The authors tested the model with data from more than 600 employees in two companies and found its core confirmed, though only moderately (Goodhue and Thompson 1995).

The model complements Davis's technology acceptance model (1989), described in the article on no-code automation. There, use depends mainly on whether software is experienced as useful and easy. Task-technology fit adds what usefulness depends on: the match with the actual tasks. For selection it follows that the test questions are not 'What can the software do?' but 'Does it handle our most frequent tasks better than today, and will our people use it?'

What studies show about software selection in small companies

Thong, Yap, and Raman (1996) examined in 114 small businesses what the success of implemented information systems depended on. Support from top management was important, but not the strongest factor. More important was the quality of external experts, meaning vendors and consultants. The authors explain this with the resource scarcity of small businesses: they usually lack in-house expertise and therefore depend more on the quality of their partners than large companies do.

A second study by the same research group compared two approaches. Some small businesses had hired an independent consultant and a separate vendor, the others a vendor who also provided consulting. The businesses with only one partner had more effective systems on average and rated vendor support better. The authors name the relationship between the vendor and the other parties in the project as an important factor (Thong and Yap 1994). An independent consultant is therefore not an end in itself. What matters is who is reachable after the purchase and understands the business.

Cricelli and colleagues (2020) describe the problem from the decision-makers' perspective, using customer management software as the example: there are hundreds of offerings, and owners lack the time and expertise to compare them. Many therefore leave the selection to an external expert. The authors propose a four-step procedure in which decision-makers themselves define which criteria count and how much, and test it in a small Italian company. Their basic idea: the criteria must come from your own company, not from a generic list. A literature review of 89 journal articles on software selection also shows that weighted scoring methods are the most common method in research (Duman et al. 2024).

Score or trial? Two perspectives on the decision

For the decision itself there are two camps. The first relies on weighted scoring, often called utility analysis in Germany: each criterion gets a weight, each candidate gets points per criterion, and the highest total wins. This makes the decision traceable and protects against the impression of a good demo.

The second camp considers such scores false precision. Whether software holds up in daily work only shows in use, and the weights are estimated anyway. A short, tough trial with real cases and the judgment of the people who work with it would be better.

I consider both objections justified and the combination the better path. The must criteria filter in advance, the weighted scoring orders the candidates and makes differences visible, and the trial decides between the two best. The scoring is then not a calculator that spits out the result but a record of why the decision was made. This fits the experience from the article comparing project management tools: the best tool is the one the team still opens voluntarily after four weeks.

The process in three phases: requirements, trial, decision

Phase 1: requirements and shortlist

With two or three future users, write down the ten most frequent tasks of the workflow and derive checkable requirements from them. Separate them into must, should, and could. At most five must criteria, otherwise no vendor remains. Typical must criteria are data protection with a data processing agreement under the GDPR, export of data in an open format, and an interface to the existing main system.

Phase 2: trial with real cases

Test at most two candidates in parallel, for two weeks. Each tester handles the same five real cases from last week in both programs, including one difficult case. For each case, record the time needed, what did not work, and how often help was needed. Also test the vendor in this phase: how quickly and how well does it answer a real question? The findings of Thong and colleagues show that this support matters especially for small companies.

Phase 3: decision and closing

Decide together with the testers. Record in writing why the winner won and which weaknesses are known. Before signing, define which old tool will be switched off in return and by when, as the article on how to reduce tool sprawl recommends. With subscription contracts, pay attention to the term, the notice period, and how you get your data back when switching.

After the selection: why implementation is part of it

Signing is only half the job. According to Goodhue and Thompson, fitting software works only if it is used, and use develops in the first weeks. That is why, even before the decision, it should be settled who is responsible for the implementation, when the old solution ends, and how success will be measured after three months. A six-phase plan for this is in the article on how to implement a CRM. It can be transferred to other software.

Beyond the individual case, the findings yield a rule for small companies: choosing the partner is part of choosing the software. A somewhat weaker program with a vendor who understands the business and is reachable often achieves more than the strongest program without support. For CRM systems, the article on CRM for small businesses describes which kinds of solutions exist.

Conclusion: how does a small company select software well?

The guiding question was how a small company selects software so that it is used and improves the work. The task-technology fit model sets the direction: what is tested is not what software can do, but whether it handles your most frequent tasks better and whether the team will use it. In practice that means a few must criteria as a filter, weighted scoring as order and justification, and a trial with real cases as the decision, together with the future users. The studies of small companies add that the quality of the vendor counts at least as much as the software itself. Selecting this way means deciding not by the best demo, but by the best daily work.

What you can do this week

• Describe on one page the workflow for which software is being sought.
• Write down the ten most frequent tasks with two future users.
• Derive at most five must criteria and a few weighted should criteria from them.
• Set aside five real cases, including a difficult one, as test cases.
• Define which old tool will be switched off after the implementation.

With these preparations, the actual selection often takes only three to four weeks, and at the end there is a decision that can be justified.