A business case answers whether an initiative deserves the money, time and attention it will consume — and whether it still deserves them once work is under way. In structured project management it is not filed at kick-off and forgotten: it is the instrument a board uses to keep funding a decision rather than a habit.
Quick Overview
What you’ll learn:
- What decision a business case actually carries, and what it is not for
- Why continued justification is a principle rather than a document review
- Which components make the case usable by people who approve spending
- Who is accountable for the case and who does the drafting
- Where the case is reviewed, and what an exception forces
- How stopping a project on purpose protects the rest of the portfolio
Who this article is for:
- Sponsors and board members who approve and defend project investment
- Project managers who draft and maintain the justification behind their work
- Business analysts who supply the options, costs and benefit measures
Reading time: 8 minutes
What a Business Case Actually Decides
The case exists to answer a single question in a form somebody can act on: should this organisation commit resources to this change, given what it expects to get back and what it might lose. Everything else in the document is evidence for that answer.
That framing matters because it excludes work the case is often asked to do. A feasibility study asks whether the change can be built at all; the case asks whether it should be paid for. A requirements document describes what will be delivered; the case describes why the delivery is worth funding. When those questions get merged into a single document, the investment decision quietly disappears into technical detail — and the board approves a plan it never actually appraised.
A case that cannot be used to say no is not a case. If every version of the document concludes that the project should proceed, the instrument has become a formality and the organisation has stopped choosing between initiatives.
Continued Justification Is a Principle, Not a Review Cycle
Structured methods treat justification as a standing condition rather than an entry ticket. The method behind the certifications listed at the end of this article organises itself around a small set of principles, and this is the first of them:
- Continued business justification — the reason to run the project must hold for as long as the project runs
- Learn from experience — lessons are sought, recorded and acted on
- Defined roles and responsibilities — everyone knows who decides what
- Manage by stages — work is planned, authorised and reviewed stage by stage
- Manage by exception — tolerances are delegated, escalation is triggered by breach
- Focus on products — the definition of done is the product, not the effort
- Tailor to suit the project — the method is scaled to the risk and the environment
Read together, those principles explain why the case is a live artefact. Stage-based control only means something if there is a criterion for authorising the next stage, and that criterion is the case. Delegated tolerance only means something if a breach can be judged against expected value. A guide to when the method is worth applying at all sits in when and how to apply this project management methodology.
What Belongs Inside the Document
A case is usable when a decision-maker can read it and see both sides of the trade. The components below are the working set:
| Component | What the decision-maker gets from it |
|---|---|
| Reasons | The problem being solved or the opportunity being taken |
| Business options | The realistic ways of getting there — including doing nothing |
| Expected benefits | Outcomes stated so that someone can later confirm or deny them |
| Expected disbenefits | Consequences the organisation accepts as part of the deal |
| Timescale | When the work runs, and when benefits start to appear |
| Costs | Delivery cost plus the cost of running what gets delivered |
| Investment appraisal | Benefits against costs and time, in a form finance recognises |
| Major risks | The threats and opportunities that could move the answer |
Two of those are routinely thin. Disbenefits get dropped because they read as an argument against the project — yet a case that admits a temporary drop in throughput during rollout is more credible, not less. And the cost of ownership after handover is often missing entirely, which is how organisations approve a build and inherit a running cost nobody budgeted.
Who Owns It and Who Writes It
Accountability for the case belongs to the sponsor — the executive who represents the investing organisation on the board. That person defends the justification, keeps it current, and answers for whether the promised benefits arrive.
Drafting is usually delegated to the project manager, working with analysts and finance. This split is deliberate and worth protecting: the person accountable for value is not the person accountable for delivery. When the two collapse into one role, the case starts being written by someone whose success is measured by the project continuing, and the appraisal loses its independence. Where the boundary of project management responsibility actually runs is covered in when a project manager is not responsible for the project.
Where the Case Gets Reviewed
Review happens at stage boundaries and whenever something material changes: a shift in the market, a supplier failure, a regulatory change, a cost estimate that has moved beyond tolerance. At each boundary the board approves the next stage against a refreshed case rather than against the original one.
This is where the schedule and cost picture has to be real. A case reviewed against a plan nobody has updated compares today’s costs with last quarter’s optimism, and the review becomes theatre. Teams that keep baselines, actuals and forecasts in one place get this for free, which is the practical value of disciplined scheduling work such as effective project management with Microsoft Project.
Deciding to Stop
The hardest use of the instrument is closing a project that has stopped making sense. Costs already spent are not an argument for spending more; the only question at a boundary is whether the remaining investment still buys the remaining benefit.
Organisations that can do this get two things. They release people and budget into initiatives that still hold, and they make honest reporting survivable — because a project that reports trouble early is not automatically a failure, it is a decision brought forward. Where projects go wrong in execution, and how those failures are usually visible before anyone acts on them, is the subject of how to avoid the most common pitfalls in project execution.
Benefits Worth Measuring
A benefit written as “improved efficiency” cannot be confirmed or denied, so it cannot be used to judge the project afterwards. A benefit written as a named measure, with a baseline, an owner and a date, can.
The discipline is to state what will be different, for whom, and how anyone would notice. Some benefits land after the project closes, which means the sponsor’s accountability outlives the delivery team — and that is exactly why the case belongs to the sponsor rather than to the project.
What Changes When the Case Is Taken Seriously
Organisations that treat justification as a live obligation start selecting differently. Initiatives compete on stated value rather than on sponsorship energy. Teams understand the economic frame of their own work, which changes what they escalate.
None of that requires heavier documentation. It requires the case to be short enough to reread at every boundary and honest enough to survive the reread.
Build Your Skills
Teams that want the full governance frame around the case — principles, themes, processes, and the roles that make the board work — will find it covered in PRINCE2 Foundation training with exam, with the practitioner level extending it to tailoring the method to a real project environment.
Frequently Asked Questions (FAQ)
How is a business case different from a feasibility study?
A feasibility study asks whether the change can be delivered at all — technically, legally, organisationally. A business case asks whether it is worth delivering. The study is often an input to the case, which is why the two get confused, but they answer different questions and can reach opposite conclusions.
How often should the case be updated?
At every stage boundary, and immediately whenever costs, benefits or risks move materially. Between those points it should be left alone; a document rewritten weekly stops being a decision record and becomes status reporting.
Should the sponsor or the project manager write it?
The sponsor is accountable for it; the project manager usually drafts it. Keeping accountability with the sponsor is what stops the appraisal from being written by the person whose work it authorises.
What if the justification collapses mid-project?
Then the board decides — reshape the scope so the remaining benefit justifies the remaining cost, or close the project in a controlled way. Continuing because the budget was already approved is the outcome the principle exists to prevent.
Does a small project need a business case?
It needs the decision, not the paperwork. Tailoring means a short, proportionate case for a small initiative — but an organisation that funds work without stating expected benefit anywhere has no way to tell later whether it was worth doing.