Ngozi Okonkwo had the idea in a staff meeting on a Tuesday in October. Her team at the Cook County Department of Revenue processed roughly 14,000 property tax exemption applications per year, and every October they hit the same wall: two clerks manually matching applicant names and parcel numbers against three separate legacy databases, producing a backlog that stretched to February. "What if we used AI for the matching?" she asked. Her supervisor nodded. "Write it up." That was the last clear guidance Ngozi received. She had never written an AI business case and was not sure what one looked like.

She spent the next six weeks writing a document that her division chief eventually returned with a single comment: "This doesn't tell me what we're buying, what it costs, or why it's worth it." She rewrote it. This lesson is the process she used the second time, and the reason the second version got funded when the first one did not.

The problem with AI enthusiasm

Most government AI ideas start the same way Ngozi's did: someone notices a painful manual process and wonders whether AI could help. That instinct is usually sound. The problem is what happens next. Without a structured development process, the idea either dies from vagueness or gets funded on enthusiasm and fails because the real constraints were never examined. The enthusiasm was never the problem. The absence of a method for testing it was.

Not every AI application is valuable, and this is worth saying plainly before you spend six weeks on a document. Some promise efficiency but deliver minimal savings once the exceptions are counted. Some require investment far exceeding the benefit. Some address symptoms rather than root problems, which means they work perfectly and change nothing. A systematic use case development process is what separates those from the ones worth funding, before the money is committed rather than after.

A business case is not a technology proposal. It is an argument that a specific problem is worth solving, that a specific solution is the best available approach, and that the investment is justified by the expected return. In government that argument has to satisfy multiple audiences: the division chief who controls the budget, the procurement office that has to structure the purchase, the IT security team that has to approve the data handling, and often the legislative oversight committee that will eventually ask whether the money was well spent. A document that satisfies all four is a different document from one that satisfies one.

Done properly, the process does four things at once. It forces clear thinking about the problem, the solution and the expected benefits. It directs scarce resources toward high-value initiatives rather than fashionable ones. It builds stakeholder alignment while the plan is still changeable. And it supports budget justification later, when someone asks what the agency got for the money.

Where good use cases come from

Many government organizations want to adopt AI and get stuck on "what should we do?" There are hundreds of potential applications and no obvious way to rank them, so agencies either default to whatever a vendor demonstrated most recently or wait for someone like Ngozi to notice a specific pain. Neither is a strategy. What agencies need is a repeatable way to identify high-value candidates, evaluate feasibility, build the case and secure funding, in that order.

Candidates cluster in recognizable places. When you go looking for opportunities in your own operation, these are the patterns worth scanning for.

• High-volume, repetitive processes. Tasks done thousands of times a year are good AI candidates because the saving multiplies and the pattern is learnable.
• Costly manual processes. Anywhere staff spend significant time on work that produces no judgment of its own.
• Error-prone processes. Where mistakes happen regularly and the mistakes have consequences for people outside the agency.
• Time-sensitive processes. Where a faster response would provide real value rather than just a better internal metric.
• Data-intensive processes. Where pattern recognition across a lot of records could add something a person scanning manually cannot.
• Inconsistent processes. Where judgment varies between staff and greater consistency would be an improvement in itself.

Ngozi's process hit several of these at once, which is why her instinct was right even though her first document was not. High volume, heavy manual cost, a seasonal deadline, and pattern matching across records were all present in the same workflow. When a candidate only hits one of the patterns weakly, that is a signal to keep looking rather than a reason to start writing.

Start with the problem, not the solution

The single most common mistake in government AI proposals is starting with the solution. "We want to implement an AI document-matching system" is not a problem statement. It is a technology preference. The problem statement comes first, and it has to be specific enough that a skeptic cannot reframe it as something else. Five elements make it that specific, and Ngozi's second draft answered all five before it named a technology.

• Current state. What is the process today, in measurable terms? "Two FTEs spend an average of 6.2 hours per day on manual database matching during the October to February filing period."
• Pain points. What fails or costs too much? "The backlog reaches approximately 4,800 applications by December, delaying exemption processing by an average of 47 days beyond the statutory 30-day target."
• Impact. Who bears the cost, inside the agency and outside it? "Delayed exemptions mean roughly 4,800 households pay the full tax bill before corrections post, creating payment plan requests and interest disputes that cost the agency an estimated $180,000 per year in staff time."
• Root cause. Why does this problem exist at all? "The three legacy databases do not share a common identifier. Manual matching is required because no automated cross-reference exists."
• Scope. How big is the problem, in cases and in cost? This is the element most often skipped, and it is the one a budget office reads first, because it decides whether the problem is worth a procurement at all.

