AI ForwardStrategy & execution

How to Build an AI Business Case: ROI, Risk, and the First Use Case

A practical framework for evaluating an AI investment through business value, current friction, risk, ownership, and measurable outcomes.

A credible AI business case does not begin with a dramatic prediction. It begins with a real problem, a measurable baseline, a bounded intervention, and an honest view of risk.

Leaders need enough structure to compare an AI idea with other investments. They do not need false precision. The purpose of the business case is to improve the decision.

Start with the business problem

Describe what is happening today. Is work waiting? Are errors creating rework? Are leaders making decisions with incomplete information? Is a team unable to keep up with demand? A specific problem creates a stronger case than an abstract desire to “use AI.”

Quantify current friction

Capture volume, frequency, time per cycle, cost of delay, rework, quality, and the people involved. Use ranges when exact figures are not available. A baseline can be improved later; an unspoken assumption cannot be managed.

Define the potential intervention

State what the proposed system would do, what it would not do, and where a person remains accountable. This is where the Theory of Constraints is useful: focus the intervention on the bottleneck with the greatest leverage rather than spreading effort across every possible use case.

Estimate value without false precision

Peter Drucker’s focus on contribution is a useful guardrail. Ask what result the work makes possible and how that result will be observed. Use a conservative range and identify the assumptions behind it.

Business case elementQuestion
ValueWhat outcome improves if this works?
EffortWhat must be built, changed, integrated, or learned?
RiskWhat could go wrong and who reviews it?
OwnershipWho is accountable after launch?
EvidenceWhat would make us scale, revise, or stop?

Evaluate risk and governance

Consider privacy, security, accuracy, bias, explainability, vendor dependence, access controls, and the consequences of an incorrect output. A lower-risk use case with a clear review process may be a better first investment than a more ambitious one.

Make the value obvious without overselling

Alex Hormozi’s emphasis on desired outcomes is relevant here: make the value understandable to the person who owns the problem. The case should explain the before, the proposed change, and the measure—not rely on jargon or inflated promises.

Decide whether to scale, revise, or stop

A business case is incomplete if it only argues for approval. Define the decision gates before work begins. What evidence would justify expansion? What signal would require a redesign? What would make the team stop?

Good discipline: write the stop criteria before the excitement of the pilot makes every result look positive.

Separate facts, assumptions, and hypotheses

A strong business case has three columns. Facts describe the current state: volume, time, errors, cost, delay, or capacity. Assumptions fill gaps where measurement is incomplete. Hypotheses describe what may improve if the intervention works. Keeping them separate prevents an attractive estimate from quietly becoming a reported result.

Use ranges and sensitivity tests. If the case only works under the most optimistic assumptions, it is not ready. Ask what happens if adoption is slower, data preparation takes longer, review effort is higher, or the expected improvement is half as large as planned.

Include the cost of organisational change

Implementation cost is not only software and engineering. It can include process redesign, training, data cleanup, governance, security review, change communication, monitoring, and the time of the people who must test and adopt the new workflow. Omitting these costs makes the case look stronger while making delivery more fragile.

A Drucker-inspired business case keeps returning to contribution: what result becomes possible, for whom, and how will the organisation know? A Theory of Constraints lens then asks whether the proposed intervention improves the constraint or merely makes a non-constraint resource busier.

Finally, define the decision gates before the pilot begins. Scale, revise, pause, and stop are all legitimate outcomes. That discipline is a sign of serious capital allocation, not a lack of belief in AI.

Further reading

This article applies Peter Drucker’s emphasis on effectiveness, contribution, and responsible management to AI decisions. The Drucker Institute is the authoritative starting point for his intellectual legacy.

The constraint-first approach draws on the Theory of Constraints, a body of practice focused on improving the part of a system that limits its performance. See TOCICO for the professional community and resources.

Talk with AI Forward about turning an AI idea into a decision-ready business case.

← Back to ArticlesStart a conversation