Aminata Osei-Bonsu, Program Director for Benefits Administration at the Oregon Department of Human Services, had 72 hours to answer the Governor's budget office. An AI-assisted document processing pilot had cut application review time by 40 percent in a three-county test, and the budget office wanted the agency-wide picture, dollar cost, timeline and staff impact, before it would put anything into the biennial appropriations request. Aminata had the data. What she did not have was the story that would move a skeptical legislature to fund it.

This lesson is about building that story. Not the technology story, the investment story: the one that survives a budget hearing, a Freedom of Information Act (FOIA) request, an equity audit, and a change in administration. Everything below is a way of turning operational results into an argument a budget analyst can defend in public, and a way of checking your own numbers before someone less friendly does it for you.

Why the ROI Question Is Harder in Government

Here is the question that stops government AI leaders cold: what is the return on investment for this project? A company knows its answer, because the answer is revenue, cost, or market share. Your benefits are citizens served faster, better decisions, less fraud, more equitable outcomes, stronger compliance. How do you put a number on serving people faster, or on improved trust in government? You still have to answer. Budget committees demand it, oversight bodies demand it, and the agency head deciding whether to fund your pilot wants to know whether it is worth the money.

Government ROI is genuinely harder to quantify than private-sector ROI, but the underlying discipline is identical. What does this investment enable? What benefits flow from it? What does it cost? Is it worth it? The difference is that your benefit ledger has more columns, several of them are not denominated in dollars, and every figure you publish can be pulled apart by an auditor three years later. That is not a reason to avoid numbers. It is a reason to be careful with the ones you use.

Government AI as Infrastructure, Not Software

The most durable frame for a government AI business case is infrastructure. Not software, not a vendor contract, infrastructure. When Oregon built the Newberg-Dundee bypass, the legislature did not ask for a return on investment in the traditional sense. It asked how many commute-hours would be saved per year, how many accidents prevented, and what the cost per resident served would be over 30 years. That is the language of public investment: deferred costs, compounding benefits, and equity of access.

AI in government works the same way. The benefits compound, the equity stakes are real, and the accountability horizon is long. Once you accept that frame, the rest of the business case gets clearer, because you stop trying to force a technology purchase into a profit-and-loss shape it was never going to fit. A government AI investment is not a line-item expense. It is closer to the new road that determines whether every other service runs faster or slower for the next decade.

What a Business Case Actually Is

A business case is a structured argument for why an investment makes sense. It answers five questions: what problem are we solving, how much does that problem cost us today, how will the solution change things, what investment is required, and how long until value is realized. Everything else in the document exists to support those five answers. If a section of your draft does not serve one of them, it is padding, and budget analysts who read dozens of these will find it faster than you think.

In government the document does four jobs at once. It forces you to think clearly about what you are trying to accomplish and why. It justifies budget requests to oversight bodies and appropriators. It establishes baseline metrics so you can later measure actual outcomes against predicted ones. And it creates accountability: if you said you would save ten thousand hours a year, someone will eventually ask whether you did. That last job is the one people forget they signed up for, and it is the reason conservative projections are worth more than impressive ones.

Five Categories of Benefit, Not One

A government business case has to address more than money. Fiscal benefits cover cost savings, reduced processing costs and improved efficiency. Operational benefits cover faster service delivery, smaller backlogs and better quality. Equity benefits cover better service to underserved populations, more equitable access and reduced bias. Compliance benefits cover audit readiness, reduced risk and improved governance. Intangible benefits cover public trust, employee satisfaction and institutional capability that makes the next project cheaper.

The trap is overweighting the fiscal column. You might save a large sum each year in processing costs and still lose more than you gained if the public concludes your system is unfair or opaque. The reputational cost of that is real even though it never appears on a ledger. Your case should account for both tangible and intangible benefits, and should be explicit about which is which, because a reviewer who cannot tell them apart will discount all of them equally.

Four ROI Models Built for Public-Sector Realities