A statement built this way is what lets you evaluate whether AI is actually the right solution, or whether the real fix is a database integration project that has nothing to do with AI. Note how much of it is arithmetic rather than opinion. Every one of those sentences can be checked by someone who disagrees with you, which is precisely what makes them persuasive to someone who does.

Does this problem actually need AI?

Before building the AI business case, answer this honestly: is AI the best solution, or just the fashionable one? Government IT is littered with AI projects that solved problems a well-designed database or a process redesign could have fixed at 10% of the cost. An AI system that matches names across three inconsistent legacy databases is genuinely useful. But if the root cause is that the three databases use different address formats, the better solution might be a one-time data normalization project, after which a simple lookup table handles matching with no AI required.

AI is worth pursuing when the problem involves pattern recognition at scale, inconsistent judgment that needs standardization, or language understanding that rule-based systems cannot handle. It is probably not the right tool when the problem is bad data, missing integrations, or processes that simply need to be redesigned. This is the same test as the root-cause element in the problem statement, applied one step later and with money on the table.

The business case should therefore include an explicit alternatives-considered section showing that you evaluated at least two non-AI options. Reviewers read this section as a proxy for whether you thought or advocated. A proposal that names two credible alternatives and explains why each was rejected reads as analysis. A proposal that names none reads as a preference in search of a justification, and experienced budget staff have seen enough of those to recognize one quickly.

Building the business case

Ngozi's revised business case ran eight pages and worked through the components below. That structure transfers to almost any government AI proposal, and the order matters as much as the content, because each section is answering the objection the previous one raises.

Problem statement

As above: specific, measurable, rooted in current-state data rather than complaints, and covering scope as well as pain. Everything downstream is scored against this section, so a vague one caps how good the rest can be.

Proposed solution

One or two paragraphs describing what the AI system would do, at a level of specificity a non-technical reader can evaluate. "An AI-assisted matching tool would ingest applicant records from all three databases nightly, use probabilistic matching to identify likely duplicates and cross-references with a confidence score, and flag low-confidence matches for human review before processing." That is specific enough to scope a procurement. "We will use AI to improve our process" is not, and it will come back with the same comment Ngozi's first draft did.

Implementation approach

How the solution would actually be put in place: what gets built or bought, what data has to be prepared, what integrates with what, and who does the work. This is the section that turns a solution description into something a procurement office can act on, and it is where unrealistic proposals usually reveal themselves, because the work that was invisible in the solution paragraph has to be named here.

Expected benefits, quantified

This is where most proposals are weakest. "Improved efficiency" is not a benefit. The benefit is: "Reduce manual matching time from 6.2 staff-hours per day to an estimated 1.5 hours per day during the five-month October to February filing period, freeing that time for higher-value work, and reducing the average processing delay from 47 days to an estimated 18 days." When you state a total of freed hours, compute it from the daily saving times the working days in the period and show that multiplication in the document. A total that does not follow from your own inputs is the fastest way to lose a reviewer's confidence in every other number you wrote.

Attach the assumptions to each figure. If you are estimating a seventy percent reduction in manual review time, explain why: what comparable systems have achieved in other jurisdictions, or what a vendor's reference implementation demonstrated. Be conservative in the projections and say where a pilot would validate them, because a projection that turns out optimistic damages the next proposal you write as well as this one.

Qualitative benefits matter too, but they come after the quantified case. Improved citizen satisfaction and reduced payment disputes are real. They are simply not sufficient on their own to justify an investment, and putting them first signals that the quantified case is thin.

Cost estimate

Government AI costs have three categories: one-time implementation covering software license or development, data preparation, integration and staff training; ongoing operations covering maintenance, vendor fees, monitoring and periodic retraining; and a risk reserve, typically 15 to 20 percent of implementation cost, for scope changes and delays. The ongoing category is the one that gets underestimated, and underestimating it is how a system that was affordable to buy becomes unaffordable to keep.

Ngozi's estimate for a commercial off-the-shelf matching tool was $85,000 implementation and $22,000 per year in ongoing costs. Over a five-year period that is $195,000 total, set against the $180,000 per year in identified costs from her problem statement, which gives a payback period of 13 months. Two definitions do most of the work in this section: payback period is how long until cumulative benefits equal the investment, and return on investment is net benefit divided by investment. Both are only as trustworthy as the benefit figure underneath them, so show that figure and how you got it.

Risk and mitigation

