What Is a Business Case?
A business case is a document that justifies why an organization should invest time, money, or resources into a specific project or initiative. It sets out the problem or opportunity, the proposed solution, expected costs and benefits, alternatives considered including doing nothing, and the key risks. Decision makers use it to compare competing investment options and to decide whether a project is worth pursuing before significant resources are committed.
A business case is a structured document that justifies a proposed investment or project by weighing its expected costs, benefits, and risks against the alternative of doing nothing.
Not every idea worth pursuing gets funded, and not every business case that looks compelling actually is. The document exists precisely to separate the two before a project consumes budget and team time that could have gone elsewhere.
What a business case typically contains
A solid business case describes the problem or opportunity in concrete terms, proposes a specific solution, and lays out the expected costs and benefits of pursuing it. It compares this option against realistic alternatives, including the often-skipped option of doing nothing at all, and states the main risks along with how they would be managed. It closes with a clear recommendation: proceed, delay, or reject.
Why ‘do nothing’ has to be on the table
Every proposal looks reasonable when it is presented alone, since the person writing it has already decided they want it approved. The comparison that actually matters is whether the proposed investment delivers more value than the alternative of not doing it, given its cost, its risk, and what else that budget and time could accomplish instead. Leaving the do-nothing option out of a business case is one of the most common ways a weak proposal gets approved on enthusiasm rather than substance.
Costs and benefits need to be comparable
A business case is only useful if costs and benefits are expressed in terms that can actually be weighed against each other. That usually means translating benefits into financial or time terms wherever realistically possible: hours saved per week, reduced error rate, avoided compliance risk, or projected revenue. Vague benefits like ‘improved efficiency’ without a number attached make a business case much harder to evaluate honestly, and easier to approve or reject based on gut feeling rather than substance.
Matching detail to the size of the decision
A business case for a significant capital investment, a new system, a large hire, an acquisition, warrants detailed financial modeling: return on investment, payback period, sensitivity to different assumptions. A business case for a smaller internal initiative, automating a manual weekly report, for example, can be a page or two with a reasonable cost estimate and a clear statement of expected time savings. Applying heavyweight financial modeling to a small decision wastes time; applying a one-paragraph justification to a major investment under-informs the decision maker.
Where it fits in a project’s lifecycle
The business case comes before detailed planning, not after. Once it is approved, the actual project plan, timeline, resourcing, milestones, gets built on the assumption that the investment is justified. Building a detailed project plan before the business case is approved risks significant wasted effort if the decision maker ultimately says no, or asks for a materially different scope.
Our tip: Write the ‘do nothing’ scenario first, before drafting the proposed solution. It forces you to state clearly what the actual cost of inaction is, which usually sharpens the rest of the business case and makes the real justification for acting much easier to defend.
Frequently asked questions
What is the difference between a business case and a project plan?
A business case answers whether a project should happen at all, by weighing its costs and benefits against alternatives. A project plan assumes the decision to proceed has already been made and describes how the work will be executed: timeline, tasks, resources, and milestones. The business case comes first and is a prerequisite for justifying that a project plan is even worth building. Confusing the two often leads teams to plan a project in detail before confirming it is actually worth doing.
Does a business case always need detailed financial figures?
Not always with the same precision. For a large capital investment, a bank loan, or a board decision, detailed figures like projected ROI, payback period, and net present value are usually expected. For a smaller internal initiative, a lighter version with a reasonable cost estimate and a clear description of expected benefits, in time saved or risk reduced, is often sufficient. The right level of detail should match the size of the decision, not follow one fixed template regardless of scale.
Who is a business case written for?
It is written for whoever needs to approve the investment: a manager, a board, an investment committee, or in a smaller company, the business owner. Because that audience is usually deciding between multiple competing proposals with limited budget, the business case needs to be readable by someone without deep technical knowledge of the project, focused on business impact rather than implementation detail.
What happens if the 'do nothing' option is left out?
Leaving it out is one of the most common weaknesses in a business case, because it removes the actual baseline the decision maker needs for comparison. Every proposal sounds reasonable in isolation; the real question is whether it delivers more value than simply continuing without it, given its cost, risk, and the opportunity cost of the resources it consumes. Including the do-nothing scenario, even briefly, forces a more honest justification.