A business case example is more useful than a blank template, because the hard part is never the section headings. It is knowing how much honesty to put in the options section, how to size a benefit you cannot prove yet, and how to write a recommendation a busy board will actually back. Below are five worked project business case examples, each filled in the way a real one crosses a funding committee. They deliberately span the five shapes a case can take: growth, cost reduction, risk, mandatory compliance, and shared infrastructure. The numbers are illustrative and rounded to keep the logic clear, but the structure is exactly what you would submit.
Key takeaways
- A good business case example shows the do-nothing option costed honestly, not just the preferred solution dressed up to win.
- Every example here answers the three questions a funder cares about: what problem this solves, what it costs and returns, and why this option beats the cheaper ones.
- The financials do not need to be precise to be useful. A defensible range, clearly labeled as an estimate, beats a false single number.
- The recommendation is one paragraph, and it names the option, the cost, the payback, and what you are asking the committee to approve.
Last updated September 2026.
If you want the underlying structure first, the full section-by-section breakdown lives in our guide to the project business case, and the downloadable financial model that produces the numbers below is in the business case template. This page is about seeing them applied.
Example 1: Replacing a legacy order-management system
A mid-size distributor runs its orders through a 14-year-old system the vendor no longer supports. Outages are rising and the finance team rekeys data by hand. Here is how the case reads.
Problem or opportunity. The order system failed for six hours twice last quarter, and each outage stops shipping. Two staff spend roughly a day a week rekeying orders into the accounting system because the two do not talk. The vendor ends all support in eighteen months, after which a serious fault has no fix.
Options considered. Three, including doing nothing.
| Option | One-time cost | Annual cost | What it fixes |
|---|---|---|---|
| Do nothing | $0 | Rising outage and rekeying cost | Nothing. Risk grows as support ends. |
| Extend the old system | $40,000 | $25,000 | Buys time, fixes nothing structural |
| Replace with a supported platform | $180,000 | $36,000 | Removes the outage and rekeying entirely |
Swipe to see more →
Costs and benefits (illustrative). The replacement costs $180,000 to implement and $36,000 a year to run. Against that: two days a week of staff time recovered (worth about $45,000 a year), avoided outage losses estimated at $30,000 a year, and the removal of an unsupported-software risk that is hard to price but real. On those figures the investment pays back in a little under three years and turns cash-positive after that.
Recommendation. Approve the replacement at $180,000. The extend option is cheaper this year and more expensive every year after, and doing nothing converts a manageable project into an emergency the day support ends. This is the kind of trade the project selection method is meant to weigh, and the numbers hold up against the do-nothing baseline.
Example 2: Hiring a project manager
People cases are the ones most often waved through on gut feel, which is exactly why writing them down matters. A program lead wants to add a dedicated project manager to a portfolio currently run part-time by engineers.
Problem. Four projects worth a combined $2.1M are coordinated by senior engineers in the gaps between their real work. Two slipped a quarter last year, and the delay had nothing to do with the engineering and everything to do with nobody owning the schedule, the dependencies, or the stakeholder updates.
Options. Keep the status quo, hire a contractor for one project, or hire a permanent project manager across the portfolio.
Costs and benefits (illustrative). A permanent hire costs roughly $130,000 fully loaded. The benefit is not a neat line item, so the case argues it two ways: the engineers return an estimated 20 percent of their time to engineering (worth well over the salary at their billing rate), and a single avoided quarter of slippage on a $2.1M portfolio dwarfs the cost. The honest case admits the benefit is a reduction in a risk, not a guaranteed saving, and sizes it as a range.
Recommendation. Hire the permanent project manager. The full worked version of this one, including how to defend a soft benefit to a skeptical CFO, is in the dedicated business case for hiring a project manager.
Example 3: Automating accounts payable
The clearest cases are the ones where a person does a repetitive task a machine could do. An operations team processes about 1,800 supplier invoices a month by hand.
Problem. Two people spend most of their week opening invoices, keying them, matching them to purchase orders, and routing them for approval. Errors cause duplicate and late payments, and month-end close waits on the backlog.
Options. Do nothing, add a third clerk, or automate the capture and matching so people only handle exceptions.
| Option | Year 1 cost | Annual benefit | Payback |
|---|---|---|---|
| Do nothing | $0 | $0 | Backlog and error cost persist |
| Add a clerk | $55,000 | Clears backlog, no error reduction | Never pays back |
| Automate capture and matching | $48,000 | ~$70,000 in recovered time and avoided late fees | Under 1 year |
Swipe to see more →
Recommendation. Approve automation. The tooling for this has matured to the point where software that reads each invoice, matches it to the purchase order, and routes only the exceptions to a person is an off-the-shelf purchase rather than a build, which is what makes the sub-one-year payback credible. The case is strong because the benefit is a real headcount-hours saving, not a soft estimate.
Example 4: A regulatory compliance project with no return
Mandatory work is where most business cases go wrong, because the author reaches for an ROI that does not exist and the committee stops believing the rest of the document. A payments business has eighteen months to meet a new reporting obligation. The case has to justify the amount, not the decision.
Problem. A regulator has set a compliance date. Missing it exposes the business to penalties and, more importantly, to a licensing conversation nobody wants to have. The work itself is unglamorous: new data capture at the point of sale, a reporting pipeline, and an audit trail that survives inspection.
Options considered. The do-nothing option is not "carry on as we are". It is "accept the penalty and the regulatory relationship that follows", and it belongs in the table precisely because naming it stops the discussion drifting into whether the project is optional.
| Option | One-time cost | Compliance date met | What the business is accepting |
|---|---|---|---|
| Do nothing | $0 | No | Penalties, and a supervisory relationship that affects every future approval |
| Manual quarterly workaround | $70,000 | Yes, barely | Four people for two weeks every quarter, forever, and a control that fails when someone is on leave |
| Automated capture and reporting | $310,000 | Yes | A higher build cost and no revenue return, in exchange for a control that holds under inspection |
Swipe to see more →
Costs and benefits (illustrative). The automated route costs $310,000 to build and roughly $20,000 a year to run. There is no revenue benefit and the case does not pretend otherwise. What it quantifies instead is the difference between the two compliant options: the manual workaround consumes about 320 person-days a year in perpetuity and depends on individuals being available in a specific fortnight. Priced at a loaded day rate, the workaround overtakes the build cost inside three years and never stops.
Recommendation. Approve the automated build at $310,000. The case is not "this pays back". It is "we are required to do this, here are the two ways to comply, and the cheaper one this year is the more expensive one by year three and carries an operational risk we would be choosing on purpose".
That last sentence is the whole technique for mandatory work. You are not arguing about whether to spend. You are arguing about which compliant option to buy, and the comparison is between the options rather than against a return.
Example 5: An enabler project with no benefit of its own
The hardest case to write is the one for work that delivers nothing a business user can see. A retailer needs to replace an integration layer that three planned projects all depend on. On its own it changes no customer experience and saves no money.
Problem. Three approved projects in next year's plan all read and write through an integration layer built in 2014. Each has independently scoped around six weeks of work to bolt onto it, and each carries the same risk that the layer cannot take the additional load. Nobody owns the layer, so it has been patched by whoever needed it last.
Options. Do nothing and let each project work around it; have each project fund its own workaround; or replace the layer once as a shared enabler before the three projects start.
| Option | Cost | Where the cost lands | What happens to the three projects |
|---|---|---|---|
| Do nothing | Hidden | Absorbed into three separate project budgets | Each pays around six weeks of workaround and inherits the same unowned risk |
| Three separate workarounds | About $210,000 in total | Three budgets, three teams, three times | All three ship, and the layer is now harder to replace than it is today |
| Replace the layer once | $150,000 | One enabler budget with no business owner | All three start later, and start cheaper |
Swipe to see more →
Costs and benefits (illustrative). The replacement costs $150,000 and returns nothing measurable by itself. The benefit belongs to the three dependent projects, which is exactly what makes this case difficult: the funder is asked to spend against a benefit that will be counted somewhere else. The case handles that head on by showing the total cost of the portfolio with and without the enabler, rather than the cost of the enabler in isolation.
Recommendation. Fund the replacement as portfolio infrastructure ahead of the three dependent projects, and record explicitly that its benefit is already counted in those three cases and must not be counted again here. Work like this belongs in the keep-the-lights-on portion of the portfolio, which is why it is usually easier to defend once the portfolio is deliberately split into the work that sustains the business and the work that changes it. An enabler competing head to head against revenue projects on a single ranked list loses every time, and the portfolio slowly becomes unbuildable.
How the case changes shape by project type
The five examples above are not five versions of the same document. Each project type puts a different question in front of the funder, and using the wrong shape is the most common reason a sound project gets declined. A mandatory project argued as an investment invites the committee to evaluate a return that was never the point.
| Project type | What the funder is actually deciding | What the numbers can show | The trap |
|---|---|---|---|
| Revenue or growth | Whether this is the best use of the money available | Payback, and the size of the opportunity | A benefit forecast with no named owner who will be held to it |
| Cost reduction | Whether the saving is real and will actually be taken | A specific budget line that gets smaller, and when | Counting freed time as cash when no budget or headcount actually falls |
| Risk reduction | How much to spend to reduce an exposure | Cost of the response against a sized exposure and its likelihood | Presenting a probability-weighted figure as though it were a saving |
| Mandatory or regulatory | Which compliant option to buy, not whether to comply | The cost difference between compliant options over several years | Inventing an ROI, which undermines the parts of the case that are true |
| Enabler or infrastructure | Whether to pay once centrally or repeatedly inside other projects | Total portfolio cost with and without it | Claiming the dependent projects' benefits, so they get counted twice |
Swipe to see more →
Pick the row before you write a word. It determines which section carries the weight: for a growth case that is the benefit and its owner, for a mandatory case the options comparison, for an enabler the portfolio-level arithmetic. Sections that do not carry weight for your type should be short and honest rather than padded to look complete.
Costing the do-nothing option properly
Every example here includes a do-nothing option, and in four of the five it is the option most likely to be chosen by default. Costing it honestly is the single highest-value hour in writing a business case, because a committee comparing a real number against a blank space will pick the blank space.
The mistake is writing $0. Doing nothing is almost never free, it is simply unbudgeted, and the cost shows up in someone else's numbers. The legacy system case above is a good illustration: the do-nothing column reads $0 one-time, but the rekeying continues at roughly $45,000 a year and the outage exposure grows the moment vendor support ends.
| Where the cost of doing nothing hides | How to surface it | Evidence a funder will accept |
|---|---|---|
| Manual effort that continues | Count hours a week, multiply by a loaded rate, extend over the same years as the investment | A named team's own estimate of hours, confirmed by their manager |
| Risk that grows over time | Show the exposure at year one and at year three, not as a single figure | A dated external fact, such as the end of vendor support or a regulatory deadline |
| Cost absorbed by other projects | Add up what each dependent project has scoped to work around the problem | The workaround line items already in those projects' own estimates |
| Revenue that does not arrive | State it as delay, not as loss, and say how long | An existing forecast, with the delay applied to it |
| Attrition and rework | Leave it out of the total and describe it in a sentence | None that holds up. Claiming it weakens the numbers that do. |
Swipe to see more →
That last row matters as much as the four above it. Part of costing the do-nothing option well is knowing which costs to describe rather than count. A case that quantifies everything, including the unquantifiable, reads as advocacy. A case that counts four things carefully and names a fifth without pricing it reads as analysis, and analysis is what gets funded. Where the cost of waiting is the core of the argument rather than a footnote, it is worth sizing it properly using what each month of delay actually costs.
What separates a weak example from a strong one
The difference is rarely the writing. Weak and strong cases usually contain the same sections and a similar amount of detail. What separates them is whether each number can be traced to somebody who will stand behind it, and whether the document admits what it does not know.
| Element | Weak version | Strong version |
|---|---|---|
| The benefit | "Improved efficiency across the team" | "Two staff currently spend a day a week rekeying. Finance has agreed the saving reduces the contractor line, not headcount." |
| The options | The preferred option, plus two obviously worse ones | Three genuine options including do nothing, one of which the author can see a committee choosing |
| The estimate | A single precise-looking number | A range with the assumption that drives it, and what would move it to the top of the range |
| The risk section | Generic risks that apply to any project | The two things most likely to make this specific case wrong, and what happens then |
| The ask | "Approval to proceed" | The amount, the decision required, the date it is needed, and who is accountable afterward |
Swipe to see more →
The strong column has a common thread: every entry names a person or a specific line. That is what a funding committee is testing when it asks questions. Not whether the arithmetic is right, but whether anyone will still own these numbers in a year, when the project is halfway done and the assumptions have moved.
How to build the cost-benefit table behind any example
The first three cases turn on the same small model: list one-time and ongoing costs, list the benefits as annual figures, and let the years compound. A benefit that only appears in year three still counts, and a cost that recurs forever should scare you more than a one-time number that looks larger. When the benefit is a saved-hours figure, show the hourly rate and the hours so a reviewer can argue with the assumption rather than the conclusion. The business case template ships a model that calculates net present value, ROI, payback, and IRR from exactly these inputs, so you are filling in cost and benefit lines rather than writing formulas.
Frequently asked questions
What is an example of a business case in project management?
A common example is the case to replace an unsupported legacy system: it states the problem (rising outages and manual rekeying), lays out three options including doing nothing, costs each one over several years, and recommends the replacement because it pays back in under three years and removes a risk that grows once vendor support ends. The five worked examples above show this structure applied to an IT replacement, a hire, and a process automation.
How do you write a business case with an example to follow?
Write five things in order: the problem with evidence, the options including do-nothing, the costs and benefits over several years, the risks, and a one-paragraph recommendation. Using a filled-in example as a guide keeps each section honest, because you can see how much detail a real decision maker needs and where a vague benefit would get challenged. Keep the whole document to something a committee can read in fifteen minutes.
What are the main elements of a business case?
The core elements are the executive summary, the problem or opportunity, the options considered, the costs and benefits, the risks and assumptions, and the recommendation. Larger organizations add a timeline and a set of success measures. The single element people most often skip, and the one a good board asks for first, is an honest costing of the do-nothing option.
What is a simple business case example?
The accounts payable automation case above is the simplest kind: a person spends measurable hours on a repetitive task, software does most of it, and the recovered hours pay for the tool inside a year. Simple cases share that shape, where the benefit is a concrete saving rather than a soft estimate, which is why they clear a committee quickly.
How long should a business case be?
Long enough to make the decision and no longer, which for most projects is three to eight pages plus a one-page executive summary. A committee should be able to skim the summary in three minutes and read the full case in fifteen. Length signals nothing about quality; a tight five-page case with an honest options table beats a forty-page document that argues one predetermined answer.
Where these examples fit
An example is a starting point, not a shortcut. Change the numbers, keep the discipline: cost the do-nothing option, put at least two real alternatives on the page, and end with a recommendation the committee can vote on without a second meeting. When several of these cases arrive at once and compete for the same budget, the way you compare them fairly is covered in project selection methods, and the argument each one has to make is set out in the full guide to the project business case.