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 three worked project business case examples, each filled in the way a real one crosses a funding committee. 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 July 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 |
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 |
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.
How to build the cost-benefit table behind any example
All 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 three 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.