Most projects that fail were doomed at approval, not delivery. They were greenlit on a slide deck and a confident sponsor, with no honest look at what they would cost, what they would return, or what else the money could have funded. The business case is the antidote. It is the document that forces a real answer to one question before anyone spends a dollar: should we do this at all? Get it right and your portfolio funds work that pays back. Get it wrong, or skip it, and you fund whoever presents best.
Key takeaways
- A project business case is the formal document that justifies an investment before approval, covering the problem, the options, the costs and benefits, the risks, and a recommendation.
- Every solid case answers three things a decision maker cares about: what problem this solves, what it will cost and return, and why this option beats doing nothing or doing something cheaper.
- The business case comes first and asks "should we do this?" The project charter comes after approval and asks "how will we run it?"
- A good case is honest about the do-nothing option and about at least two real alternatives, not a one-sided pitch for a decision already made.
- Reuse the same template across every proposal so your portfolio compares projects on the same basis rather than on presentation quality.
What is a project business case?
A project business case is a formal document that justifies why an organization should invest in a proposed project, setting out the problem or opportunity, the options considered, the expected costs and benefits, the risks, and a recommendation. It is prepared during initiation, before approval, and its job is to give a decision maker enough honest analysis to fund the project, decline it, or send it back for rework.
The audience matters. A business case is written for the people who control the money: a steering committee, a portfolio board, a PMO, or an executive sponsor. They are not reading it to admire the idea. They are reading it to decide whether this project earns a share of a fixed budget over every other idea competing for the same funds. That framing should shape every section you write.
Business cases feed directly into project selection methods: the case supplies the numbers and the qualitative argument, and the selection method (a scoring model, a cost-benefit calculation, or a constrained optimization) turns those into a fund or decline decision. A weak case starves the selection process of the inputs it needs to judge fairly.
What goes in a business case? The template, section by section
There is no single legal format, but strong cases across PMOs share the same backbone. Use these sections as a reusable template. Keep each one tight; a decision maker should be able to read the whole thing in fifteen minutes and skim it in three.
| Section | What it answers | Keep it to |
|---|---|---|
| Executive summary | The problem, the recommended option, the cost, the return, and the ask, in one page. | 1 page |
| Problem or opportunity | What business need or gap this addresses, with evidence, not assertion. | Half a page |
| Options considered | Do nothing, plus at least two real alternatives, each with cost, benefit, and risk. | 1 to 2 pages |
| Costs | One-time and ongoing costs, including people, licenses, and run costs after go-live. | Half a page plus a table |
| Benefits | Tangible (cash, time saved) and intangible (risk reduced, compliance met), with owners. | Half a page plus a table |
| Financial analysis | Payback, net present value, or benefit-cost ratio for the recommended option. | Half a page |
| Risks and assumptions | The main things that could sink the return, and what you are assuming to be true. | Half a page |
| Recommendation and timeline | The option you recommend, why, and a high-level schedule and funding ask. | Half a page |
The executive summary is the section most decision makers actually read closely, so write it last and make it stand alone. It should carry the recommendation and the headline numbers on its own, because plenty of approvers will decide from that page and skim the rest.
The options section is where honesty lives
The single most common weakness in a business case is a fake options section: one real proposal dressed up with two obviously bad alternatives so the preferred choice wins by default. Reviewers see through it, and it destroys the credibility of the whole document. Always include the do-nothing (or do-minimum) baseline as a genuine option with its own costs and consequences, and give at least one credible alternative a fair hearing. A case that admits where the recommended option is weaker is far more persuasive than one that pretends it has none.
How do you write a business case for a project?
Writing a business case is less about prose and more about assembling honest evidence in an order a decision maker can follow. Work through it in this sequence.
1. Define the problem before the solution
Start with the business need in plain terms, backed by evidence: a cost that is growing, a risk that is unmanaged, a revenue opportunity with a number attached, or a compliance deadline. If you cannot state the problem without naming your preferred solution, you have not defined it yet. Decision makers fund problems worth solving, not solutions looking for a problem.
2. Lay out the real options
List the genuine ways to address the problem, always including doing nothing. For each option, estimate cost, benefit, effort, and risk at a level that lets them be compared, not at false precision. Two or three options is usually enough; more than four and the case becomes a menu no one can decide from.
3. Quantify costs and benefits honestly
Separate one-time costs from ongoing run costs, because a project that is cheap to build and expensive to operate is a trap. On the benefit side, split tangible benefits you can put a dollar on from intangible ones you cannot, and give every benefit an owner who will be accountable for realizing it. Benefits with no owner tend not to happen, which is why benefits realization management exists as a discipline in the first place.
4. Run the financial analysis
For the recommended option, calculate at least one financial measure: payback period, net present value, or benefit-cost ratio. Payback (how long until the benefits repay the cost) is the easiest to explain to a non-finance audience. Net present value adjusts for the fact that a dollar next year is worth less than a dollar today. Show your assumptions so a reviewer can pressure-test them.
| Measure | What it tells you | Best when |
|---|---|---|
| Payback period | How many months or years until benefits repay the investment. | You need a fast, intuitive read for a mixed audience. |
| Net present value (NPV) | The value of the project in today's dollars after discounting future cash flows. | Benefits and costs span several years. |
| Benefit-cost ratio (BCR) | Total benefits divided by total costs; above 1.0 means benefits exceed cost. | You are comparing several projects on one number. |
5. State the risks, then recommend
Name the handful of risks that could actually sink the return, not a generic risk register. Then make a clear recommendation: which option, why, what it costs, and what schedule it implies. A case that ends without a recommendation pushes the hardest decision back onto the reader and usually stalls.
Business case example
Here is a compressed example for an internal automation project, showing how the numbers hang together. A shared services team spends roughly 900 hours a year manually keying vendor documents, at a fully loaded cost near 45 dollars an hour, or about 40,500 dollars a year.
- Problem: Manual document handling costs 40,500 dollars a year and delays month-end close by three days.
- Recommended option: Buy and configure a document extraction tool. One-time cost 25,000 dollars; ongoing cost 8,000 dollars a year.
- Benefit: Cuts manual handling by 80 percent, saving about 32,400 dollars a year, and removes the close delay.
- Payback: Net first-year saving after run cost is about 24,400 dollars against a 25,000 dollar build, so payback lands just past twelve months.
- Recommendation: Fund the automation option; the do-nothing baseline keeps a recurring 40,500 dollar cost with no upside.
Notice what makes this credible: the numbers are traceable to an assumption a reviewer can challenge (hours, rate, reduction percentage), the run cost is not hidden, and the do-nothing option is stated as a real cost rather than ignored. That is the standard to hold every case to.
Business case vs project charter
A business case and a project charter are different documents that answer different questions at different moments. The business case comes first and asks "should we do this project?" It seeks permission and funding. The project charter comes after approval and asks "how will we run this project?" It grants authority to the project manager and sets scope, objectives, and stakeholders.
| Business case | Project charter | |
|---|---|---|
| Core question | Should we invest in this? | How will we execute the approved project? |
| Timing | Before approval, during initiation. | After the case is approved. |
| Audience | Funders: board, PMO, sponsor. | The delivery team and stakeholders. |
| Focus | Justification: problem, options, costs, benefits, ROI. | Authorization: scope, objectives, roles, high-level milestones. |
| Owner | Sponsor or business analyst. | Project manager, authorized by the sponsor. |
The two are linked: the charter builds on an approved business case, carrying its objectives and constraints into an execution mandate. If your organization runs a formal stage gate process, the business case is typically the artifact reviewed at the first gate, and the charter is produced once that gate is passed.
Common questions about project business cases
What is a business case in project management?
A business case in project management is the document that justifies a project before it is approved, setting out the business problem, the options considered, the expected costs and benefits, the risks, and a recommendation. It is prepared during initiation and read by the people who control funding, who use it to decide whether the project should proceed.
Who writes the business case?
The business case is usually written by the project sponsor or a business analyst on their behalf, often with input from finance for the numbers and from the PMO for the format. The sponsor owns it because they are the one asking for funding and will be accountable for the benefits. The PMO typically supplies the template and reviews the case for completeness before it goes to a board.
What is the difference between a business case and a business plan?
A business case justifies a single project or investment inside an existing organization, focused on whether that one initiative is worth funding. A business plan describes an entire business or venture, covering its market, model, operations, and financials over years. A business case is narrower, shorter, and aimed at a funding decision; a business plan is broader and aimed at running or launching a business.
When should a business case be written?
A business case should be written during project initiation, before the project is approved or funded, so decision makers can judge it against other proposals competing for the same budget. Writing it too late, after work has quietly started, turns it into a rubber stamp rather than a real decision. It should also be revisited if scope, cost, or expected benefits change materially during delivery.
How long should a business case be?
A business case should be as short as it can be while still making an honest, complete argument, which for most projects means five to fifteen pages plus a one-page executive summary. Large or high-risk investments justify more depth, but length is not a proxy for quality. A tight, evidence-backed case beats a padded one, and decision makers reward brevity.
Where the business case fits in your portfolio
A single strong business case funds one project. A consistent business case template funds the right projects, because it lets your portfolio compare every proposal on the same basis: same sections, same financial measures, same honesty about options. That consistency is what turns a pile of competing pitches into a portfolio you can actually govern.
Once cases are written to a common standard, they flow into the rest of the portfolio machinery. Selection decides which pass the funding gate, using formal selection methods. Then portfolio prioritization ranks and sequences the survivors against real capacity. Treat the business case as the front door to that whole system, not a form to fill in after the decision is already made.