Private-sector ROI models rarely translate cleanly, because government does not maximize profit. It maximizes public value under budget constraints and legal obligations. Four categories carry most public-sector cases, and the strongest business cases use all four rather than leaning on whichever one produces the largest number. Each has a different evidentiary standard, and each fails in a different way when a legislative auditor examines it.

Cost avoidance

Cost avoidance is the most powerful category and the most underused. It asks what you would have spent had you not deployed the system. Oregon's benefits pilot avoided an estimated $1.4 million in overtime and temporary staffing during the 2025 summer surge, when Medicaid re-enrollment volume jumped 38 percent after a federal policy change. The agency did not hire 22 temporary workers it had budgeted for. That budget line never appeared, which is exactly why cost avoidance is hard to sell: you are showing a number that exists on no ledger.

To make it visible, document the counterfactual. What was the staffing model before the pilot? What did the surge cost in prior years? What would this year's surge have cost without AI assistance? Build the table and show the delta. A cost-avoidance claim with no documented baseline is indistinguishable from an assertion, and reviewers treat it accordingly. With the baseline attached it becomes the most persuasive line in the document, because it maps directly onto a decision the agency chose not to make.

Time savings converted to labor value

Time savings are the easiest to measure and the most scrutinized. The formula is hours saved multiplied by the fully loaded cost per hour of the staff role, where fully loaded means salary plus benefits plus overhead, typically 1.3 to 1.5 times base salary for state employees. Publish the multiplier you used. Half the disputes about time-savings figures turn out to be disputes about whether overhead was counted, and they are much easier to settle before the hearing than during it.

In Oregon's case, each eligibility specialist recaptured an average of 11 minutes per application review. At 1,800 applications per week agency-wide, that is 330 staff-hours per week. At a fully loaded rate of $58 per hour, that is $19,140 per week, or roughly $995,000 per year in recaptured staff capacity. Every step there is reproducible from the inputs, which is the property you want. A reader who disagrees can substitute their own rate and recompute, rather than having to take your total on faith.

Be precise about what recaptured means. Staff do not disappear. The time shifts to higher-value work: complex case management, outreach to eligible residents who never enrolled, appeals processing that had been backlogged for 14 weeks. Legislators respond better when you name what people do with recovered time than when you imply the recovered hours are cash. If your case does imply cash, say plainly whether any position is actually being eliminated, because someone will ask and the answer should not be a surprise.

Quality improvement and error reduction

Errors in government cost real money and cause real harm. Benefits overpayments trigger federal audit findings and repayment obligations. Underpayments expose agencies to due-process litigation. Inconsistent eligibility determinations create disparate-impact liability. Each of those has a cost your financial management system already tracks, which makes this category unusually well evidenced compared with the others.

Oregon's pilot reduced document-classification errors by 62 percent compared with manual processing. That fed a 17 percent reduction in incomplete application rates, which in turn cut average time-to-determination from 23 days to 14. Faster determinations mean fewer emergency interim payments, fewer appeals, and lower administrative law judge hearing load. Quantify those downstream costs for your own agency: appeals volume, litigation settlements, federal audit findings, and re-processing labor are all in your systems already, and they are usually eye-opening when aggregated.

Citizen value, the hardest and most important category

Citizen value appears on no government balance sheet, yet it drives legislative support and it is the honest reason most of this work matters. Cutting time-to-determination from 23 days to 14 means a family knows nine days sooner whether it qualifies for food assistance. That has economic value: avoided payday loan fees, avoided utility disconnection charges, avoided emergency room visits from deferred care. Researchers at the Urban Institute estimate that each day of benefits delay costs low-income households an average of $4.70 in downstream financial impact.

You cannot book that as agency savings. You can cite it, name the person behind the statistic, and build an addendum that explains the full public value of speed, accuracy and access. Keep it in its own section rather than blending it into the fiscal total. A reviewer who finds an unbookable estimate quietly added to a savings line will discount the whole document, and they will be right to.

Start by Quantifying the Problem

