“Project Charter vs Business Case: What’s the Difference?”

What is the difference between a project charter and a business case?

project charter vs business case is a key topic in modern project management and teamwork. A business case justifies why a project should exist — the problem, the options considered, the costs and benefits, and the recommended investment. A project charter authorises the project once that investment is approved — naming the sponsor, the project manager, the objectives, the scope boundary, and the constraints the team must work within.

Put simply: the business case gets the money, and the charter gets the work started. One is an argument, the other is a mandate. A project can be justified without being authorised, which is exactly the gap between the two documents, and the reason both exist.

The practical test is who reads them. A finance director reads the business case and asks about payback. A delivery lead reads the charter and asks who approves scope changes. If a single document tried to serve both readers, it would be 40 pages long and used by neither.

Which document comes first?

The business case always precedes the charter, and the sequence is not a formality.

1. Identify the problem or opportunity. Something measurable is wrong or available: invoice processing takes 11 days, or a new regulation takes effect in nine months.
2. Build the business case. Options, costs, benefits, risks, and a recommendation with numbers. This is where the project is either funded or killed.
3. Approve the investment. A funding decision is recorded, with a budget envelope and a named sponsor.
4. Write and sign the charter. The sponsor converts the approved envelope into an authorised project with a defined scope and a named manager.
5. Plan. Detailed schedule, resources, and risk register follow the charter, not precede it.

Skipping step 2 produces projects with no exit criteria. Skipping step 4 produces projects with funding but no authority, where the manager cannot escalate because nobody agreed what success means.

What goes into a business case?

A business case has a fixed spine. The length varies from two pages for a small internal project to forty for a capital investment, but the sections do not.

Two of these are routinely missing and they are the two that matter most. “Do nothing” is a real option with a real cost, and until you cost it you have no baseline. Benefit ownership is the other: a benefit with no owner is an aspiration, and most post-implementation reviews fail on exactly this point.

What goes into a project charter?

The charter is shorter and more operational. A one-page charter that is actually signed beats a twenty-page one that was circulated for comment.

Identification. Project name, sponsor, project manager, and the date of authorisation. Boring, and the first thing an auditor asks for.

Purpose and objectives. Two or three objectives, each with a measure and a date. “Reduce invoice cycle time from 11 days to 4 days by 30 June” is an objective; “improve efficiency” is a slogan.

Scope. What is in, and — more usefully — what is explicitly out. The out-of-scope list is the cheapest change control you will ever write.

Deliverables and acceptance criteria. What will exist at the end, and who confirms it is acceptable.

High-level constraints and assumptions. Budget envelope, deadline drivers, technology or regulatory constraints, and the assumptions the plan depends on.

Authority and escalation. Who approves scope changes, who approves spend above a threshold, and what the project manager may decide alone. This section prevents most of the political damage that happens later.

High-level risks and success criteria. Three to five risks with owners, and the definition of success in terms a sponsor can confirm at closure.

How do the two documents differ at a glance?

The lifespan difference is the one teams underestimate. A business case is a living argument that gets retested when assumptions change; a charter is a stable mandate that should not quietly drift. If your charter is being edited every month, scope control has failed. If your business case has not been opened since approval, benefits are not being tracked.

How do you build the financial justification?

This is where most business cases fall apart, because the numbers are asserted rather than modelled. Here is a worked example for a realistic internal project: replacing a manual invoice process with an automated workflow.

The inputs. Implementation cost $180,000 in year zero, covering licences, integration, and internal effort at a loaded rate. Ongoing running cost $24,000 a year. Benefits are released processing effort: 14 finance staff at 6 hours a week saved during month-end, at a loaded rate of $38 an hour, which is 14 × 6 × $38 = $3,192 a week. Annualised over 46 working weeks that is $146,832. Add a $30,000 a year reduction in late-payment penalties.

The cash flows. Year 1 net benefit is $146,832 + $30,000 − $24,000 = $152,832. Year 2 rises to $168,000 as adoption matures, and year 3 to $180,000. Assume a 10% discount rate, which is a defensible corporate hurdle for a low-risk internal project.

Reading the result. Net present value is $232,872 over three years, which is positive, so the project clears the hurdle. Payback is reached during year 2: the cumulative present value is −$41,076 after year 1 and +$97,692 after year 2, with breakeven at roughly 1.3 years. The three-year return on investment is ($320,832 − $180,000) ÷ $180,000 = 78%, and the internal rate of return lands near 62%.

That single table does more for a funding decision than three pages of narrative, because a reviewer can challenge any assumption and see the effect immediately. When a director asks “what if adoption is only half?”, you can answer with a number instead of a promise.

What happens when the numbers are marginal?

Most real decisions are between two projects that both look reasonable, or one project that looks marginal. Both cases need the same discipline.

Compare two candidates on the same basis. Project A costs $480,000 and returns $210,000, $260,000, and $300,000 over three years. At 10%, the present value of benefits is $190,909 + $214,876 + $225,394 = $631,179, so NPV is $151,179 and payback is 2.03 years. Project B costs the same $480,000 and returns $150,000, $190,000, and $230,000. Its present value is $136,364 + $157,025 + $172,802 = $466,191, so NPV is −$13,809.

