Why a process matters more than the product list
Most poor software purchases are not caused by a bad product. They happen because the buying team never agreed what the software had to do, was shown a polished demonstration of someone else’s strengths, and made the decision on impressions. A written software evaluation process does not guarantee a good outcome, but it makes the reasoning visible and repeatable, and it makes it harder for the loudest voice or the best presentation to decide.
The steps below suit most mid-sized purchases. For a small, low-risk tool you can compress them; for something that touches many teams or sensitive data, you will want every step and probably more care at each one.
Step 1: State the problem, not the product
Start with a short statement of what is going wrong or what you want to enable. “Approvals take too long and nobody can see where a request is stuck” is a problem. “We need a workflow platform” is a solution already chosen.
Also decide at this point whether software is the right answer. Sometimes the cause is an unclear process or missing ownership, and a new tool would only move the confusion to a new place. Changing the process, or configuring something you already own, may be enough. The trade-offs between those paths are covered separately under build versus buy.
Step 2: Agree who is involved and who decides
Name the people who will use the tool daily, the people who will administer it, and the people who pay for it or carry its risks (finance, security, legal, operations). Name one decision owner. A group can advise, but a decision with no owner tends to drift or be reopened late. A quick round of stakeholder mapping can reveal who has been left out before it becomes a problem.
Step 3: Write requirements before you see any product
Write what the software must do, what would be useful, and what is out of scope. Keep each requirement specific enough that someone could check it. This is the single most protective step against being led by demos, because it fixes the yardstick in advance. The detail of how to do it well is a topic of its own under requirements gathering.
Include non-functional needs as well: security expectations, performance, accessibility, reporting, data export, and support hours. These are the items people tend to forget until after signing.
Step 4: Build a long list, then a short list
Collect candidates from several sources: colleagues in similar organizations, independent reviews, existing suppliers, and a deliberate look at at least one option outside the usual suspects. Then cut the list using only your must-have requirements and a handful of basic checks, such as whether the vendor can meet your data location or support needs. Aim for roughly three to five candidates for detailed work. Fewer than three removes any real comparison; many more makes careful testing impractical.
Step 5: Control the demonstrations
Demos are useful, but they are written by the seller. To reduce their pull:
- Send the same scripted scenarios to every vendor ahead of time, based on your real tasks, and ask them to show those rather than their standard tour.
- Have several evaluators attend and score independently before any group discussion.
- Ask to see the unglamorous parts: admin screens, error handling, reporting, import and export.
- Keep notes of what was shown live versus described as “on the roadmap”. Planned features are not the same as working ones.
Step 6: Test with real work
A demonstration shows what a product can do in good conditions. A trial or pilot shows what it does with your data, your users and your habits. Use real tasks, real users and success criteria agreed in advance. How to run one fairly is covered in more detail under software pilot design. Even a short trial with a few genuine users usually reveals problems no demo would.
Step 7: Check integration, security and the vendor itself
Technical fit matters as much as features. Ask how the product will exchange data with your existing systems, a topic explored under system interoperability, and whether it supports the identity arrangements you rely on, such as single sign-on. Ask the supplier structured questions about support, data access, security and exit terms, as set out in vendor due diligence. Involve your security and legal colleagues for anything touching sensitive data or contracts; this guide gives general information, not professional advice.
Also consider how hard it would be to leave later. Switching costs are easiest to reduce before signing, and vendor lock-in is worth assessing explicitly.
Step 8: Compare options on the whole picture
Bring the evidence together. A weighted scoring matrix can help you compare options consistently, provided you remember it is a discussion aid and not an oracle. Price needs the same care: the licence fee is rarely the full cost, so estimate total cost of ownership across several years, including implementation, training, integration and the time your own staff will spend.
Step 9: Decide, record and plan the rollout
Write a short decision record: the problem, the requirements, the options considered, the evidence, the main risks, and why the choice was made. This protects the organization when people change roles and helps you judge the decision honestly later. Then plan adoption, since a good purchase can still fail if people are not trained or if processes do not change. Organizational change management and system training approaches deserve time in the plan, not an afterthought.
When the process should be lighter or heavier
Not every purchase deserves nine steps. A useful rule of thumb is to scale effort to the cost of being wrong: how many people depend on the tool, how sensitive the data is, and how hard it would be to reverse. A free trial of a single-user utility needs very little. A system that will become the shared record for several departments deserves the full treatment, plus a clear exit plan.
Finally, accept that no process removes uncertainty. The aim is to make the decision on evidence you chose in advance, rather than on whichever demo happened to be most persuasive.