Every credible case begins with the current state, not the solution. How many applications do you process a year? How long does processing take? What is the error rate? What does the problem cost, in processing expense, backlog, dissatisfaction and compliance exposure? Which residents does it affect, and which strategic objectives does it touch? Answer those before you name a technology, because the answers are what any later claim of improvement will be measured against.

Be specific. Slow processing is vague. A statement of the form "application processing takes six months on average, so citizens wait six months for benefits they are eligible for immediately, at an estimated annual cost of a stated figure in delayed payouts and administrative expense" is quantifiable, and quantifiable is the only kind of problem statement that supports a defensible benefit claim later. It also protects you against the straw-man baseline, which is the third of the four classic ways these documents fail.

Counting the Full Cost, Including the Parts Nobody Budgets

Government business cases routinely underestimate true cost by ignoring the unglamorous lines. Be comprehensive across five categories: development, meaning the data scientists, engineers and tooling to build the system; infrastructure, meaning cloud, data platforms and hosting; change management, meaning training, communication and support through the transition; governance and oversight, meaning the processes and the compliance staff to run them; and ongoing operations, meaning monitoring, model retraining and human review.

Change management and governance are the two that get dropped, and they are frequently larger than the development line. If overseeing the system and keeping it compliant requires a handful of new staff, that is part of your ongoing cost and belongs in the request. A case that funds the build but not the operation produces a system that degrades after the launch budget runs out, which is a slower and more expensive failure than never building it.

Be Honest About When Benefits Arrive

Benefits do not arrive on the day the contract is signed. A realistic phasing runs in three stages. Months one through six are development: high cost, minimal benefit realization. Months seven through twelve are pilot: partial benefit realization, with some costs starting to decline. From month thirteen you are in full deployment, where benefits realize fully and costs stabilize at the ongoing run rate. Those windows are illustrative rather than universal, and your own phasing should reflect your procurement and integration reality.

Government technology projects are notoriously overoptimistic about how fast benefits realize, and the optimism is rarely deliberate. It comes from planning the build and forgetting the adoption. Build realistic buffers, and present the first-year benefit as partial rather than annualized. If your Year 1 line shows a full year of savings from a system that goes live in month seven, an experienced analyst will find it, and everything else in the document will inherit the doubt.

Risk, Sensitivity, and the Alternatives You Rejected

State what could go wrong and what you would do about it. Typical risks include data quality problems that prevent deployment, public opposition, technical delays, benefits landing materially below projection, and regulatory changes that force a redesign. For each one, give a likelihood, an impact, and a mitigation. A risk register with three honest entries beats a page of generic hazards, because the reviewer is testing whether you have thought about failure, not whether you can list it.

Then show the projection under more than one scenario: a base case where most benefits realize on schedule, a pessimistic case where roughly half realize and the timeline slips by months, and a best case slightly above plan. Sensitivity analysis is not hedging. It tells the reader which assumption the whole case rests on, and that is usually one variable, such as adoption rate or document complexity at scale.

Finally, compare against the alternatives you did not choose: the status quo, process redesign without AI such as hiring more staff or streamlining the workflow, a commercial off-the-shelf product, and a different technical approach such as a rules-based system. Compare cost, timeline, benefits and risk for each. If the rules-based option is nearly as good and much cheaper to govern, your case is stronger for saying so, and you will not be ambushed with it later.

Three Worked Cases, and What Their Arithmetic Shows

The three cases below are teaching sketches rather than audited results, and they are most useful when you check each total against its own stated inputs. Two of the three do not fully reconcile, and the ways they fail are the ways real submissions fail. Where a figure does not follow from the inputs, the inputs are kept here and the derived total is dropped, so you can run the sum yourself and see what it actually supports.

Case one: benefits processing automation

A large benefit agency processes 5 million applications a year, taking six months on average, at $150 per application. That multiplies to $750 million in annual processing cost, which checks out. The agency also estimates roughly $100 million in delayed benefit payouts to citizens waiting for benefits they already qualify for. The proposed system screens applications and identifies the 60 percent that are straightforward approvals; those clear in two weeks, and complex cases go to human reviewers.