Government AI proposals that do not address risk get sent back. Address at least four. Accuracy risk: what happens when the AI matches incorrectly, and who catches it. Fairness risk: are certain property types or neighborhoods systematically more likely to be mismatched. Data security risk: what data enters the system and under what data-handling agreements. Procurement risk: what happens if the vendor is acquired or the product is discontinued.

For each risk state the mitigation, and state it as a mechanism rather than an intention. Not "we will be careful" but "all low-confidence matches below 85% confidence will require human review before processing." Hold that threshold, and be clear about what it does and does not buy you. It routes the uncertain cases to a person, which is the right design. It does not certify the matches above the line as correct, because a confidence score is the system's own estimate of itself rather than a measurement of accuracy, and a wrong match made confidently is exactly the one no human will look at.

Governance

Every AI business case in government should name a system owner: the person responsible for monitoring performance, responding to errors and reporting outcomes to leadership. This is not a technical role, it is an accountability role. "The Deputy Director for Taxpayer Services will serve as system owner, with quarterly performance reports to the Commissioner." That single sentence does more to build executive confidence than three pages of technical architecture, because it answers the question every executive is actually asking, which is who they will be talking to when something goes wrong.

Implementation timeline

A realistic government AI timeline from approved business case to live system is 12 to 18 months, with procurement typically consuming the first 6 to 9 months. Proposals that promise a three-month deployment get flagged as unrealistic by procurement offices that have seen too many projects slip. Show the procurement phase explicitly. Show integration and testing. Show the parallel-run period, when the AI and the manual process run side by side so accuracy can be validated before cutting over, and say when benefits actually begin, which is after go-live rather than at approval.

A second worked example

Ngozi's case is a matching problem. Here is a different shape, from a benefits program, to show that the structure holds. The problem: benefits applications take 45 days to process, citizens wait for determinations, and staff spend their time on repetitive data entry and document review. The proposed solution: an AI system to extract application data, perform initial eligibility screening, and flag documents for human review.

The business case put expected benefits at reducing processing time to 15 days, reducing staff time by 30%, and improving citizen satisfaction. Costs were estimated at $200K development and $50K annual maintenance, with a 12-month development timeline and benefits beginning after go-live. The stated payback period was 18 months, on the basis that staff efficiency savings exceed costs by then. Risks named were accuracy concerns, mitigated by human review, and implementation delays, mitigated by a phased approach.

Read that example the way a budget analyst would. The dollar value behind the 30% staff-time saving is what makes or breaks the 18-month payback claim, and it is not shown, so the payback figure is an assertion rather than a calculation. Your own version needs that line. And "mitigated by human review" is a promise about a control, not the control itself: it holds only if reviewers have the time, the training and the authority to reject the AI's screening, which is a staffing and workflow commitment the business case should cost out rather than assume.

The one-page summary

Every government business case needs a one-page executive summary that can be read in four minutes and contains enough for a senior leader to ask the right questions. Ngozi's one-pager had six elements: the problem in two sentences, the proposed solution in two sentences, the quantified benefits, the five-year cost, the 13-month payback period, and the one sentence about governance. The eight-page document supported every claim in that one-pager.

The one-pager got the meeting. The eight-pager answered the questions that came out of it. That division of labor is the whole point, and it is why writing the long document first and summarizing it afterward works better than the reverse. The business case is not a document you write to satisfy a requirement. It is a thinking tool that forces you to find out whether your idea is actually good before you spend a year procuring it.

Building stakeholder buy-in

A technically strong business case that has not been socialized before formal submission will fail. Government budget processes are not purely analytical. The division chief who sees a proposal for the first time at a budget meeting and feels surprised will push back, not because the analysis is wrong but because the surprise signals that their input was not sought. The work of preventing that follows a short sequence: identify who would be affected, understand what they actually care about, engage them early enough that their input can change something, incorporate what they say, and then communicate the benefits in their terms rather than yours.

Ngozi's revised process shows what that looks like in practice. She drafted the problem statement and shared it with frontline staff to confirm it described their actual experience. She shared the alternatives-considered section with IT security early, before it hardened into a procurement document. She briefed the procurement office on the vendor landscape before the business case was finalized, because procurement officers know which contract vehicles are available and which vendor categories have faced bid protests.

Then she shared the draft executive summary with the division chief two weeks before formal submission and asked for questions. By the time the business case was submitted, everyone who might raise an objection had already raised it in a setting where it could be addressed without derailing the formal process. The analysis in the second version was better than the first. What actually changed the outcome was that nobody read it for the first time in the room where it was decided.

Anti-Patterns to Avoid

Four of these sink business cases before funding. The rest sink the project afterward.

