Reviewing the decision a year on
The review is booked, skipped, and forgotten. It is also the only mechanism by which an organisation gets better at buying software.
A year after a purchase, the people involved have moved on to other things, the product is embedded, and revisiting the decision feels academic. So the review does not happen, and the same reasoning produces the same result next time.
Book it at the decision, not afterwards
Put the date in the calendar the week the contract is signed, with a named owner, and attach the decision record to it. Scheduled at the moment of commitment, it happens. Scheduled later, it does not. For a concrete example of workplace interaction after purchase, read more can be used to identify the behaviours and measures that rollout should actually change.
Timing it a couple of months before the renewal notice window is the practical choice, because then the answer can actually change something.
Check it against what you wrote
The review is short if the groundwork was done: read the original success criteria, look at the measurements, and answer whether they were met.
Where they were not, distinguish the three causes, because they lead to different actions. The product does not do what was expected. It does, but adoption did not happen. Or it does and adoption happened, and the benefit was not there — which means the business case was wrong, and that is the most useful finding of the three.
Wrong product: consider replacing. Poor adoption: fix the rollout. Wrong business case: change how you evaluate next time. Treating all three as 'it did not work' loses the lesson.
Look at what you now know that you did not
Every implementation teaches something the evaluation missed: a question nobody thought to ask, a cost that was invisible, a reference question that would have surfaced a problem.
Writing those down is what makes the next selection better. Over several purchases this accumulates into a short, specific checklist that is worth more than any generic methodology, including this one.
Review the whole subscription portfolio while you are there
Most organisations carry software they no longer need: overlapping tools, licences for people who left, tiers sized for a shape they have outgrown, a product bought for a project that ended.
An annual pass over everything being paid for — what it is, who uses it, when it renews, whether it is still needed — regularly finds a meaningful share of the budget available for reallocation, and it takes an afternoon.
Be willing to conclude it was fine
Not every review needs to produce a change. A decision that worked, confirmed with evidence, is a good outcome and worth recording as one.
The purpose is not to find fault. It is to close the loop, so that the organisation's software decisions are informed by what happened last time rather than by whoever is most persuasive this time.
For broader rollout and service-improvement practice, the UK Government Service Manual provides an independent operational reference.