The case also claims that average processing falls from six months to four. Weight the two stated groups and you do not get four months: 60 percent at two weeks plus 40 percent at six months lands well below that. Keep the split, which is the real claim, and drop the blended average. The benefit line does hold up: cost per application falling from $150 to $70 is $80 across 5 million applications, which is the $400 million a year the case states.

The investment lines are development $8 million over one year, infrastructure $2 million a year, change management $1 million, and governance and oversight $1 million a year. The steady-state arithmetic is clean: ongoing cost of $3 million against $400 million in annual savings leaves $397 million, exactly as stated, and change management is correctly excluded because it is one-time. The Year 1 total is where it breaks. As printed it adds development to infrastructure and governance only, omitting the change-management line entirely, so the stated first-year cost and the net benefit derived from it are both dropped here. The cost components are kept above; add them yourself. Note what that error is: this document warns against ignoring change management two sections later, then does it in its own worked example.

Case two: fraud detection at a tax authority

Two hundred million returns are filed annually and the audit rate is 0.5 percent, which is one million audits, and that multiplication checks out. Audits are effectively random, hitting compliant and non-compliant filers alike, so most find nothing significant. The case also states $5 million in audit costs, which against one million audits implies about five dollars per audit. That is not a credible unit cost for an audit, so the figure is dropped here and the audit volume kept.

Watch the metric definition in this one. The 0.5 percent begins as the share of returns audited and is then reused as a detection rate rising to 2 percent. Those are two different quantities wearing the same number, and conflating them is exactly the sort of thing that unravels under questioning. Define each rate explicitly: share of returns selected, and share of selected returns that find something. The claimed fraud detection rising from $500 million to $2 billion is a fourfold increase, which is at least consistent with the fourfold rate change.

The investment is $4 million development plus $1 million a year ongoing, and the steady-state arithmetic checks out: an additional $1.5 billion (the $2 billion less the original $500 million) against $1 million of ongoing cost leaves $1.499 billion. One caveat belongs in any case like this: detected fraud is not collected revenue, and a business case that treats detection as if it were recovered money is claiming a benefit it has not yet earned. The other caveat is political. Targeting audits by risk score is defensible only if you can also show it does not concentrate enforcement on a protected group.

Case three: skills matching at a labor ministry

One hundred thousand workers a year are displaced by automation and job elimination. The current retraining success rate is 40 percent, largely because workers do not know what options exist, and unemployment benefits for this population cost the government $200 million annually. The proposed system analyzes worker skills, recommends emerging opportunities, and connects people to retraining, lifting the success rate to 60 percent. That yields 20,000 additional successful transitions a year, and that multiplication checks out.

The claimed saving of $100 million a year does not follow from those inputs. Spread $200 million across 100,000 workers and the implied cost per worker is far too small for 20,000 additional transitions to produce $100 million, so the savings figure and the net-benefit lines derived from it are dropped here. What remains is still usable: the displaced population, the two success rates, the 20,000 additional transitions, and the investment of $5 million in development plus $2 million a year ongoing. Supply your own benefit cost per worker and the case rebuilds itself honestly.

One structural observation about all three. Each presents a net benefit far larger than its cost, and each does so with round numbers. That is the shape of an illustration, not of an audited result, and it is worth noticing precisely because this lesson also warns against inflated projections. Treat these as templates for the arithmetic, not as benchmarks for what your own project should promise.

Navigating Public-Sector Budget Cycles

Government budget cycles are not optional calendars. They are legal frameworks with hard deadlines, and AI projects that miss them wait for the next window. Most states operate on biennial budgets. Oregon's runs July 1 through June 30 of odd-numbered years. The Governor's recommended budget is submitted in December, and agency budget requests are due to the Department of Administrative Services in September, well before the biennium starts. A project that is not in the September request cannot receive new general fund appropriations until the following biennium, two years later.

Three strategies help you work inside those constraints, and the first two are what let Aminata answer the budget office at all.