• Solving the wrong problem. Building a business case for an AI solution to a problem that does not really exist, or that has a better non-AI solution. Avoid it by defining the problem first and evaluating alternatives seriously rather than as a formality. The alternatives-considered section is where this defect becomes visible to a reviewer, which is a good reason to write it honestly and an even better reason to write it early.
• Unrealistic benefits. Projecting improvements that will not materialize in practice, usually by assuming the exception cases behave like the common ones. Be conservative in projections and validate them with an actual pilot before the number reaches a budget document. An optimistic projection costs you credibility on every proposal you write afterward.
• Hidden costs. Underestimating what it takes to maintain and update the system once it is live. Include realistic maintenance, monitoring and retraining costs, and remember that the staff time to review flagged cases is a cost even though it never appears on a vendor invoice.
• Ignoring risks. Not acknowledging what could go wrong, or listing risks with no real mitigation. Comprehensive risk assessment and genuine contingency planning are the difference between a mature proposal and a wish list, and a risk section that names only risks you have already solved reads as evasion.
• Leading with the technology. Opening with the system you want rather than the problem you have. It reframes every subsequent question as a challenge to your judgment instead of a test of the analysis, and it invites the reviewer to propose a different technology rather than agree with your problem.
• Treating human review as the mitigation. "Flagged for human review" appears in nearly every government AI proposal and is only as strong as the review behind it. If reviewers are handed more cases than they have hours for, or are measured on throughput, review becomes a rubber stamp and the mitigation exists only on paper. Cost the review capacity and say who has authority to overrule the system.
• Reading a confidence score as an accuracy score. A high-confidence match is one the system rates highly, not one that has been verified. Setting a review threshold is sound design; treating everything above it as correct is how a systematic matching error runs for months without anyone looking at it. Sample above the line as well as below it.
• Submitting cold. A first-rate analysis that nobody has seen before the meeting will lose to a mediocre one that everybody has. Surprise reads as a process failure regardless of how good the numbers are.

Practice Prompts

Run these against a real process in your own agency, ideally one you personally find painful.

• Identify use cases. Brainstorm high-value AI use cases in your organization against the six opportunity patterns above, and identify three to five potential candidates rather than settling on the first one.
• Analyze the problem. Pick one candidate and develop a detailed problem statement covering current state, pain points, impact, root cause and scope. Use measurable terms wherever you can, and mark the places where you had to guess.
• Design the solution. Sketch an AI solution for that problem. What would the system actually do, step by step, and where would a human be in the loop? Write it at the level of specificity that could scope a procurement.
• Build a preliminary case. Estimate the benefits and the costs across all three cost categories, then calculate a rough payback period and return on investment. Show every multiplication so a reader can check it.
• Analyze stakeholders. Identify who would be affected by your proposed system, what each of them cares about, what they would object to, and how you would address it before submission rather than during it.

Reflection

Answer these honestly before you start writing anything.

• If a skeptic reframed my problem as a data quality problem instead of an AI problem, could I show they were wrong?
• Which of my benefit numbers would survive someone asking me to show the calculation?
• Who in my agency will be worse off if this system works, and have I talked to them?
• What is the ongoing annual cost of the thing I am proposing, and whose budget absorbs it once the project is no longer new?
• If the pilot showed materially less benefit than projected, would I still recommend proceeding, and would I say so?

Glossary

• Business case. An argument that a specific problem is worth solving, that a specific solution is the best available approach, and that the investment is justified by the expected return.
• Problem statement. A structured description of a problem covering current state, pain points, impact, root cause and scope, written in measurable terms.
• Alternatives considered. The section of a business case that documents the non-AI options evaluated and why each was rejected.
• Payback period. How long until cumulative benefits equal the investment made.
• Return on investment. Net benefit divided by investment.
• Risk reserve. An allowance added to an implementation estimate, typically 15 to 20 percent, to absorb scope changes and delays.
• System owner. The named individual accountable for monitoring an AI system's performance, responding to errors and reporting outcomes to leadership.
• Parallel run. A period during which a new system and the existing manual process operate simultaneously so accuracy can be validated before cutover.
• Confidence score. A system's own numeric estimate of how likely its output is to be right, used to route uncertain cases to human review. It is not a measurement of accuracy.

Related Lessons

The business case sits between finding an opportunity and running the project, and these lessons cover what is on either side of it.

• Workflow Analysis: Finding AI Opportunities is the disciplined version of the opportunity scan in this lesson, and it is where a candidate list comes from.
• Building the AI Business Case goes further into the financial argument and how budget offices compare competing proposals.
• AI Pilot Program Design covers the pilot that validates the benefit projections before they become commitments.
• AI Output Confidence Calibration explains why a confidence score is not an accuracy measurement, which is the assumption behind most review thresholds.
• Prompt Engineering Mastery: Structured Prompts and Prompt Engineering Mastery: Chain-of-Thought and Few-Shot cover the hands-on skills that turn an approved solution design into something that works.

