AI Business Case and ROI Sprint
Connect AI investment to attributable value, full cost, uncertainty, and a funding decision.
Build an AI business case with a baseline, attributable benefits, full costs, risk assumptions, and a clear keep, kill, or scale decision.
About this RisePlan
Course thesis
A useful AI business case connects a specific workflow change to a measured baseline, credible alternatives, attributable benefits, fully loaded costs, risk assumptions, and a decision rule. ROI is one input; guardrails and uncertainty remain visible.
What you leave with
You will produce an AI business case with a baseline, attributable benefits, fully loaded costs, uncertainty ranges, decision thresholds, and an accountable owner.
For
Founders, finance leads, operators, product owners, and sponsors who approve, fund, or review AI initiatives.
Workflow
Frame the investment, build the ROI and unit-economics scorecard, track full cost and variance, decide keep, kill, or scale, and review value after launch.
Change
Move from approving AI through activity and forecasts to applying pre-agreed investment thresholds to observed value, cost, risk, and adoption.
What you can do
Use these as checks while you move through the plan.
Define an AI investment decision with a baseline, counterfactual, and alternatives
Calculate ROI from attributable benefit and fully loaded cost
Connect unit economics to service, quality, adoption, and risk guardrails
Track forecast, actuals, allocation, and variance on a consistent basis
Apply pre-agreed keep, kill, or scale thresholds
Run post-launch reviews that change funding, scope, or the next bounded test
Define the AI Business Case
Frame the investment decision around a defined problem, a measured baseline, realistic alternatives, and evidence thresholds agreed before spending expands.
An AI business case is the evidence required to decide whether an initiative deserves investment. It defines the business problem, current baseline, feasible alternatives, expected benefits, full costs, risks, uncertainty, decision thresholds, and evaluation plan.
Start with the decision and counterfactual. Describe what happens if the organization continues the current process, improves it without AI, buys a service, or builds the proposed AI workflow. An ROI number without a credible alternative can make weak work look valuable.
HM Treasury's appraisal guidance calls for clear objectives, options, costs, benefits, risks, proportional analysis, and an evaluation plan. It also treats optimism bias explicitly and excludes sunk costs from forward-looking choices. Source: HM Treasury, The Green Book 2026.
The AI Business Case Canvas holds one testable outcome, the baseline method, the alternative options, benefit logic, cost boundary, risk assumptions, evidence gaps, threshold, owner, and review point.
Worked example
Illustrative structure: an operations team is considering AI-assisted case triage. The business case compares the current process, a rules-based queue, a purchased service, and an AI-assisted workflow. The team records its real baseline before estimating benefit and leaves uncertain values as ranges to test.
Quality checklist
The business problem names a live workflow and affected owner
The baseline has a source, period, and measurement method
At least one non-AI alternative is considered
Benefits and costs use the same scope and time horizon
Uncertain inputs remain visible as assumptions or ranges
The decision threshold is agreed before the review
Common mistakes
Starting with a preferred tool instead of a business decision
Using a target as if it were the measured baseline
Comparing the AI option only with doing nothing
Counting sunk costs as a reason to continue
Leaving uncertainty hidden inside one precise forecast
Exercise
Frame One Live AI Investment Decision
Choose one proposed or active AI initiative. Complete the canvas with the people who own the workflow and the budget.
Record:
- Decision to make
- Business problem and affected workflow
- Current baseline and measurement method
- Do-nothing counterfactual
- Non-AI and AI alternatives
- Expected financial and nonfinancial benefits
- Cost boundary
- Material risks and assumptions
- Evidence gaps
- Threshold for keep, kill, or scale
- Accountable owner and review point
Output to complete
AI Business Case Canvas
Copyable template
Decision to make:
Business problem and workflow:
Baseline and method:
Counterfactual:
Alternatives considered:
Benefits:
Cost boundary:
Risks and assumptions:
Evidence gaps:
Decision threshold:
Owner and review point:
Use this at work tomorrow
Write the decision, baseline source, and strongest non-AI alternative for the AI initiative currently asking for funding.
Core idea
A credible AI business case compares options, measures the baseline, and sets the decision threshold before the next funding review.
Build the ROI and Unit-Economics Scorecard
Calculate ROI from attributable benefit and fully loaded cost, then pair it with unit economics and guardrails that protect service, quality, and risk.
AI ROI percentage compares attributable financial benefit with the full cost of achieving it. Use the formula ((attributable financial benefit - total cost) / total cost) × 100%, and keep nonfinancial benefits separate unless finance approves a defensible monetary conversion.
Define the unit of value before calculating ROI. Useful units might be cost per resolved case, contribution per qualified order, downtime cost per production hour, or cost per compliant document. Pair the business unit metric with service, quality, adoption, and risk guardrails.
The FinOps Foundation recommends connecting technology cost to business-value metrics, defining unit measures and thresholds, and allocating shared cost so owners can act. Source: FinOps Foundation, Unit Economics.
The AI ROI Scorecard records baseline volume and unit cost, attributable benefit, fully loaded cost, nonfinancial outcomes, guardrails, assumptions, confidence, owner, and decision threshold.
Worked example
Illustrative template only: baseline volume [enter actual], baseline unit cost [enter actual], attributable benefit [enter approved value], total cost [enter fully loaded value], ROI percentage [((benefit - cost) / cost) × 100%]. Leave the result blank until finance validates the inputs and attribution method.
Quality checklist
Benefit and cost use the same scope, period, and population
Attribution method is written and reviewable
All material one-time and recurring costs are included
Nonfinancial benefits stay separate unless conversion is approved
Guardrails cover service, quality, adoption, and risk
Finance and workflow owners validate the inputs
Common mistakes
Counting gross time saved as cash benefit without showing how capacity changes
Using revenue instead of contribution or attributable margin
Leaving implementation, integration, review, and change costs outside the denominator
Mixing annual benefits with monthly costs
Monetizing every nonfinancial benefit to inflate ROI
Ignoring quality or risk deterioration when cost falls
Exercise
Build the ROI Scorecard
Use one live initiative and finance-approved data. Do not fill unknown cells with estimates disguised as actuals.
Record:
- Outcome and unit of value
- Baseline period, volume, and unit cost
- Comparison or counterfactual
- Attributable financial benefit
- One-time and recurring costs
- Total cost for the same period
- ROI formula and result
- Nonfinancial benefits
- Quality, service, adoption, and risk guardrails
- Assumptions and confidence
- Decision threshold and owner
Output to complete
AI ROI and Unit-Economics Scorecard
Copyable template
Outcome and unit of value:
Baseline period, volume, and unit cost:
Counterfactual or comparison:
Attributable financial benefit:
One-time costs:
Recurring costs:
Total cost:
ROI percentage: ((attributable benefit - total cost) / total cost) × 100%
Nonfinancial benefits:
Guardrails:
Assumptions and confidence:
Decision threshold and owner:
Use this at work tomorrow
Ask finance to validate the benefit, total-cost boundary, attribution method, and time horizon for one AI initiative.
Core idea
AI ROI needs attributable benefit, fully loaded cost, a consistent period, and guardrails that stop savings from hiding poorer work.
Track Full Cost, Forecast, and Variance
Build a fully loaded cost view, compare forecast with actuals on the same basis, explain variance, and trigger action at pre-agreed thresholds.
An AI budget should include the costs required to reach and sustain the claimed outcome: internal labor, data work, integration, model or API use, infrastructure, vendors, evaluation, security and legal review, change support, monitoring, incident response, and retirement.
Allocate shared costs using a documented rule and reconcile forecast with actuals for the same period. When a cost cannot be allocated directly, label the method and confidence instead of hiding it in a platform total.
The FinOps Foundation treats forecasting as a recurring comparison of plans with actual use and cost, with variance analysis feeding future decisions. Source: FinOps Foundation, Forecasting.
The AI Cost and Variance Tracker records each cost line, driver, allocation rule, forecast, actual, variance, explanation, threshold, owner, and corrective action. Thresholds belong to the business case and should be set before the review.
Worked example
Illustrative table structure:
| Cost line | Driver | Allocation rule | Forecast | Actual | Variance | Cause | Threshold | Owner | Action |
|---|---|---|---|---|---|---|---|---|---|
| [enter] | [enter] | [enter] | [finance input] | [finance input] | [calculate] | [explain] | [pre-agreed] | [name] | [decide] |
Quality checklist
Material labor, data, integration, control, and run costs are included
Shared costs use a documented allocation rule
Forecast and actuals use matching scope and periods
Variance calculations can be reproduced
Thresholds were set before review
Every material variance has an owner and action
Common mistakes
Tracking only model or cloud charges
Mixing cash cost, allocated cost, and avoided cost without labels
Comparing forecast and actuals from different periods
Changing thresholds after seeing the variance
Explaining an overrun without assigning corrective action
Scaling volume before unit cost and guardrails are stable
Exercise
Build the Cost and Variance Tracker
Choose one live initiative and use finance records for a consistent period.
For each cost line, record:
- Cost category and driver
- Direct or shared
- Allocation rule
- One-time or recurring
- Forecast
- Actual
- Absolute and percentage variance
- Cause and confidence
- Pre-agreed threshold
- Owner
- Corrective action
Include labor, data, integration, model or API use, infrastructure, vendors, evaluation, controls, change support, monitoring, and retirement where material.
Output to complete
AI Cost and Variance Tracker
Copyable template
Cost category and driver:
Direct or shared:
Allocation rule:
One-time or recurring:
Forecast:
Actual:
Absolute variance:
Percentage variance:
Cause and confidence:
Pre-agreed threshold:
Owner:
Corrective action:
Use this at work tomorrow
Ask finance and engineering to agree the full cost boundary and allocation rule for the highest-spend AI initiative.
Core idea
AI budget control starts with a fully loaded cost boundary, consistent periods, and thresholds set before actuals arrive.
Make the Keep, Kill, or Scale Decision
Apply pre-agreed thresholds to ROI, cost, risk, adoption, and operating evidence, then record a bounded keep, clear kill, or justified scale decision.
The decision is keep, kill, or scale, based on thresholds agreed before the review. Prior spending is a sunk cost and should not determine whether more funding is justified.
Kill when the core outcome misses its threshold, unacceptable risk remains, or there is no credible path within the approved cost and time boundary. Record closure, contract, data-retention, and workflow-transition actions.
Keep when evidence is promising but incomplete. Continue only in a bounded scope with one named test, budget cap, owner, and decision date. Keep is not permission for indefinite pilot drift.
Scale when the outcome is reproduced in live work, attribution is credible, guardrails hold, operating ownership is clear, and unit economics support wider use. The Keep, Kill, or Scale Memo makes the evidence, dissent, decision, and next action visible.
Worked example
Illustrative decision logic: choose keep only if a bounded follow-up test can resolve the named evidence gap within the existing cap; choose kill if the outcome or risk threshold cannot be met; choose scale only after live results, controls, ownership, and unit economics support broader use.
Quality checklist
The original threshold is shown beside the result
ROI, cost, guardrails, and uncertainty are all visible
Sunk cost is excluded from the forward decision
Keep has a named test, cap, owner, and decision point
Kill includes closure responsibilities
Scale includes operating capacity, controls, and unit economics
Common mistakes
Moving the threshold after results arrive
Treating sunk cost as evidence for another funding cycle
Using keep without a named evidence gap, cap, and decision point
Scaling a technical result before live workflow and guardrails hold
Killing the tool without planning data, contract, and workflow closure
Leaving dissent or uncertainty out of the memo
Exercise
Write the Funding Decision Memo
Choose one initiative due for review. Attach the current business case, ROI scorecard, cost tracker, risk evidence, and dissenting view.
Write:
- Decision requested
- Pre-agreed thresholds
- Evidence against each threshold
- Attribution and uncertainty
- Budget and variance
- Guardrail status
- Decision: keep, kill, or scale
- Rationale
- Dissent or unresolved evidence
- Funding and scope consequence
- Owner and next action
- Next decision point, only when the decision is keep
Output to complete
Keep, Kill, or Scale Decision Memo
Copyable template
Decision requested:
Pre-agreed thresholds:
Evidence against each threshold:
Attribution and uncertainty:
Budget and variance:
Guardrail status:
Decision: keep/kill/scale
Rationale:
Dissent or unresolved evidence:
Funding and scope consequence:
Owner and next action:
Next decision point, if keep:
Use this at work tomorrow
Draft the decision line and threshold table for the AI initiative with the most ambiguous next funding call.
Core idea
Keep is a bounded test, kill includes an exit plan, and scale requires reproduced value with workable controls and unit economics.
Review Value After Launch
Turn the original business case into a live review loop that compares forecast with observed value, cost, risk, and adoption after launch.
An approved business case is a forecast, not proof. After launch, compare observed outcomes, costs, guardrails, and adoption with the baseline and counterfactual, then update the next funding decision.
Review cadence should match the workflow's risk, value, and speed of change. Use scheduled reviews plus event triggers for material cost variance, quality failure, incident, vendor change, model change, or data drift.
The U.S. Government Accountability Office organizes AI accountability around governance, data, performance, and monitoring, including clear goals, performance metrics, and ongoing assessment. Source: U.S. GAO, AI Accountability Framework.
The AI Value Review Playbook records what changed, actual outcomes and costs, attribution confidence, guardrail events, unresolved assumptions, decision, actions, owners, and the next scheduled or event-triggered review.
Worked example
Illustrative review structure: compare the approved threshold with the current evidence, list material changes since approval, record confidence and confounders, apply the decision rule, and assign each follow-up action. Do not invent missing actuals to complete the meeting pack.
Quality checklist
Actuals come from named systems or accountable owners
The original baseline, counterfactual, and threshold remain visible
Attribution confidence and material confounders are recorded
Guardrail events are reviewed beside financial results
The decision changes funding, scope, or the next bounded test
Actions have owners and scheduled or event-based triggers
Common mistakes
Reviewing a dashboard without making a funding decision
Dropping the original baseline or threshold from the pack
Ignoring workflow, model, vendor, or data changes that break comparison
Reporting time saved while adoption or quality guardrails fail
Leaving actions without owners or triggers
Scheduling reviews by habit without event-triggered escalation
Exercise
Run the Post-Launch Value Review
Choose one initiative with enough operating evidence for review. Bring the original business case, current ROI scorecard, cost tracker, incident and quality records, adoption evidence, and prior decisions.
Review:
- Baseline and counterfactual still valid?
- Observed outcome and attributable benefit
- Forecast versus actual cost
- Unit economics at current volume
- Quality, service, adoption, and risk guardrails
- Changes to workflow, data, model, vendor, or regulation
- Unresolved assumptions and confidence
- Keep, kill, or scale decision
- Actions, owners, and triggers for the next review
Output to complete
AI Value Review Playbook
Copyable template
Initiative and decision owner:
Original baseline and threshold:
Counterfactual status:
Observed outcome and attributable benefit:
Forecast versus actual cost:
Unit economics:
Guardrail status and events:
Material changes since approval:
Unresolved assumptions and confidence:
Decision: keep/kill/scale
Actions and owners:
Next scheduled or event-triggered review:
Use this at work tomorrow
Add the original threshold, current actuals, guardrail status, and decision line to the next AI funding review agenda.
Core idea
The post-launch review asks whether observed value still justifies cost and risk, then changes funding or scope accordingly.
30-day path
Week 1: Complete the AI Business Case Canvas with the workflow owner and finance.
Week 2: Validate the ROI, unit-economics, guardrail, and attribution inputs.
Week 3: Reconcile fully loaded forecast and actual cost, then explain material variance.
Week 4: Apply the pre-agreed threshold and circulate the Keep, Kill, or Scale Decision Memo.
After launch: Run scheduled and event-triggered value reviews using observed evidence.
Success signals
Reviewed initiatives have a sourced baseline, counterfactual, alternatives, and pre-agreed decision threshold
ROI inputs can be reproduced from attributable benefit and fully loaded cost records
Material cost variance, attribution uncertainty, and guardrail events have named owners
Each funding review ends in a recorded keep, kill, or scale decision
Kept initiatives have a bounded test; killed initiatives have closure actions; scaled initiatives have operating ownership
Reflection prompts
Which benefit is genuinely attributable to the AI workflow?
Which material cost or risk currently sits outside the business case?
What evidence would move the next decision from keep to kill or scale?
Manager checklist
Require a measured baseline and credible alternatives before approval.
Ask finance to validate attribution, cost boundary, and time horizon.
Set decision thresholds before results are interpreted.
Review guardrails beside the ROI result.
Record funding, scope, ownership, and closure consequences.
Want this shaped around your company?
Risey can research your company foundation first, then build a version of this path around your real workflows, customers, and culture.
Start with your company