1. Start with existing budget authority. Many agencies hold discretionary spending in their operating budgets, typically 3 to 8 percent of the personnel services budget, that does not require legislative appropriation. Use it to fund a time-bounded pilot. The pilot generates the data you need for the next appropriations cycle, which is the only way to arrive at the hearing with evidence instead of a proposal.
2. Use federal matching funds early. Programs receiving federal matching funds, including Medicaid, SNAP (Supplemental Nutrition Assistance Program) and TANF (Temporary Assistance for Needy Families), can often draw federal match on administrative improvement investments. Oregon's pilot drew federal administrative match under Centers for Medicare & Medicaid Services enhanced funding provisions: the state general fund contribution was $340,000 against a pilot approaching $1 million. Confirm your own match authority and rate with your federal program office before you assume either.
3. Align the ask with the budget narrative already being told. Budget offices are not neutral; they work from a political framework. If the executive priority is reducing workforce costs through attrition, frame the case as enabling attrition without service degradation. If the priority is equity, lead with the disparate-impact reduction data. Read the budget instructions memo every year, because it tells you the story the executive branch wants told.

Procurement Realities That Shape the Document

Your business case is not only an argument for funding. It is the foundation of your procurement record. In Oregon, technology contracts above $250,000 require an alternative procurement process or a competitive solicitation under ORS 279B, and the case you write today becomes the first exhibit in your Request for Proposal. Write it knowing that a losing bidder may challenge your methodology and that a legislative auditor may test your projections against actual outcomes years later.

Document assumptions explicitly. If you project a 40 percent processing time reduction, state the basis: a three-county pilot, 14 weeks, 4,200 applications processed. Do not extrapolate without naming what changes at scale, including document complexity, legacy system integration and staff training curves. Honest uncertainty strengthens a case because it signals institutional maturity. Legislators and auditors distrust projections that show only upside, and they have earned that reflex.

Quantifying Benefits That Resist Quantification

Some of the most important benefits are genuinely hard to measure. Three techniques help without pretending to precision you do not have. The first is equivalency benchmarking: find a comparable benefit already valued in your accounting. Oregon uses a cost-per-case-served metric across benefits programs, so a fall from $187 to $112 per case can be compared directly against efficiencies achieved by other program improvements and shown to compete on a per-dollar basis.

The second is proxy metrics with stated limitations. Aminata's team could not directly measure household economic stability, so they measured application completion rates, up 22 percent; re-application after denial, down 31 percent; and average days to first payment, down nine days. Those are proxies and were labelled as such. They signal improvement without claiming certainty about outcomes, and the labelling is what makes them survive review rather than a weakness to be hidden.

The third is constituent testimony as qualitative evidence. A single well-chosen story, used with consent, can change a hearing room: fourteen days instead of 23, described in testimony to the Joint Ways and Means Committee as nine days a parent did not have to skip meals, set against 94,000 annual determinations. Story anchors the number and the number validates the story. Note that 94,000 annual determinations is consistent with the 1,800 per week used earlier, which is the sort of internal check a reviewer will run whether or not you do.

Making the Case Credible

Decision-makers are skeptical of optimistic projections because they have been burned by them. Six habits build credibility. Be conservative: if you think you will save 20 percent of processing costs, claim less, because overdelivery buys you the next project. Ground projections in data from comparable programs rather than assertion. Include the dissenters instead of pretending consensus, and say what the skeptics believe and why you disagree. Commit to measuring actual outcomes against projections and reporting them. Explain the risks. And keep tangible and intangible benefits visibly separate, so nobody has to guess which figures are measured and which are estimated.

None of this is modesty for its own sake. A case that projects 20 percent and delivers 25 gains credibility that funds the next three projects. A case that projects 50 percent and delivers 25 loses it, and the loss lands on your whole agency's AI program, not just on the one project that missed. Credibility is the asset you are actually managing here, and it compounds in both directions.

Structuring the Business Case Document

A government AI business case runs to six sections, each kept short. Budget office analysts read dozens of these, so density is a feature and length is a liability.

