Project Charter vs Business Case: What's the Difference?
A business case argues whether the investment should be made: costs, benefits, options and payback. A charter authorises the work once that decision is taken, and defines scope, objectives, roles, milestones and tolerances. The business case is written for the people holding the budget. The charter is written for the people doing the work and the stakeholders around them.
Side by side
They sit either side of one moment: the funding decision. Everything before it is argument; everything after it is definition. Confusing the two produces a charter full of benefits nobody will be measured on, or a business case full of delivery detail nobody in finance will read.
| Aspect | Project charter | Business case |
|---|---|---|
| Question it answers | What are we doing, who decides, and within what limits? | Is this worth doing, compared with the alternatives? |
| Written when | After approval, before work starts | Before approval |
| Owned by | Project manager, signed by the sponsor | Sponsor, usually with finance |
| Core content | Objectives, scope, roles, milestones, budget envelope, tolerances | Options, costs, benefits, assumptions, payback, risks to the case |
| Primary audience | Delivery team and stakeholders | Investment board, finance, portfolio governance |
| Financial detail | The approved envelope, nothing more | A full model with a do-nothing option |
| Lifespan | Baseline reference through delivery | Revisited at gates and after benefits land |
| Typical length | One to three pages | Several pages plus a spreadsheet model |
| Fails when | Scope was never agreed by the people it affects | Benefits have no named owner after go-live |
When you need a business case
You need one whenever money is being asked for and there is more than one way to spend it. Its job is comparison, which is why a case with a single option is not really a case — it is a request. At minimum it needs the do-nothing option costed, because "what happens if we do not do this" is the question the board will ask and the one most cases answer worst.
The sections that carry the weight are the cost and benefit registers and the assumptions log. Costs are usually the easy half. Benefits need to be split into cash-releasing, cost-avoidance and non-financial, and each cash-releasing benefit needs a name attached — the budget holder whose line it will eventually come out of. A benefit nobody has agreed to give up budget for will not be realised.
The assumptions log is what makes the case survivable. Every number rests on something: adoption rate, licence pricing, headcount, migration volume. Writing those down separately means that when one turns out to be wrong, you can rerun the case rather than defend it. Our business case template keeps the assumptions on their own tab and carries a benefits realisation view for the year after delivery, because that is where most cases quietly stop.
When you need a project charter
You need a charter once the money exists and the work is about to start. It is a short, blunt document whose purpose is to stop three specific arguments happening in month four: what is in scope, who can decide what, and what counts as done.
Scope needs an out-of-scope list, and the out-of-scope list is the more useful half. Objectives need to be measurable in a way somebody outside the team could verify. Roles need naming rather than describing — a RACI attached to the charter settles more disputes than a paragraph about governance ever will. Tolerances need numbers: how far can time, cost and scope move before this comes back to the sponsor.
The charter is also the moment to agree the reporting contract. Who gets what, how often, and to which forum. Agreeing it on day one costs an hour; agreeing it in month three costs the same hour plus every misaligned report in between. Our charter and kickoff pack pairs the charter with a RACI, a stakeholder and comms plan and a pre-kickoff checklist for that reason.
When you need both
Any project large enough to have a sponsor and a budget line needs both, and they need to be consistent. The charter's objectives should be traceable to the business case's benefits — if an objective in the charter does not serve a benefit in the case, either the scope has grown or the case was incomplete.
The link between them also matters at the end. A change request that moves cost or schedule beyond tolerance should trigger a check against the business case, not just a re-plan. If a project delivers on its charter but the case no longer stands up, that is a decision for the sponsor, and it is far cheaper to surface it at the change request than at closure. Keeping impact assessments attached to each request, as in the change request log, is what makes that check possible rather than theoretical.
At portfolio level the two documents do different jobs again. The business case feeds prioritisation and comparison across projects; the charter feeds resourcing and dependency mapping. A portfolio view needs both, which is why a small PMO's starting set usually includes a template for each.
The overlap
The overlap is real and it is where duplication creeps in. Both documents describe the problem being solved. Both list high-level scope. Both name the sponsor. Both carry a milestone view and a top-level risk summary. In smaller organisations they are sometimes merged into a single approval document, and for a project of a few weeks that is a sensible economy.
Where merging goes wrong is at scale and over time. The business case is revisited at gates by people who care about return; the charter is referenced weekly by people who care about scope. A merged document either gets updated for one audience and confuses the other, or gets frozen and serves neither. The practical split is to write the case once, properly, and let the charter cite it rather than repeat it.
One more honest point: neither document prevents anything by existing. A charter does not stop scope creep; it makes scope creep visible and gives it somewhere to be decided. A business case does not guarantee benefits; it records who said they would be delivered and on what assumptions. The value is in having something specific to check reality against, which is also what makes closure worth doing properly.
Questions
Which comes first?
The business case. It supports the decision to fund the work; the charter is written once that decision has been made and defines what was actually authorised.
Can a small project skip the business case?
Many organisations set a threshold below which a short justification is enough. The parts worth keeping even then are the do-nothing option and the assumptions the numbers rest on.
Who signs the charter?
The sponsor. The project manager usually writes it, but a charter without a sponsor's signature does not authorise anything, and the tolerances in it are meaningless.
Does the business case get updated during delivery?
It should be revisited at each gate and whenever a change request moves cost, schedule or benefits materially. Otherwise the project delivers against a case that stopped being true months earlier.
What is the difference between a charter and a PID?
A PID is a fuller PRINCE2 document that includes the business case, plans and controls in one place. A charter is shorter and typically references the business case rather than containing it.