The short answer
Explain the problem in the budget holder's terms, compare the options including doing nothing, show the full cost over the contract term, set out the benefits with a measure and an owner for each, and be honest about the risks. Put the decision you need on the first page.
What should a technology business case include?
- The decision you need, in one or two sentences, on the first page.
- The problem, in the budget holder’s terms: money, risk, time or customers.
- The options, including doing nothing.
- The full cost over the contract term, not just year one.
- The benefits, each with a measure, a starting point and an owner.
- The risks and what you’ll do about them.
- The timeline to decide, implement and see results.
Why include a do-nothing option?
Because it’s always an option, and the budget holder will be thinking about it anyway. Setting out what happens if nothing changes makes the cost of the problem visible, and gives every other option something fair to be measured against.
How do you work out total cost of ownership?
Add up everything the purchase will cost over its life:
- Licences or subscription fees for the full term, including expected growth in users or volume.
- Implementation and set-up, whether by the supplier, a partner or your own team.
- Internal time: the hours your people will spend on the project and on running it afterwards.
- Integration with your existing systems, and keeping those integrations working.
- Training, including for people who join later.
- Support or premium service tiers if you need them.
- Price rises at renewal. Use the cap in the contract if there is one.
- The cost of leaving: data export, running two systems during a switch, notice periods.
How do you estimate benefits honestly?
Measure where you are today before you promise where you’ll be. For each benefit, write down the measure, today’s number, the number you expect and who is responsible for getting there. Keep benefits you can measure separate from ones you can only describe, and don’t add the second kind into your totals.
Ask shortlisted suppliers for references who can tell you what changed for them, then decide for yourself what is realistic for your organisation.
What risks should you cover?
- Implementation running late or over budget.
- People not using it.
- Integration problems with existing systems.
- Supplier risk: their financial health, security and support.
- Lock-in: how hard it would be to leave.
For each, say how likely you think it is, what it would cost and what you’ll do to reduce it.
How long should it be?
Long enough to answer the budget holder’s questions and no longer. A one-page summary with the decision, the cost, the benefits and the main risks, backed by an appendix with the detail, works for most purchases.
The budget section of the Asand benchmark checks how certain your funding is and suggests what to do next.