Most technology business cases fail for the same three reasons: the costs are incomplete, the benefits are unmeasurable, and the do-nothing option is not taken seriously.
Fix those three and approval becomes much more likely — partly because the case is better and partly because it reads as honest.
State the problem in business terms
Not "we need a new CRM". That is a proposed solution.
The problem is what is actually happening: quotes are not being followed up and we estimate we are losing work; nobody can tell what is in the pipeline; when somebody is away their customers are unattended.
Stated that way, the case can be evaluated against alternatives, and a reader who disagrees with your solution may still agree with your problem — which is a much better starting position than a rejected proposal.
Include doing nothing as an option
The one people leave out, and the one that makes the rest credible.
Set out honestly: what continues to happen, what it costs, and what the risk is. Sometimes the honest answer is "not much for another two years", and saying so is more persuasive than manufactured urgency.
Where doing nothing genuinely does carry a serious cost — unsupported software, a system nobody can maintain, a compliance obligation not being met — that is the strongest argument in the case, and it deserves to be prominent.
Get the costs complete
Incomplete costs destroy credibility, and they destroy it later, at the point where the project needs more money.
Over three to five years, include:
- Purchase or build cost
- Implementation and configuration
- Data migration, which is regularly underestimated
- Integration with other systems
- Training, including the time people spend being trained
- Ongoing licences or hosting, at your projected size rather than today's
- Support and maintenance
- Internal staff time throughout
- Continued development after launch, for anything custom
Internal time is the item most often omitted, and it is real. A project consuming two days a week of a manager for four months is a cost, and pretending otherwise means the project appears to overrun when it was simply mispriced.
Note assumptions and price rises. Subscription costs rise; saying so in advance is better than explaining it in year two.
Make benefits measurable
"Improved efficiency" cannot be approved, because it cannot be checked.
Convert each claimed benefit into something you could measure afterwards:
Time. "Approximately six hours a week currently spent reconciling two systems." Multiply by a realistic cost.
Errors. "Around four invoicing corrections a month, each taking an hour and occasionally costing goodwill."
Speed. "Invoices raised on average eleven days after work completion; we expect that to fall to two, which improves cash by a calculable amount."
Revenue. Only where you can defend the link. "Quotes followed up consistently" is defensible if you can show how many currently are not.
Be conservative. A case that promises modest measurable benefits and delivers them is worth far more to your credibility than one that promises transformation.
Write the benefits so that somebody could check them in a year. If you would not want that check, the benefit is not real enough to include.
Name the risks yourself
A case with no risks reads as either naive or evasive, and readers will find them anyway.
The ones worth naming for most technology projects: data quality worse than expected; staff not adopting the new system; the supplier failing to deliver; the project taking longer than planned; and a dependency on one internal person.
For each, state what would reduce it. Naming a risk with a mitigation is reassuring. Naming one without is not.
Structure it for the reader
One page that stands alone: the problem, the options, the recommendation, the cost, the benefit, the risk. Then the detail behind it, then the technical material as an appendix.
Assume the summary is what gets read — see explaining technology to non-technical stakeholders.
Name an owner and a review point
Two things that materially improve approval rates.
An owner, named, responsible for delivering the benefit rather than the project. And a review point — a date at which the promised benefits will be measured and reported, including if they have not materialised.
Committing to that review is a strong signal that you believe your own numbers, and it is what makes the next business case easier.
What gets cases rejected
Urgency that cannot be substantiated. Readers discount it.
Benefits that are all qualitative. Nothing to approve against.
A single option. Reads as a decision already made, seeking rubber-stamping.
Costs that arrive in instalments. The most damaging, because it affects everything you propose afterwards.
Technical language in the summary. If the reader cannot follow the first page, the answer is defer.
Our consultancy team helps UK businesses build cases their boards can act on, including the honest version of the do-nothing option. Start a conversation.
