What Is a Project Charter?
A project charter is a short document that formally authorizes a project to begin, and defines its purpose, high-level scope, key stakeholders, and the project manager's authority to lead it. It's typically one of the very first documents created for a project, since it's what officially turns an approved idea into a project with a named owner and real authority to proceed.
Quick facts
- A project charter formally authorizes a project — it's the document that officially says "this is approved, begin work."
- It names the project manager and establishes their authority to make decisions and use resources for the project.
- It's high-level by design — detailed requirements and planning happen afterward, not inside the charter itself.
- A project charter typically follows a business case that justified the investment, and precedes detailed project planning.
- It serves as a reference point throughout the project — when scope questions come up later, the charter is often the first place to check what was originally agreed.
What a project charter typically includes
| Section | What it covers |
|---|---|
| Project purpose | Why this project exists, and what problem or opportunity it addresses |
| High-level scope | What's included, and importantly, what's explicitly out of scope |
| Objectives | What success looks like, ideally in measurable terms |
| Key stakeholders | Who's involved, including the project sponsor |
| Project manager and authority | Who's leading the project, and what decisions they're authorized to make |
| High-level budget and timeline | Rough estimates, refined further during detailed planning |
| Major risks or assumptions | Known risks or assumptions the project is being planned around |
Why a project charter matters
Without a charter, a project can start informally — someone begins work based on a verbal agreement or an email thread — which often leads to confusion later about what was actually approved, who has authority to make decisions, and what the real scope boundaries are. A charter formalizes all of this in one place, giving the project manager clear, documented authority and giving the whole team and stakeholders a shared reference for what was actually agreed at the start, before memory and assumptions start to drift.
A worked example: a simplified project charter
Project: Customer Support Ticketing System Upgrade
- Purpose: Current ticketing system can't support automated routing, causing average response times of 48 hours; this project replaces it with a system supporting automated routing and reporting.
- Scope: Includes migration of existing ticket data, automated routing configuration, and staff training. Does not include a public-facing customer portal (planned as a separate future project).
- Objectives: Reduce average response time to under 8 hours within 60 days of launch.
- Key stakeholders: VP of Customer Support (sponsor), Support team leads, IT.
- Project manager: [Name], authorized to allocate up to $50,000 without additional approval and to make day-to-day scope and resource decisions within the defined boundaries.
- High-level timeline: 4 months, target launch Q1.
- Key risks: Data migration complexity from the legacy system is not yet fully understood.
This gives everyone involved a shared, documented understanding of what's actually been approved — useful for settling a scope disagreement later ("was the customer portal part of this project? No — the charter explicitly excludes it") without relying on anyone's memory of an earlier conversation.
Project charter vs business case vs project plan
| Document | Purpose | When it's created |
|---|---|---|
| Business case | Justifies why the investment should be approved | Before the project is approved |
| Project charter | Formally authorizes the project and establishes the PM's authority | Right after approval, before detailed planning |
| Project plan | Detailed schedule, budget, and execution plan | After the charter, during detailed planning |
The charter sits between the business case (which secures approval) and the detailed project plan (which defines exactly how the work will be executed) — it's the formal bridge between "this is approved" and "here's exactly how we'll do it."
Common mistakes when writing a project charter
- Making it too detailed, turning it into a full project plan. A charter should stay high-level — detailed scheduling and task breakdowns belong in the project plan that follows, not the charter itself.
- Leaving out explicit scope boundaries. Without a clear "what's not included" section, scope disagreements later have no clear document to resolve them against.
- Not clearly defining the project manager's actual authority. A charter that names a project manager without specifying what decisions they can make on their own creates ambiguity that surfaces at the worst possible moments — mid-project, when a fast decision is needed.
- Treating it as a formality that's created and then forgotten. A charter is meant to be a living reference throughout the project, especially useful when scope or priority questions arise later.
FAQ
Who writes a project charter? Typically the project manager drafts it, often based on input from the project sponsor and key stakeholders, then the sponsor formally approves and signs it, which is what gives it its authorizing power.
Is a project charter legally binding? It's generally an internal authorization document, not a legal contract — though in some organizations, especially where formal governance processes require it, it carries significant procedural weight even without being a legal document in the traditional sense.
How long should a project charter be? Typically short — often just one to a few pages. Its value comes from being a clear, high-level reference that's easy to read and refer back to, not from covering every possible detail of the project.
Does every project need a formal charter? Larger or higher-risk projects almost always benefit from one; very small, low-risk initiatives sometimes proceed with a lighter, informal version of the same information, depending on the organization's governance practices.