Business Case vs Project Charter: What’s the Difference?
The two documents get bundled together at initiation, approved in the same meeting, and filed in the same folder, which is why they are so often treated as one thing with two names. They answer different questions, they belong to different people, and they behave completely differently once the project is running.
Section 4 of the PMBOK® Guide Eighth Edition covers both among the artefacts a project works with, and the distinction that matters in practice is what each one is still doing in month nine.
Two documents, two questions
The business case answers whether the work is worth doing. What problem or opportunity exists, what the options were, what this one costs, what benefit it produces, when that benefit appears and who collects it. It belongs to the sponsor and it is an argument, which means it can be defeated by new information.
The charter answers whether the work is authorised and who runs it. It commits the organisation, appoints a project manager, states the objective and sets the limits that manager works inside. It belongs to the organisation and it works as an instrument: it persuades nobody of anything, it simply establishes that this is happening.
Three practical consequences
They fail differently and you take the failures to different places. A problem with feasibility, resources or authority goes to whoever chartered the project. A problem with viability, where the benefit has shrunk or the cost has grown past what it is worth, goes to whoever owns the case, and the honest version of that conversation includes the possibility of stopping.
Only one of them is meant to be revisited. A charter is written once and amended rarely; a business case is supposed to be retested whenever something material changes, and at every gate. Organisations that approve a case at the start and never look at it again have converted an argument into a permission slip, which is how projects outlive their own justification.
A significant change affects both, in sequence. A scope change alters what is being delivered, so the case has to be retested first: does this still produce enough benefit to be worth the cost? Only when that is answered does the question of authority and limits arise. Projects that reverse the order end up with a properly approved change to something that should have stopped.
A floor fitted out for people who did not arrive
A financial services firm was refurbishing two floors of its head office. The business case rested on consolidation: two satellite offices would close, their leases ending within the year, and about three hundred people would move into the refurbished space, saving a substantial annual sum in rent.
The charter was clear, the funding was approved, and the works started in the spring. Six months in, the firm's working pattern settled into something nobody had planned for: attendance across the business had fallen to about two days a week, and the satellite offices' leases were renegotiated down to smaller footprints and kept. The consolidation saving, which was the whole of the case, was no longer available in the form the case described.
The project continued. It was properly chartered, the budget was approved, the contractor was engaged, and stopping felt like failure. It completed on time and slightly under budget, and it is a well-executed refurbishment.
At handover, the locker bank on the west side stood with every door ajar and a numbered key in each lock, and it stayed that way for months, because the population that was to have filled it never arrived. Nobody had done anything wrong at any point. What had not happened was the one thing that should have: a return to the case in the month the leases were renegotiated, to ask whether the remaining benefit still justified the remaining spend.
The answer might well have been yes, with a reduced scope. It was never asked, because the project's governance had a charter, a plan and a change process, and no mechanism at all for questioning the reason.
Where they overlap without conflicting
The objective appears in both. The charter states it briefly as a commitment; the case explains why it is worth achieving. They should say compatible things, and when a project's charter objective and its business case benefit have drifted apart, that is worth noticing and worth asking about.
Both are needed on adaptive work. A team working iteratively still has an authorisation and still has a justification, and the second one gains importance rather than losing it, because adaptive delivery is supposed to be able to stop when the value stops appearing. That only works if somebody is still holding the case.
For a PMP® candidate, the point to hold is that authorisation and justification are separate and maintained by different people, so a scenario where circumstances have undermined the benefit is a business case question rather than a change control question. A response that processes a change request has kept the project moving without asking whether it should. A structured PMP exam preparation course takes on situations where a project is running well and no longer worth doing.
Find your business case and read the paragraph describing the benefit. If anything in it has changed since approval, that belongs in front of your sponsor this month, framed as a question about the case. It is an uncomfortable conversation and it is considerably more comfortable than the one at handover.
Interested in going further?
Projects rarely fail because nobody authorised them; they fail because nobody went back to the reason. Omega's PMP® Exam Preparation works through justification and authority as two separate obligations.
Both artefacts are described in the PMBOK® Guide Eighth Edition.
Ad · Amazon affiliate link.
References
A167: Project Charter Explained: Purpose, Content and Common Misunderstandings
A170: Decision Log: The Forgotten Project Control
A169: Assumption Log vs Risk Register
A155: Risk Register vs Risk Report vs Issue Log: What Goes Where?
A174: Work Breakdown Structure: Still Useful in 2026?
PMP and PMBOK are registered marks of the Project Management Institute, Inc.
