How to Build the Business Case for an AI Project

A credible AI business case has five parts: the full cost (build, run and people), the value tied to a measurable baseline, an adoption ramp that does not assume instant use, best, base and worst cases, and an honest list of what you left out. Show the arithmetic so anyone can change an assumption and see the effect. This post includes a worked example, which is entirely illustrative: every number is an assumption for demonstration, not a result from a real project.

This is the same logic the site's AI Business Case Builder walks through: shortlist and cost models, compare API with self-hosting, model ROI with adoption and best, base and worst cases, then export a report. The AI ROI Calculator gives the adoption ramp and a three-year payback chart with its assumptions visible.

The model bill is the easy line. Much of the cost is often elsewhere.

For the model line, choosing between a hosted API and self-hosting changes both the cost shape and the effort, which API or local models: where the cost break-even sits works through.

Value is the change from a measured starting point. State what is measured today, then what changes and by how much, using units finance can check: hours, cost per unit, error rate, time to resolve.

Be careful not to count the same saving twice, such as hours saved and headcount avoided for the same work, and do not count time saved as cash saved unless the time is actually redeployed or a cost is actually removed.

The numbers below are assumptions invented to show the arithmetic. They are not results, benchmarks or typical figures for any real project. Replace every one with your own measured values.

Imagine an assistant that handles a share of routine support requests. The assumptions:

Value depends on the share of requests the system fully handles. Run three cases:

def case(handled_share, requests=2000, minutes=15, hourly=40,
         run_per_month=1200, build=60_000):
    hours_saved = requests * handled_share * minutes / 60
    value = hours_saved * hourly
    net_per_month = value - run_per_month
    payback_months = build / net_per_month if net_per_month > 0 else float("inf")
    return round(hours_saved), round(value), round(net_per_month), round(payback_months, 1)

for name, share in [("worst", 0.15), ("base", 0.30), ("best", 0.45)]:
    print(name, case(share))
# worst (75, 3000, 1800, 33.3)
# base  (150, 6000, 4800, 12.5)
# best  (225, 9000, 7800, 7.7)

Look at what the three cases show: with these assumptions, the outcome swings from a payback of under eight months to nearly three years depending on one number, the share of requests handled. That is the real message for decision-makers. It tells you which assumption to test first, with a small proof of concept on real requests, before committing the full build. It also shows why a single-number business case is fragile.

Adoption adds another dimension. Few systems reach their steady-state share on day one, so model a ramp: a low share in the first months, rising as users trust it and the system improves. Both calculators on this site include an adoption ramp for that reason.

The FDE chapters on use case scoring, proof-of-concept scoping and data readiness cover how to choose a first use case and test it cheaply. The post on AI strategy for engineering leaders shows how business cases feed a portfolio.

Leave out benefits you cannot measure, and list them separately as upside you are not counting, such as better consistency or faster onboarding. Leave out one-off effects you cannot defend. State clearly what the case excludes and why, so readers know the numbers are conservative rather than inflated. Include the risks: quality failures, data issues and the controls you will need, with their cost.

Lead with the decision you want, then the base case with its assumptions on one page, then the range, then the first step that reduces uncertainty. Make the model available so that finance can change an assumption themselves. A case that survives their changes is stronger than one that only works with your numbers.

What goes into an AI business case? The full cost (build, run, people and change), value tied to a measured baseline, an adoption ramp, best, base and worst cases, and an explicit list of what is excluded. Show the arithmetic so others can change the assumptions.

How do I calculate the ROI of an AI project? Work out the value from the change against a baseline, such as hours saved times cost per hour, subtract the ongoing run cost to get a net monthly benefit, and divide the one-off build cost by it to estimate payback. Repeat for best, base and worst cases.

Why show three scenarios instead of one? A single number hides how fragile the case is. Three cases show how much the outcome depends on a key assumption, such as the share of work the system handles, and tell you what to test first.

Is the worked example in this post real data? No. Every figure in the example is an assumption invented to demonstrate the arithmetic. Replace them with your own measured numbers before using the method.

How do I model adoption? As a ramp, not a switch: a low share of use in the early months, rising as users gain trust and the system improves. Base the ramp on a pilot where you can, and show how sensitive the result is to it.

Does time saved count as money saved? Only if the time is redeployed to valuable work or a cost is actually removed. Agree with managers where the time will go, and avoid counting the same saving twice.

What should I leave out of the business case? Benefits you cannot measure and one-off effects you cannot defend. List them separately as upside you are not counting, and state what the case excludes so the numbers read as conservative.

• AI strategy for engineering leaders: choose, fund and stop
• API or local models: where the cost break-even sits
• How to measure the impact of AI coding tools
• Forward deployed engineering topic hub
• Forward Deployed Engineer roadmap