A practical checklist for choosing business software

01

The business problem

Most software disappointment is decided before the contract is signed. A tool is chosen because it demoed well, because a peer organisation uses it, or because a deadline forced a decision — and the requirement it was meant to serve was never written down.

Smaller organisations feel this hardest. There is rarely a procurement function, the person choosing is usually the person who will run it, and the cost of an unsuitable choice is measured in months of workaround.

02

Context

A defensible decision does not require a large process. It requires the same few things to be written down before options are compared: the problem, the users, the constraints and the measure of success.

This checklist is the sequence we use on client selection work. It is deliberately short enough to complete in a couple of working sessions.

03

Options and recommended approach

The checklist

1. 1

   State the business problem in one paragraph

   Describe the current situation, who it affects and what it costs in time, money, risk or service quality. If this cannot be written without naming a product, the problem is not yet understood.

2. 2

   Map the process as it is actually performed

   Walk it with the people doing it, including the exceptions and the spreadsheets. Software fits a real process, not the documented one.

3. 3

   Separate must-have from useful

   Keep must-haves to the smallest set that solves the problem. Long requirement lists inflate cost and eliminate good options for the wrong reasons.

4. 4

   Write down the constraints

   Budget, existing systems, data protection obligations, accessibility duties, internal capability and the realistic time available to implement.

5. 5

   Agree the measure of success

   Decide before selection what will be different in six months and how you will know. Without this there is nothing to hold the decision against.

6. 6

   Shortlist three options and compare them against the same criteria

   Score against your written criteria rather than against feature lists. Include the option of improving the current process without new software.

7. 7

   Test with real work

   Run a trial using genuine cases, with the people who will use it daily. Demonstrations show the product at its best; a trial shows it at yours.

8. 8

   Check the commercial and exit terms

   Pricing at your expected scale, renewal terms, support, data export and what happens if you leave. Export is the item most often discovered too late.

9. 9

   Plan implementation before you commit

   Configuration, migration, integration, training and who owns it afterwards. The licence is rarely the largest cost.

04

Practical use case

A service organisation of around thirty people wanted a CRM after enquiries were repeatedly lost between inboxes. Working through the checklist, the must-have set reduced to three items: a single view of an enquiry, a visible owner, and reporting on response time.

Two of the four products originally shortlisted were eliminated on data export terms rather than features, and the trial used a fortnight of real enquiries rather than sample data. The chosen tool was not the most capable of the four; it was the one the team used correctly without supervision.

05

Benefits

• A decision that can be explained to a board, a funder or an auditor
• Fewer features paid for and not used
• Implementation planned as work, not discovered as a surprise
• A written success measure that makes review possible later

06

Limitations and risks

• A checklist does not remove the need for judgement about the organisation's appetite for change
• Trials consume real staff time and need to be resourced honestly
• Requirements written in isolation from frontline users tend to describe the wrong process
• Prices, features and terms change; anything recorded during selection should be re-checked before signature

07

Responsible AI and data considerations

Where a shortlisted product includes AI features, treat them as a separate assessment rather than a bullet on the feature list.

• Establish what data the feature processes, where it is hosted and whether inputs are used for model training
• Identify the named person who reviews output before it is acted on
• Record how a decision or output can be explained to the person affected by it
• Confirm retention periods and the lawful basis for any personal data involved

08

Conclusion

Good selection is mostly the discipline of writing things down in the right order. The organisations that are satisfied with their software two years later are usually the ones that could state, before buying, exactly what problem they were solving.