1. Executive summary, one page. Problem statement, proposed solution, total investment, primary benefit categories, implementation timeline. No jargon.
2. Current state analysis. Baseline metrics, documented pain points, staff and process costs, error and appeals rates. This is your before picture, and it is what every later claim is measured against.
3. Proposed solution. What the technology does, what it does not do, the vendor if known, integration requirements with legacy systems, and the data governance approach.
4. Financial analysis. All four ROI categories, assumptions stated, sensitivity ranges included. What happens if adoption is 20 percent below projection? What is the break-even timeline?
5. Risk and mitigation. Technology, procurement, equity and workforce risk, each with a response. Show that you have thought about what goes wrong.
6. Implementation plan. Phases, milestones, dependencies, staffing, and a go/no-go evaluation framework. Government funders want off-ramps, and giving them one makes approval easier, not harder.

Equity Obligations Are Not Checkboxes

Every government AI deployment that touches service delivery carries an equity obligation, and in Oregon that obligation has teeth: ORS 659A.142 prohibits discriminatory impact in public services, and OAR 125-070 governs equity impact requirements for significant technology contracts. Your case must address whether the system performs equally well across demographic groups, what the error rate is for applicants who do not speak English compared with those who do, and what happens to residents who cannot engage with a digital process at all.

Oregon's pilot found a 6 percent higher document-rejection rate for handwritten materials, which came disproportionately from elderly applicants and those without home printers. Aminata's team flagged it, added a human review pathway, and documented the mitigation. That transparency cost the program nothing and reduced its exposure to a civil rights challenge that would have cost a great deal. Treat equity analysis as risk management rather than compliance theater: a system that serves 80 percent of your population well and 20 percent poorly will eventually generate more cost in litigation, re-processing and political opposition than it saves.

Anti-Patterns

Four failures account for most rejected or later-discredited government AI business cases. Each is easy to commit in good faith.

• Inflated projections. You want the project funded, so you promise aggressive benefits and tell yourself they are stretch targets. When results miss, credibility collapses, leadership concludes that AI projects always underdeliver, and future requests die on arrival. Build in margin and overdeliver.
• Ignoring costs. You count development and skip change management, governance and ongoing operations. You win the build money and then cannot afford to run what you built. Force the full cost list, and check it with your finance and IT colleagues rather than estimating alone.
• An unrealistic baseline. You compare against doing nothing, when the honest comparison is continuing as you are, hiring more staff, or buying an off-the-shelf product. A straw-man baseline inflates the case, and a savvy reviewer who spots it will discount everything else you wrote.
• Ignoring negative outcomes. You project only upside and omit staff displacement, bias risk and opacity to the public. Oversight bodies learn about these afterwards and conclude you were either dishonest or unaware. Naming a downside alongside its mitigation is more persuasive than claiming there are none.
• Publishing a total nobody can reproduce. If a reader cannot rebuild your headline figure from the inputs on the page, the figure is an assertion. Every worked example in this lesson that failed did so at exactly this point: a total that no longer matched the components printed above it.
• Quoting a payback period with no cost input. A break-even claim requires a stated total cost of ownership. If the cost of the tool, the integration and the ongoing operation is not somewhere in the document, the payback number is unsupported no matter how carefully it was calculated elsewhere.
• Annualizing a partial year. Showing twelve months of savings from a system that goes live in month seven is the most common way an otherwise honest case becomes indefensible. Phase the benefit line against the deployment schedule you published two pages earlier.
• Letting one number wear two meanings. A rate that starts as the share of cases selected and later becomes the share of cases where something was found is two quantities, not one. Define each metric in the document, because a reviewer who catches the switch will reasonably assume the rest of the analysis is equally loose.

Practice Prompts

