How to Write a Technology Business Case

A technology business case has one job: to give the decision-maker the information they need to make a sound investment decision.

That sounds straightforward, but most business cases fail at this basic test. They are written to justify a decision that has already been made, rather than to inform a genuine choice. They present a preferred option alongside two alternatives that were never seriously considered. They contain a financial model that has been constructed to reach a predetermined conclusion. They understate the implementation risk because acknowledging the risk might result in the case being rejected.

The consequence of a weak business case is not just governance risk. It is delivery risk. Programs that start with a business case that misrepresents the scope, understates the cost, or overstates the benefits are set up to fail before they begin.

Start with the problem, not the solution

The most common mistake in technology business cases is starting with the solution. The business case is written after the decision has effectively been made - the platform has been chosen, the vendor has been selected in principle, the project team is already in place. The business case becomes a documentation exercise rather than a decision-making tool.

A business case that starts with the solution cannot present a genuine options analysis. It can only present a comparison that is structured to favour the option that has already been chosen.

Starting with the problem means defining it precisely: what is not working as it should? What is the impact of continuing with the current state? What is the cost - financial, operational, reputational, compliance-related - of not addressing it? How confident are you in that quantification?

A well-defined problem statement does three things. It establishes the investment is necessary. It defines the scope of the solution that is needed. And it provides the basis for evaluating whether the preferred option actually addresses the problem.

Analyse the options honestly

A genuine options analysis includes at least three alternatives: the status quo, a minimum viable intervention, and the proposed investment. In some situations it will include more.

The status quo is often presented as the “do nothing” option, but it is rarely truly passive. Maintaining an aging system has costs - licensing, integration overhead, workaround maintenance, security risk. The status quo option should present the realistic forward cost of continuing with the current state.

Each option should be assessed against the same criteria: strategic alignment, technical feasibility, implementation risk, total cost, benefits achievable, and timing. The assessment should be honest about what is not known, what assumptions are being made, and where the analysis has limitations.

The conclusion of the options analysis - the recommended option - should follow from the assessment, not lead it. If the recommended option is not the best performer against the criteria, explain why. There may be good reasons (timing, risk appetite, capability constraints) to choose a less theoretically optimal option. Document them.

Build the financial model properly

The financial model is the part of the business case that is most likely to be wrong and most likely to be tested.

A credible financial model covers:

Capital costs. Platform licensing or purchase, implementation services, integration development, infrastructure, data migration, testing, training. Include contingency - not a token percentage, but a reasoned estimate based on the complexity and risk profile of the program.

Operating costs. Ongoing licensing, support and maintenance, hosting, helpdesk uplift, training for new staff. Be clear about what changes relative to the current state.

Benefits. Quantify what can be quantified and be clear about what cannot. Benefits that are presented as “efficiency gains” without a basis for calculation are not a financial benefit - they are an aspiration. Where benefits depend on process change or behaviour change, acknowledge that and factor it into the probability weighting.

Net present value. Present the NPV at a discount rate appropriate to your organisation’s cost of capital. Show the sensitivity analysis - what happens to the NPV if costs are ten percent higher than estimated, or benefits are twenty percent lower?

The financial model needs to be transparent. The assumptions should be documented separately and clearly linked to the numbers in the model. A decision-maker who cannot follow the logic of the financial model cannot make a sound decision based on it.

Address implementation risk

Implementation risk is where most technology business cases fall short. The risk section tends to present generic risks (vendor risk, change management risk, data migration risk) without specificity, and presents mitigations that are more aspiration than plan.

A credible risk assessment identifies the specific risks in this program, not generic project risks. It quantifies the likelihood and impact where possible. It presents mitigations that have been designed and committed to, not hypothetical ones. And it acknowledges where the mitigation does not eliminate the risk - only reduces it.

The risk section should also address delivery capability honestly. Does the organisation have the people, the governance structures and the vendor management capability to deliver this program? If not, what is the plan to address that?

Know your approval audience

A business case that is technically correct but structured incorrectly for its audience will be returned for revision, which is expensive and demoralising.

Understand the approver’s specific requirements before you write:

What format are they expecting? Some departments have a standard template. Use it. Deviating from the expected format creates friction.

What are their threshold concerns? Delegate approvers at different levels have different risk tolerances and different areas of focus. A Chief Financial Officer will scrutinise the financial model. A Chief Information Officer will scrutinise the technical architecture and implementation risk. A Secretary or CEO will scrutinise the strategic alignment and governance arrangements.

What does a complete submission include? Is a separate executive summary required? Are there supporting documents (IT security assessment, architecture review, legal sign-off) that must accompany the business case?

What are the most common reasons for return? If your organisation has a track record of business cases being returned for revision, understand why. Address those issues before you submit.

The supplementary business case

When a program has gone over budget or scope has changed significantly, a supplementary business case is required. This is a different document from the original business case and has a different challenge: it must explain what went wrong with the original estimates and why the new estimates should be trusted.

A supplementary business case that does not address this question directly will not succeed. The approver’s implicit question is: if the original numbers were wrong by this much, why should I trust the new numbers? The answer requires an honest account of why the original estimates were wrong - not an excuse, but an explanation - and a clear description of what has changed in the approach to estimating and managing the completion of the program.

The Enterprise Technology Business Case Pack includes a full business case template, options analysis framework, financial model and delegate approval checklist. See the templates page for details.