What a business case is, and what it is not
A business case is the document that answers a single question for the senior approver reading it: should we commit capital to this proposal, or not? Every section of the document is in service of that question. Anything that does not move the reader closer to a yes or a no is decoration, and decoration is what gets cases rejected.
It is not a project plan. It is not a vendor pitch. It is not a strategy document. A project plan describes how the work will be done after approval. A business case explains why the work should be approved at all. Mixing the two is the most common structural mistake we see in cases that fail.
The format matters less than the logic. A five-page Word document, a twelve-slide deck, or a one-page memo can all be defensible business cases if they contain the same six elements. What is not defensible is a case missing any of them.
The six sections an approved business case shares
After reviewing how cases get approved in practice, six sections appear in essentially every successful business case. The order can vary; the presence cannot.
1. Executive summary (one page)
The executive summary states the recommendation first, the problem and the headline numbers second. It exists to let a senior approver act on the case without reading the rest of the document. Lead with the conclusion, not the journey.
A strong executive summary fits four things on one page: what is being proposed, what it costs, what it will return (NPV, IRR, payback), and what the recommendation is (approve, approve with conditions, defer, or reject). If you cannot fit those four things on one page, the case is not yet ready.
2. Problem or opportunity statement
The problem must be quantified in business terms, not technology or process terms. "Our CRM is outdated" is not a problem statement. "We are losing 8% of inbound leads because the sales team cannot reach them within the 5-minute response window, equating to roughly $1.2M in annual missed pipeline" is a problem statement. The first sentence is a complaint; the second is a business case foundation.
The discipline is to name the dollar value of the status quo. If you cannot name it, the case is harder to argue, because you have not yet shown there is a problem worth spending money to solve.
3. Options analysis with a do-nothing baseline
A credible business case names alternatives. The mandatory baseline is "do nothing", because the question approvers actually answer is not "is this proposal worth doing?" but "is this proposal better than not acting?". Without the baseline, the comparison is incomplete.
Three options is usually the right number: do nothing, the recommended proposal, and one credible alternative. The alternative does not have to be the runner-up you actually considered; it can be a deliberately weaker option that helps the reviewer see why the recommendation is preferable. The honest framing is "we considered these three; here is why option two wins."
4. Financial analysis
This is where most cases either earn or lose the approver's trust. Four metrics, at minimum, with sensitivity.
5. Risk assessment
Reviewers know every project carries risk. What they want to see is whether you have looked. Three to five risks, each with likelihood, impact, and the mitigation you intend to apply, is enough for most business cases. The mitigation matters more than the risk itself; an unmitigated risk on the page is an invitation to reject.
The convention that pays off in practice is to lead with the risk you find most uncomfortable. Reviewers notice the omissions; they trust the document that names them first.
6. Recommendation
State the recommendation in unhedged language. Approve, approve with conditions, defer, or reject. Reviewers cannot act on "the team feels positive but acknowledges uncertainty." They can act on "we recommend approval, conditional on completing the security review by 15 September." If the case ends with hedging, expect the conversation to keep going for another month.
The litmus test
If a senior approver who has never met you reads only the executive summary and the recommendation, can they make the call? If yes, the case is ready. If no, the work is not finished, even if the document is twenty pages long.
NPV, IRR, payback, and ROI: what each tells you
The four financial metrics that appear in every defensible business case each answer a different question. Treating them as redundant, or relying on only one, is a sign of an under-cooked case.
Net Present Value (NPV)
NPV is the dollar value the project creates above the cost of capital, expressed in today's money. A $5M investment that returns $2M annually for five years does not have a $5M NPV; discounted at 10%, the NPV is closer to $2.58M. NPV tells you how much value the project produces. A positive NPV means the project creates value above the cost of the capital it consumes.
The formula is NPV = Σ CF_t / (1+r)^t, where CF is the cash flow in year t and r is the discount rate. The discount rate reflects the time value of money and is usually set at the organisation's weighted average cost of capital, often between 8% and 12% for stable corporates.
Internal Rate of Return (IRR)
IRR is the discount rate at which NPV equals zero. It tells you the percentage return the project generates. Compare it against your hurdle rate, the minimum return your organisation requires for capital deployment (typically 10% to 15% in corporate settings). An IRR above the hurdle rate means the project clears the bar; below, and it destroys value relative to alternative uses of the capital.
IRR is intuitive for executives because it speaks the same language as a percentage return. But it is unreliable when cash flows change sign more than once (a project with multiple investment rounds, for example). When that happens, trust NPV and report IRR with a caveat.
Payback period
Payback is the time in years for the cumulative cash flow to turn positive. It answers the question "when do we get our money back?" It is a measure of liquidity risk, not value. Two projects can have identical NPVs but very different payback periods; the one with shorter payback is preferred when capital is constrained or when the operating environment is uncertain.
Return on investment (ROI)
ROI is the simplest of the four: total benefit divided by total cost. It is useful for comparing projects of similar duration but unreliable across different timeframes (a 50% ROI over one year is very different from 50% over ten). Include it because executives ask for it, but lead with NPV and IRR.
Sensitivity is the difference between a case and a wish
A single-point estimate for NPV is not a business case; it is a wish. The case that gets approved shows what happens to NPV when the key assumptions move. A sensitivity tornado or a probabilistic NPV from Monte Carlo simulation is no longer optional in serious capital allocation: it is what separates a case that survives questioning from one that collapses under it.
The four mistakes that kill most business cases
1. Benefits overstated
The most damaging mistake by a wide margin. Cases routinely project benefits 40-60% higher than what actually materialises, because authors anchor to the numbers needed to justify the investment rather than the numbers supported by evidence. The fix is to model the base case conservatively. If your vendor estimates a 12-week implementation, plan for 16. If market research suggests 30% adoption in year one, model 20%. Approvers remember the cases that under-promised and over-delivered, and they remember the opposite even more vividly.
2. No do-nothing baseline
If the case does not show what happens if you do not act, the reviewer cannot tell whether the proposal is worth its cost. The do-nothing option must be quantified, not just named. "We will continue current operations" is not the baseline; "we will continue to lose 8% of inbound leads at a value of $1.2M annually, with the gap widening as our competitor scales" is the baseline.
3. Single-point estimates without sensitivity
An NPV of $4.2M means almost nothing without a range. What happens if implementation slips by six months? If benefits ramp slower? If OpEx is 15% higher than estimated? Approvers know your assumptions are uncertain; they want to see that you know it too. A tornado chart showing which assumptions move NPV the most takes one page and rescues many cases that would otherwise fail.
4. Hedged recommendations
The case must end with a clear ask. "Approve", "Approve with conditions", "Defer", or "Reject". Cases that hedge ("we feel the proposal has merit but recognise the uncertainty") leave the decision-maker with no path forward. State the recommendation. Defend it with the analysis. Trust the reviewer to push back where they disagree.
How to write the case in 90 minutes
The sequence that works in practice is the opposite of the order the document appears in.
- Build the financial model first. Get the costs and benefits in a spreadsheet. Compute NPV, IRR, payback, ROI. Decide whether the case is even directionally positive before writing a word of narrative. Many cases die at this step, which is the right place to die.
- Run sensitivity. Identify the three assumptions that move NPV the most. If any of them are out of your control, surface that early.
- List the top three risks. The risks the financial model does not capture: implementation slip, vendor failure, regulatory change, organisational resistance. Assign likelihood and impact to each.
- Draft the recommendation in one sentence. "We recommend approving the CRM platform upgrade at a base NPV of $4.2M (10% discount), with a 14% IRR clearing our 12% hurdle, and a downside scenario that remains positive at $0.6M." That sentence is the spine of the case.
- Write the narrative around it. Executive summary, problem, options, financial analysis, risk, recommendation. The narrative is the easy part once the recommendation sentence exists.
Build it in fifteen minutes, not ninety.
The SocraticFlow Business Case Builder runs the financial model, the Monte Carlo sensitivity, and the risk math for you, then produces a six-section PDF that mirrors the structure above. Free to use; the audit-ready PDF is $39 at launch, $29 for founding members on the waitlist.
Try the Business Case Builder →