Closing

The gap between "we should use AI for this" and a funded project is not a technology gap. It is the distance between an intuition and an argument that a stranger can check. Everything in this lesson exists to close that distance: the opportunity patterns tell you where to look, the five-element problem statement makes the problem legible, the alternatives section proves you considered not doing it, and the cost and risk sections make the commitment honest.

Ngozi's second draft succeeded for an unglamorous reason. It answered the three questions her division chief asked in his one-line rejection, in the order he asked them, with numbers he could verify and a name he could call. Write for that reader. If your document survives someone who wants to say no, it will comfortably survive someone who wants to say yes.

Key Takeaways

• Look for opportunities in known patterns. High-volume, costly, error-prone, time-sensitive, data-intensive and inconsistent processes are where valuable use cases live. A candidate that matches only one pattern weakly is a reason to keep looking.
• Not every AI application is valuable. Some deliver minimal savings, some cost more than they return, and some fix symptoms while the root problem continues. The process exists to find that out before the money is committed.
• Start with the problem, not the solution. Current state, pain points, impact, root cause and scope are the five elements. Without them the proposal cannot be evaluated by anyone who does not already agree with you.
• Ask whether AI is actually the right tool. An alternatives-considered section covering at least two non-AI options prevents the common failure of using AI where a data normalization project or a process redesign would work for less.
• Quantify benefits before listing qualitative ones. "Reducing manual matching from 6.2 to 1.5 staff-hours per day across a five-month filing period" is a benefit. "Improved efficiency" is not. Show the multiplication behind every total.
• Cost estimates need three categories. One-time implementation, ongoing operations, and a risk reserve of typically 15 to 20 percent. Five-year total cost against identified annual problem costs is what produces the payback period a budget office can compare.
• Risk and governance sections are not optional. Name the accuracy, fairness, data security and procurement risks, name a mechanism for each, and name a system owner. These two sections separate a mature proposal from a technology wish list.
• State mitigations as mechanisms, not intentions. A review threshold routes uncertain cases to people; it does not certify the confident ones. Human review only mitigates anything if reviewers have the time, training and authority to say no.
• The one-page summary is the proposal. Problem, solution, quantified benefits, five-year cost, payback period and governance, in one page that gets the meeting the long document then survives.
• Socialize before you submit. Brief frontline staff, IT security, procurement and the sponsoring executive first. Every objection raised informally is one you can address without derailing the budget process.

Frequently Asked Questions

How precise do the numbers have to be at the business case stage? Precise enough to be checkable, and honest about which ones are estimates. A figure you derived from a measurement and a figure you assumed should be visibly different in the document, with the assumption stated next to the number rather than in a footnote. Reviewers are far more tolerant of a wide range you can defend than a single confident figure you cannot, and the fastest way to lose them is a total that does not follow from the inputs printed just above it.

My agency has no comparable jurisdiction to benchmark against. What do I use? Use your own process. Time the current work for a representative period, count the exceptions, and build the projection from that baseline rather than from a vendor's marketing figure. If you must use a vendor's reference implementation, cite it as theirs and say what was different about their environment. Where you genuinely cannot support a projection, propose a pilot to produce the number instead of estimating it, which is a stronger position than a figure nobody can source.

Is a 12 to 18 month timeline really unavoidable? Procurement is the part you cannot compress much by yourself, which is why it typically consumes the first 6 to 9 months and why proposals promising three-month deployments get flagged. What you can compress is everything before the clock starts: having the problem statement, the alternatives analysis and the security conversation done in advance means procurement begins the week after approval rather than months later. Talking to your procurement office early about existing contract vehicles is usually the highest-leverage hour in the whole process.

What if the honest analysis says do not build it? Then you have done the expensive thinking cheaply, and that is a result worth writing up rather than burying. A short memo explaining why a plausible-sounding idea does not pay off protects the agency from someone proposing the same thing next year, and it builds far more credibility for your next proposal than a case you had to strain to make. Reviewers remember who brought them a proposal that turned out to be honest.

Who should actually write this, me or IT? The person who understands the problem should write the problem statement, the benefits and the scope, because those are operational facts rather than technical ones. IT and security should shape the solution description, the data handling and the cost of integration. Procurement should see the vendor landscape section before it is final. A business case written entirely by IT tends to be strong on architecture and weak on why anyone should care, which is the section that decides funding.