Project B fails the hurdle and should be rejected or rescoped, even though its total undiscounted return of $570,000 looks respectable. That gap between “$570,000 of benefits” and “−$13,809 of value” is the entire argument for discounting, and it is why a business case written in undiscounted totals can be actively misleading.

Run the downside. Halve Project A’s year-one benefit to $105,000 and hold the rest: present value becomes $95,455 + $214,876 + $225,394 = $535,725, NPV $55,725, still positive. That is a resilient business case. If halving the benefit turns NPV negative, the project is a bet rather than an investment, and it should be described that way in the recommendation.

Test the sensitivity that matters. For most projects it is adoption, not cost. A 10% cost overrun on Project A reduces NPV by $48,000; a 10% shortfall in benefits reduces it by $63,000. Knowing which lever hurts more tells you where to spend management attention.

What does delay cost?

Approval cycles have a price, and putting it in the business case changes behaviour more than any process redesign.

If Project A’s benefit is $210,000 in year one, that is roughly $808 per working day across 260 days. A six-week approval delay — 30 working days — costs about $24,231 in deferred benefit, and it also pushes payback out. A governance calendar with monthly decision meetings therefore has a real cost of up to $16,000 per project per month of waiting.

The counter-argument is that hasty approvals produce bad projects. Both are true, which is why the right structure is a standing approval slot with a fixed submission deadline, not a faster rubber stamp. The business case exists to make the decision quick, not to make it frequent.

Who approves what?

Approval authority is where charters and business cases interact, and where organisations most often improvise.

The rule that prevents most conflict: whoever signs the charter must also own the benefit. When the sponsor and the budget holder are different people, write down which one can stop the project and which one can change its scope. Two signatures with unclear precedence is worse than one.

What are the trade-offs of combining them?

Small organisations often merge the two documents, and sometimes that is correct. The trade-offs are worth stating rather than discovering.

Combining saves time and hides the decision. A single document gets written once and approved once, which is faster. It also means the funding conversation and the delivery conversation happen in the same meeting, and the funding argument usually wins because it is more urgent. Scope then gets set by whoever is in the room.

Separating creates rigour and a handoff gap. Two documents force two distinct decisions and give the project manager a mandate with a signature on it. The risk is that the charter is written by someone who did not read the business case, so the objectives drift from the benefits.

The pragmatic middle. Write a full business case, then derive a one-page charter directly from it, copying the objectives and benefit measures verbatim. That preserves traceability without producing two documents that argue with each other.

The threshold rule. Below roughly $50,000 of total investment, a combined three-page document is proportionate. Above $250,000, separation is almost always worth the extra week, because the cost of an unjustified project dwarfs the cost of a document.

What mistakes do teams make?

Writing the charter first and the case afterwards. This is the classic inversion: a project appears, a charter is drafted to make it official, and the justification is written to fit the decision. The result is a business case that cannot say no, which means it is not a decision tool at all.

Treating the business case as a one-time gate. Benefits drift, costs overrun, and assumptions expire. Revisit the case at each stage gate with actual figures, and be willing to stop. A gate that never stops anything is a calendar entry.

Leaving out “do nothing”. Without a costed baseline, every benefit looks infinite. Cost the current pain in hours, penalties, and lost revenue, or the comparison has no denominator.

Vague objectives. “Improve customer satisfaction” cannot be accepted or rejected at closure. Attach a measure, a baseline, a target, and a date to every objective in the charter.

No named authority. A charter without an escalation path produces a project manager who is accountable for outcomes they cannot control. Fix this in one paragraph.

Forgetting the assumptions list. Assumptions are the cheapest risk register you will ever write, and the first thing to check when the project starts slipping.

How does Doitify support the handoff?

Doitify is our product, so read this as disclosure. The relevant capability is not document editing; it is keeping the charter’s objectives and the business case’s benefit measures alive inside the delivery workspace. Projects hold tasks, sub-tasks, checklists, owners, and due dates, with Kanban, Gantt, roadmaps, calendars, and workload views on the same records, plus work and performance reports.

The practical benefit is traceability. When the charter says the invoice cycle time must fall from 11 days to 4, that measure can live as a reported metric on the project rather than as a sentence in a PDF nobody opens. Doitify Copilot can help turn an approved objective into the task structure that delivers it, which shortens the gap between authorisation and first sprint.

The limits are honest: Doitify is not a document management system, and it will not write your financial model. Use a spreadsheet for the NPV, then carry the decision, the objectives, and the benefit measures into the workspace where the work actually happens.

Conclusion

The business case and the project charter answer different questions, and a project needs both answers. The case justifies the spend with numbers a reviewer can challenge: options, discounted cash flow, payback, and the cost of doing nothing. The charter converts an approved spend into an authorised project with a scope boundary, a named manager, and an escalation path.

Write the case first, derive the charter from it word for word on objectives and measures, and revisit the numbers at every gate. That sequence is what turns a folder of documents into a decision, and a decision into work someone is accountable for delivering.

If this post on project charter vs business case was helpful, you might also enjoy The Best ChatGPT Prompts for Project Managers (2026 Guide) and Capacity vs Availability in Project Management: Key Differences and How to Use Both.