AI programme management
An AI business case decision-makers can evaluate
Build an AI business case with a measured baseline, alternatives, full costs and explicit assumptions. Give decision-makers evidence for the next commitment.
An AI business case should make a funding decision easier to evaluate. It needs to show the problem, the available options, the evidence behind expected benefits and the conditions under which the investment would cease to make sense.
That is a different task from selling the technology. A demonstration can make a capability tangible. It cannot establish that the capability addresses your most valuable problem, fits the operating environment or produces the return shown in a spreadsheet.
If you are preparing a proposal for executives, organise it around the next commitment. A small evaluation budget requires different evidence from a company-wide rollout. Explain what the requested commitment will buy, what it will help you learn and what decision follows.
The aim is a case that can survive challenge. A decision-maker should be able to disagree with an assumption without losing the structure of the argument.
Define the change in business terms
Describe the current process and the problem it creates. Name the affected users, frequency of the task, observable performance and consequences of leaving it unchanged. “We should use generative AI” is a technology preference, not a case for change.
Choose an outcome with a measurement route. Examples include shorter time to an approved content asset, fewer unresolved support requests or lower cost per completed localisation task. The right outcome depends on your process. Define what counts as acceptable completion before valuing more output.
Be explicit about the demand. If you create more capacity, is there useful work for it to absorb? If the process becomes faster, will the downstream team keep up? A benefit that stops at a hand-off may have less value than the proposal suggests.
Start the proposal with the decision you want. State the scope, resources, accountable owner and evidence to be collected. Readers can then judge whether the request is proportionate to the problem.
For how this fits within a portfolio, see the AI programme management guide.
Compare AI with credible alternatives
Include business as usual, process improvement and a conventional automation option where relevant. The alternatives need comparable assumptions. Do not describe AI in its best possible future and the current process only through its worst failures.
A redesigned template may remove much of the drafting burden. Better source management may solve the information problem. A rules-based workflow may be easier to control for a stable task. These options can also complement AI; the comparison helps identify which part of the change produces value.
HM Treasury's Green Book is public-sector appraisal guidance, not a private-company investment rule. Its emphasis on options and uncertainty is still a useful reference when preparing a transparent comparison.
Record why each option remains in the shortlist or is excluded. Constraints such as unavailable data, unacceptable consequences or a missing operating owner may matter more than a headline benefit estimate. A clear comparison avoids making the investment depend on excitement about a particular supplier.
Establish a baseline you can defend
Use process data from an appropriate observation period. Explain where the records come from and whether they cover routine work, exceptions and rework. When data is missing, identify the gap rather than filling it with an unlabelled estimate.
Define the unit. Cost per draft, cost per approved asset and cost per customer outcome answer different questions. Choose the unit that corresponds to the business objective and use it consistently across alternatives.
If the baseline comes from a sample, describe the sample and its limitations. A few straightforward cases may understate the current workload, but they may also make the new system look easier than it will be in ordinary use. Represent the mix that matters.
Separate recorded facts, estimates and assumptions in the proposal. Decision-makers should not have to inspect footnotes to discover which is which. This distinction makes the case easier to update after an evaluation and reduces arguments about apparently precise figures.
Separate capacity, savings and revenue
Time saved is released capacity. It becomes a cash saving only when a real expense changes. It may instead support higher throughput, faster response or better quality. Describe which route the organisation intends to take and who controls it.
Revenue benefits require another chain of evidence. More content does not automatically create more demand. More leads do not automatically produce more closed business. If an AI initiative is expected to improve sales, explain the behavioural and commercial steps between the output and the financial outcome.
Pipeline also differs from revenue. My professional profile reports €1M in pipeline, five opportunities and fifteen proposals for the Optimizely partner-led initiative in six months. These are owner-reported career results. They do not establish realised sales, a close rate or the return from an AI investment.
Avoid counting the same benefit twice. If shorter task time produces more capacity, you cannot also treat all of that time as a cash saving unless the two effects are genuinely separate. Ask finance to examine the benefit model and the action needed to realise each benefit.
Calculate the full cost of the workflow
Include setup, integration, evaluation, training, review, support and ongoing supplier charges. Count retries and discarded outputs where they affect the economics. A low price per model request is one cost component, not the total cost of the service.
Also identify costs imposed on other teams. Legal or procurement review, source maintenance and expert checking may require capacity even if no new invoice appears. Make that work visible so the receiving team can judge whether it is feasible.
Use ranges for uncertain variables. Supplier usage, task volume and correction effort may change after deployment. Show how the case behaves under a plausible less favourable scenario. If a small change reverses the conclusion, the next stage should investigate that variable.
Plan exit costs as well. Data export, replacement workflows and contract constraints can affect reversibility. The article on moving from PoC to production explains the operational responsibilities that a complete cost model should cover.
Hypothetical example: an internal content workflow
Consider a fictional team that completes 1,000 short content tasks each month. Suppose an AI draft saves three minutes per task before review. That represents 3,000 minutes, or 50 hours, of gross capacity. These inputs are illustrative and do not describe a client.
Now suppose the new checking process adds two minutes per task. The net capacity gain becomes 1,000 minutes, or approximately 16.7 hours. That calculation still says nothing about cash savings. The team must decide whether it can use the released capacity and whether quality remains acceptable.
The business case also includes setup and operating work, not only generation. If the evaluation shows that difficult cases require much more checking, the estimate should change. An average across easy tasks cannot justify extending the service to tasks the trial did not cover.
A useful funding request might therefore be a bounded evaluation of net task effort and output quality. It would not promise the gross 50 hours as a realised saving. The next commitment is designed to test the assumptions that matter most.
Give uncertainty a visible place
List the assumptions with the largest influence on the conclusion. For each one, state the current evidence, plausible range, owner and plan for resolving uncertainty. Prioritise uncertainties that could change the investment decision.
Do not use a risk register only to collect technical issues. Adoption, workflow fit, source maintenance, review capacity and supplier dependence can undermine the benefit without causing a technical outage.
The NIST AI Risk Management Framework is a useful reference for connecting risks with responsibilities throughout the lifecycle. Your business case still needs to explain the particular consequences and controls of the proposed use.
Some risks are conditions for proceeding rather than variables to price. If required data access is unresolved or a consequential failure has no workable control, adding a contingency percentage does not make the proposal ready. State the condition plainly.
Use the AI project risk register to turn uncertain assumptions into specific scenarios, accountable owners and controls. That record makes it easier to explain what must be resolved before the next funding commitment.
A worksheet for the approval conversation
Use this structure to make the proposal reviewable. Attach detailed calculations separately so the main argument remains clear.
Swipe or use the arrow keys to see every column.
| Element | What the proposal should show | Question from a reviewer |
|---|---|---|
| Problem | Current workflow, affected users and baseline | Why is this a priority? |
| Options | Comparable alternatives and constraints | Why this approach? |
| Benefits | Realisation path and evidence | Who makes the benefit happen? |
| Costs | Setup and complete operating effort | What is missing from the estimate? |
| Risks | Consequences, controls and owners | What can invalidate the case? |
| Decision | Scope, commitment and next review | What exactly are we authorising? |
Give the benefit owner a visible role. The delivery team can build a capability; another person may need to change staffing, planning or customer operations to realise value. A business case is incomplete when that change has no owner.
Invite challenge before the approval meeting. Ask an operational colleague to identify displaced work and a finance colleague to challenge benefit classification. Those reviews can expose a weak assumption while changing the plan is still inexpensive.
Fund stages with explicit exit criteria
A discovery stage should answer whether the problem and data justify evaluation. An evaluation stage should test usefulness and consequential failures. A production stage should establish operating readiness and measurable outcomes. Do not request all three commitments on the strength of evidence from the first.
At each transition, define what would support continuation, revision or closure. Set the criteria before seeing the results. This does not remove judgement, but it makes the judgement harder to rewrite around the preferred outcome.
Keep commitments proportionate. A promising evaluation may justify a limited release with clear boundaries. It does not necessarily justify a full rollout. The production KPI guide helps translate the benefit model into post-release measures.
For content-heavy use cases, AI for marketing discusses where review and approval need to remain inside the workflow.
Answer the questions the board will ask
What happens if adoption is slower? What if the supplier changes pricing or performance? Which benefit can the organisation actually realise? Who operates the service? What evidence would make you recommend stopping?
Prepare direct answers, including uncertainty. “We will test this assumption before expanding” is stronger than a precise forecast unsupported by records. Explain why the proposed stage is worth funding even while some questions remain open.
Approval is not the final measure of a good business case. The proposal should also support later review. Keep its assumptions and decision criteria available so actual outcomes can be compared with what the organisation believed when it invested.
Discuss your AI business case if the idea is convincing but the funding decision is difficult to frame. Bring the current process, available baseline and next commitment; those inputs let us work on the decision itself.
Apply this to your project
Tell me the decision you are facing, the constraints and what you have already tried.
Keep exploring
AI governance: assign responsibility before release
Make AI governance operational with clear decision rights, release gates and incident ownership. Use a charter that your team can apply to real work.
AI project risk register: turn concerns into controls
Build an AI project risk register around failure scenarios, owners and tested controls. Use a worked example to review residual risk before release.
AI roadmap prioritisation: choose what to build first
Prioritise an AI roadmap around evidence, dependencies and measurable value. Use a practical decision sheet to choose the next project with confidence.