• Problem quantification. Take a problem your agency faces, such as long processing times or high error rates. Quantify it: how many people it affects, what it costs, how much time it consumes. Cite where each number came from.
• Benefits projection. For one specific AI solution, project the benefits. How much faster, how much cheaper, how much more accurate, and what is your confidence in each?
• Cost estimation. Estimate total cost for that project across all five categories: development, infrastructure, change management, governance, and ongoing operations. Leave nothing out, then have someone in finance try to add a line you missed.
• Business case development. Write a one-page case using the six-section structure. Include problem, solution, benefits across the categories, costs, timeline and key risks.
• Sensitivity analysis. Build pessimistic and best-case versions of your base projection. How do benefits and net position change, and which single assumption moves the answer most?
• Arithmetic audit. Hand your draft to a colleague with one instruction: recompute every figure from the inputs printed on the page. Any number they cannot rebuild is a number you have to source or drop.

Reflection

Think of an AI project you are considering and write its business case using this framework: problem, solution, benefits across fiscal, operational, equity and compliance categories, costs, timeline and risks. What is the net position in Year 1, and in Year 2? What is your confidence level, and what specific evidence would change it? Then ask the harder question. If the legislature funded this and an auditor came back three years later to compare your projection with the outcome, which line would you least want them to start with? That line is where your case needs work.

Then run the reverse exercise on someone else's document. Take a funded business case from your own agency, ideally one written before you arrived, and try to rebuild its headline number from the inputs printed inside it. Note every figure you cannot reconstruct and every assumption that is implied rather than stated. Whatever you find there is what a reviewer will find in yours, and the list is usually shorter and more mechanical than people expect: an omitted cost line, an annualized partial year, a percentage with no denominator.

Glossary

• Return on investment (ROI). A measure of financial benefit relative to investment, typically benefits less costs, divided by costs. For government AI, benefits include fiscal, operational and equity outcomes, not all of which convert to currency.
• Business case. A structured argument for why an investment makes sense, covering problem definition, solution design, benefits, costs, timeline, risks and comparison to alternatives.
• Cost-benefit analysis. A systematic method for evaluating an investment by comparing costs to benefits, including both quantified and qualitative factors.
• Baseline metrics. The quantified current state against which improvement is measured. Without them you cannot demonstrate that a deployed system delivered what was projected.
• Cost avoidance. Spending that did not occur because of the investment. It requires a documented counterfactual, because by definition it appears on no ledger.
• Fully loaded rate. The cost of an hour of staff time including salary, benefits and overhead. State the multiplier you applied whenever you convert hours into money.
• Risk mitigation. Strategies for reducing the likelihood or impact of an identified risk. Every credible case names its risks and describes how each is handled.
• Intangible benefits. Benefits that are real but resist precise measurement, such as public trust, employee satisfaction or reduced bias. Include them, but keep them separate from measured figures.
• Sensitivity analysis. Restating the projection under alternative assumptions to show which variable the conclusion depends on most.
• Counterfactual. The documented account of what would have happened without the investment. It is the evidence that turns a cost-avoidance claim from an assertion into a finding.
• Equivalency benchmarking. Valuing a hard-to-price benefit by comparing it against a metric your agency already uses and already funds, such as cost per case served.
• Proxy metric. A measurable stand-in for an outcome you cannot observe directly. Usable in a business case only when its limitations are stated alongside it.
• Break-even timeline. The point at which cumulative benefits equal cumulative costs. It cannot be stated at all unless the full cost of ownership appears somewhere in the document.

Related Lessons

This lesson sits inside the strategy sequence. Developing an Organizational AI Strategy establishes the mission alignment your case has to trace back to, and AI Maturity Assessment tells you whether the capability exists to deliver what you are about to promise. Prioritization Frameworks for Government AI is how you decide which case to write first when several projects compete for the same appropriation, and AI Roadmap Development turns the funded case into a sequence. For the tier below, Building an AI Use Case: From Idea to Business Case covers the earlier work of shaping the idea, and Measuring AI Impact covers the measurement you committed to when you published your projections.

Closing

Start by quantifying the problem and getting those numbers right. Project benefits conservatively. Build costs comprehensively, including the governance and change-management lines nobody enjoys requesting. Identify the risks and say what you would do about each. When you present, you will be credible because you did the work honestly rather than because you found a large number.

