Skip to content

Writing an IT Business Case: Costs, Benefits, Risks and Options

How to write a short, honest business case for an IT project, comparing real options against business as usual, counting full costs, defending benefits and testing risky assumptions.

Agile vCIO · Last reviewed October 22, 2026 · 6 min read

A business case is a short document that answers one question for whoever approves the money: is this IT project worth doing, and is this the best way to do it? It describes the problem, the realistic options, what each option would cost and deliver, and what could go wrong.

Small businesses often skip this step because the decision feels obvious or the owner is already in the room. The discipline still pays off on a modest project. Writing it down forces you to compare alternatives, surface hidden costs and agree in advance on what success looks like, which makes the project easier to manage and easier to judge afterward.

This guide borrows structure from one of the most detailed public frameworks for business cases, the UK government's Green Book and its Five Case Model, and scales it down for a small or midsize business. It is general information, not financial, tax or legal advice.

Start With the Problem, Not the Product

A weak business case starts with a product someone already likes. A strong one starts with the problem and with what happens if you do nothing. The Green Book calls this the business as usual: "the outcome that is expected if current arrangements continue and the proposal is not implemented."

For example, imagine a hypothetical 25-person accounting firm whose file server is out of warranty and slow during tax season. Business as usual is not free. It means growing hardware risk, staff time lost to slow access, and a likely emergency replacement at the worst possible moment. Writing that down gives every option something concrete to beat.

Then set objectives. The Green Book asks for objectives that are specific, measurable, achievable, realistic and time-limited. "Improve file access" is vague. "Move all client files to a supported platform before the next tax season, with no more than four hours of planned downtime" can be planned and checked.

The Five Case Model, Scaled Down

The Green Book, updated February 5, 2026, describes five linked dimensions of a business case. Translated for a small business, they ask:

  • Strategic case: why change, why now, and how does this fit the business's goals?
  • Economic case: which options were considered, and which gives the best value?
  • Commercial case: how will you buy it, what will the contract say, and who carries which risks?
  • Financial case: can the business afford it, and what does it do to cash flow?
  • Management case: who will run the project, and how will you know it worked?

The Green Book stresses that these are "not five separate business cases" but connected views of one proposal, developed in a way that is proportionate to its costs, complexity and risks. For a small project, a paragraph or two per dimension may be enough.

Lay Out Real Options

The Green Book recommends generating a wide longlist of options, then narrowing it to a shortlist of viable ones. Options that cannot meet the objectives are dropped, with one exception: business as usual must always stay on the shortlist as the benchmark.

For IT projects, a typical shortlist might include:

  1. Business as usual: keep running what you have.
  2. Do the minimum: for example, extend support or upgrade in place.
  3. Replace like for like with newer equipment or software.
  4. Move to a cloud or subscription service.
  5. Outsource the function to a provider.

Options change who does the work, not just what it costs. NIST's patch management guide, SP 800-40 Revision 4, notes that replacing conventional software installations with software as a service shifts patching to the provider. That ongoing effort belongs in your comparison.

Before comparing numbers, list your critical success factors. The Green Book describes these as the attributes any option must have to deliver the objectives successfully, such as staying within budget or supporting the software your team depends on.

Count the Full Costs

Compare options over the same period, ideally the expected life of the solution. Include:

  • One-time costs: purchase, setup, data migration, consultant time, training and any period of running old and new systems side by side.
  • Recurring costs: subscriptions, support contracts, maintenance and expected renewal increases.
  • Internal staff time: the hours your own people will spend on the project and on running the result.
  • Exit costs: exporting data, early termination fees and eventual disposal or replacement.

Tax treatment can change the real cost. IRS Publication 946 explains how businesses recover the cost of property through depreciation and how they can elect a section 179 deduction, and it lists off-the-shelf computer software among qualifying property. Rules and limits change, so ask your accountant how a purchase or subscription will be treated.

When costs and benefits fall in different years, a dollar later is worth less than a dollar today. The Green Book discounts future values for this reason. A business would normally use its own required rate of return, which your accountant can help set.

Benefits You Can Defend

List benefits by type and be honest about which ones you can measure:

  • Costs avoided, such as paying for extended support or emergency repairs.
  • Time saved, valued at what that staff time actually costs.
  • Revenue enabled, such as serving more clients with the same team.
  • Risk reduced, such as a lower chance of a long outage or data loss.
  • Requirements met, such as a security control your insurer or a client contract requires.

Some benefits will not convert neatly into dollars. List them separately rather than forcing a number. The Green Book's recommended summary table lists costs and benefits that can't be expressed in money alongside the ones that can. Name an owner for each benefit and record today's baseline, so you can check later whether it arrived.

Be Honest About Risk and Uncertainty

The Green Book tells appraisers to adjust for optimism bias, which it defines as "the proven tendency for appraisals to be over-optimistic about key assumptions." Its remedy is to raise cost and duration estimates and lower benefit estimates.

It also recommends sensitivity analysis and switching values, which it describes as "the values that a key assumption would need to change to, in order to make an option no longer value for money." In practice, ask: what if migration takes twice as long, or only half the staff adopt the new tool? If a small change flips the answer, say so.

Add a short risk list covering each risk, its likelihood and impact, an owner and a planned response. Common IT project risks include data migration problems, vendor lock-in, staff resistance, security gaps during the transition and unplanned downtime. Include a contingency amount for risks that remain.

A Simple Outline

A small-business IT business case can fit on a few pages:

  1. Summary and recommendation
  2. The problem and business as usual
  3. Objectives and success measures
  4. Options considered and why some were ruled out
  5. Costs and benefits of each shortlisted option over the same period
  6. Risks, sensitivity checks and contingency
  7. How you will buy it and key contract terms
  8. Delivery plan with an owner, milestones and decision points
  9. When and how you will review the results

Write a short early draft before you collect quotes, then update it once real prices and contract terms arrive. The Green Book's process works the same way, moving from an outline case to a full business case after procurement. For related planning, see our guides to IT Budgeting for Small Businesses: A Practical Guide and How to Build an IT Roadmap for a Small Business.

Key takeaways

  • Start with the problem and the cost of doing nothing, not with a preferred product.
  • Compare a short list of real options, always including business as usual as the benchmark.
  • Count full costs over the solution's life, including staff time and exit costs, and ask your accountant about tax treatment.
  • Separate measurable benefits from unmeasurable ones and give each benefit an owner and a baseline.
  • Adjust for optimism, test key assumptions and keep the document proportionate to the project.

Sources

Spotted something out of date? Let us know.

More in IT Strategy & Leadership