Funding committees hear many overoptimistic projections and have learned to discount them. An honest, conservative, data-grounded case stands out for exactly that reason, and it survives the scrutiny that comes years later when someone checks whether you delivered. Aminata's 72 hours were not enough to build the agency-wide number the budget office wanted, and she did not pretend otherwise. What she brought instead was a documented pilot, a stated method, and a clear account of what remained uncertain. That is what a fundable case looks like in government.

Key Takeaways

• Frame AI as infrastructure, not software. Legislative audiences fund systems that serve residents for decades, and that frame unlocks a different conversation than a technology upgrade.
• Use all five benefit categories. Fiscal, operational, equity, compliance and intangible benefits give a complete picture, and the four ROI models sit inside that frame rather than replacing it.
• Make the counterfactual visible. Cost avoidance only lands if you document what the agency would otherwise have spent. Build the baseline table before you claim the saving.
• Every total must be reproducible from the inputs on the page. If a reader cannot rebuild your headline figure, it is an assertion, and an auditor will treat it as one.
• Count change management and governance as real costs. They are routinely omitted, they are often larger than development, and omitting them produces a system you can build but cannot run.
• Know your budget cycle deadlines cold. A project missing the September request waits for the following biennium. Start pilots on existing authority so you arrive at the next cycle with data.
• Confirm federal match authority before you assume it. Administrative match under programs such as Medicaid and SNAP can substantially reduce the general fund contribution, but the rate and eligibility are determined by the federal program office, not by your projection.
• State assumptions and uncertainty ranges. Honest projections with sensitivity analysis build more credibility with analysts and auditors than optimistic point estimates.
• Treat equity analysis as risk management. Differential error rates are a litigation risk, a federal compliance risk and a political risk, not only a fairness question. Find them early and mitigate them in the design.
• Pair the constituent story with the data. Numbers without faces do not move decision-makers; faces without numbers do not survive scrutiny.

Frequently Asked Questions

Our benefits are mostly non-financial. Can we still build a business case?

Yes, and most government cases are in that position. Quantify what you can, use equivalency benchmarking against a metric your agency already values, and use clearly labelled proxy metrics for the rest. The requirement is not that every benefit converts to dollars. It is that measured figures and estimated ones are never blended into a single total.

How conservative is too conservative?

The failure mode of conservatism is a case that no longer justifies the investment, which is a fair outcome if that is what the evidence supports. The failure mode of optimism is a discredited program. Given the asymmetry, err toward the projection you would be comfortable defending against actual results in three years.

What if I cannot get a reliable cost figure from the vendor?

Then you cannot publish a payback period, and you should say so rather than estimating one. State the cost components you do have, mark the unknown explicitly, and treat closing that gap as a procurement task. A break-even claim resting on a cost that appears nowhere in the document is the single easiest thing for a reviewer to dismantle.

Should I include benefits that accrue to residents rather than to the agency?

Include them, cite the source of any external estimate, and keep them in a separate section from agency savings. Citizen value drives legislative support and it is often the honest reason for the project, but booking it as agency savings misstates the fiscal picture and undermines the parts of your case that are solid.

The pilot cost came from a different funding source than the deployment will. Does that matter?

It matters a great deal, and it should be stated rather than smoothed over. A pilot funded from discretionary authority or federal administrative match tells you almost nothing about whether the general fund will carry the deployment. Show the funding source for each phase separately, and show the scaling cost in the year it would actually be requested.

How much detail about the technology belongs in the document?

Enough to say what the system does, what it does not do, how it integrates with legacy systems, and how the data is governed. Beyond that, technical depth competes with the financial argument for the reviewer's attention and usually loses. The section that decides funding is the one describing the problem and the baseline, not the one describing the model.

How do I handle a projection that turned out wrong?

Report it against the original projection, explain what assumption failed, and say what you changed. You committed to measurement when you published the forecast. Agencies that report misses on their own terms retain far more credibility than agencies discovered missing them by an auditor, and the difference shows up in the next appropriation.