Project Charter: What It Is and How to Write One (Template)

A project charter is the single document that formally kicks a project into existence. Skipping it is one of the most reliable ways to guarantee that a project runs over budget, over time, or over everyone's patience.

Most teams dive straight into tasks before anyone has agreed on what the project is actually trying to accomplish. The charter exists to close that gap. It forces the conversation about purpose, success criteria, and who holds authority before the first task is assigned.

What is a project charter?

A project charter is a formal document that authorizes a project to begin, defines its high-level objectives, and grants the project manager the authority to use organizational resources. It's the founding contract between the project sponsor, the project manager, and the organization.

The term comes from the Project Management Body of Knowledge (PMBOK), where PMI defines the charter as the output of the Initiating Process Group. In practical terms, the charter answers four questions up front: Why are we doing this? What will we produce? Who is responsible? And what does success look like?

A charter is not a detailed schedule, a task list, or a technical specification. It's a short, high-level document, typically two to six pages, that gives a project its official starting point. Everything that comes after, the project plan, the work breakdown structure, the Gantt chart, builds on the foundation the charter establishes.

Key Facts

• Per PMBOK 7th edition, the project charter is the document that formally authorizes a project to begin and gives the project manager authority to apply resources (PMI, 2021).
• Projects with a documented charter are 2.5x more likely to meet original goals and business intent (PMI Pulse of the Profession, 2023).
• The average project charter is 2 to 6 pages in most enterprises, with regulated industries trending longer (PMI community survey, 2024).

Why a project charter matters

Projects fail for predictable reasons. Scope creep, misaligned stakeholders, unclear ownership, and fuzzy success criteria show up in post-mortems again and again. A well-written charter attacks all four directly.

Executive sponsor alignment is the first payoff. A signed charter means the sponsor has read and agreed to the purpose, budget envelope, and success criteria. When scope disputes arise later, the charter is the reference point everyone returns to. Without it, those conversations become debates about memory and intention.

Stakeholder buy-in happens naturally when the charter process surfaces disagreements early. Different departments often have different assumptions about what a project will deliver. Writing the charter forces those assumptions into the open where they can be resolved before work starts rather than after it's underway.

Authority clarity matters more than most teams admit. The charter explicitly grants the project manager the right to assign resources, make decisions, and escalate blockers. This sounds obvious, but in matrix organizations where resources report to functional managers, a signed charter is the difference between a project manager who can get things done and one who spends all their time negotiating for access.

And the data backs this up. PMI's research shows chartered projects are 2.5x more likely to meet their original goals. That's not a marginal improvement. It's the difference between a project that delivers and one that quietly becomes a cautionary tale.

The 10 sections of a project charter

Every effective charter covers these ten areas. You don't need a template with rigid section headings, but you do need every concept present, somewhere, in the document.

1. Project name: A clear, descriptive name that the team and stakeholders will use consistently. Avoid internal code names that mean nothing outside the immediate team.

2. Purpose and justification: Why is this project being done? What business problem does it solve or what opportunity does it capture? This section should reference measurable context: revenue lost, compliance risk, customer complaints, or market timing.

3. Objectives and success criteria: What will the project achieve, and how will you know it succeeded? Objectives should follow the SMART format (Specific, Measurable, Achievable, Relevant, Time-bound). Vague objectives like "improve the customer experience" don't work here. "Reduce average onboarding time from 14 days to 7 days by Q4" does.

4. High-level requirements: The key conditions the final deliverable must meet. Not a full requirements document, but enough specificity that stakeholders agree on what "done" means. Think of this as the short list of non-negotiables.

5. Scope and deliverables: What is explicitly in scope, and what is explicitly out of scope. Both sides of the boundary matter. If something is ambiguous, call it out. Stating what's out of scope prevents scope creep as clearly as stating what's in.

6. Milestones: The major checkpoints in the project timeline, with target dates. These are not a full schedule. They're the five to ten moments where the project will demonstrate meaningful progress: end of discovery, first prototype, pilot launch, full deployment, project close.

7. Budget: The approved funding envelope and any major cost categories. Some organizations include just the total; others break it down by phase or resource type. The key is that a sponsor has signed off on a specific number, not a range.

8. Stakeholders: Who has a stake in the outcome, who will be affected, and who needs to be consulted or kept informed. This maps directly to the RACI matrix that comes later in planning. The charter version is higher-level: names, roles, and their relationship to the project.

9. Risks and assumptions: Known risks that could affect the project, with a brief note on likelihood or impact. And assumptions, the things you're treating as true without full confirmation. Both deserve attention because an unchallenged assumption is just a risk you haven't acknowledged yet.

10. Approval signatures: The formal sign-off from the project sponsor and any other required approvers. This is what transforms the document from a draft into an authorization. Without signatures, the charter is advisory. With them, it has organizational weight.

Project charter vs project plan vs scope statement

These three documents are related but serve different purposes. Confusing them causes real problems.

The charter comes first and is intentionally brief. It's written before the team fully understands the work, so it can't be detailed. The project plan is built during planning once the team has done enough analysis to make reliable commitments. The scope statement lives inside the project plan as part of the scope baseline, alongside the work breakdown structure.

A common mistake is writing the charter after the planning work is done and then back-dating it. This defeats the purpose. The charter should be written first, with the limited information available at the start, and then used to authorize the planning work.

How to write a project charter: step by step

Writing a charter is not a solo activity. It requires inputs from the sponsor, key stakeholders, and the project manager. Here's the sequence that works.

Step 1: Gather inputs before you write anything

Talk to the sponsor and relevant stakeholders before opening a template. You need to understand the business case, any constraints (budget cap, regulatory requirements, hard deadlines), and which organizational resources are available. Pull any existing documents: a business case, a request for proposal, a board decision memo. These become the raw material.

Step 2: Draft the purpose and justification

Write the "why" first. A strong purpose statement connects the project to organizational strategy or a specific business problem. If you can't articulate why the project matters in two or three sentences, that's a signal to go back to the sponsor before proceeding. Unclear purpose at charter stage becomes unclear scope at execution stage.

Step 3: Define objectives using SMART criteria

Each objective should be specific enough that a third party could verify whether it was achieved. Run each one through the SMART test. "Launch the new employee portal" is not an objective. "Launch the new employee portal to all 500 employees by March 31, with 80% of users completing onboarding within the first two weeks" is.

Limit objectives to three to five. More than that usually means the project scope is too broad and should be broken into separate initiatives.

Step 4: List scope and key deliverables

Write down what the project will produce and, critically, what it won't. The out-of-scope list is often more valuable than the in-scope list. For a CRM implementation, you might note explicitly: "Phase 1 does not include integration with the billing system" or "custom reporting is out of scope and will be addressed in Phase 2." This prevents the charter from being used to justify work that was never agreed to.

Step 5: Map stakeholders and confirm sponsor

Identify everyone who has authority over project decisions, will be affected by the outcome, or needs to be informed. Confirm who the project sponsor is, because this person will sign the charter and become the primary escalation path for issues the project manager can't resolve independently. A project without a clear, engaged sponsor almost always struggles.

Step 6: Get sign-off before planning begins

Route the draft charter to all required approvers. Hold a brief review meeting if the document surfaces disagreements. The goal is not a perfect document but a signed one. Once you have sign-off, planning can begin with the confidence that the organization is committed to the project's direction. Everything in the project life cycle that follows builds on this authorization.

Project charter template

Use this as a starting point. Adjust the headings and fields to match your organization's norms.

PROJECT CHARTER

Project Name: [Full descriptive name]
Project Manager: [Name, contact]
Project Sponsor: [Name, title]
Date: [Charter date]
Version: 1.0

---

PURPOSE AND JUSTIFICATION
[Why is this project being undertaken? What business problem does it solve?
Reference any supporting data, financial impact, or strategic priority.]

---

OBJECTIVES AND SUCCESS CRITERIA
Objective 1: [SMART objective: specific, measurable, time-bound]
Objective 2: [SMART objective]
Objective 3: [SMART objective]

Success will be measured by: [Key metrics and targets]

---

HIGH-LEVEL REQUIREMENTS
- [Requirement 1]
- [Requirement 2]
- [Requirement 3]

---

SCOPE
In Scope:
- [Deliverable or work area 1]
- [Deliverable or work area 2]

Out of Scope:
- [Explicitly excluded work 1]
- [Explicitly excluded work 2]

---

MILESTONES
Milestone 1: [Description] | Target: [Date]
Milestone 2: [Description] | Target: [Date]
Milestone 3: [Description] | Target: [Date]

---

BUDGET
Total approved budget: $[Amount]
[Optional: breakdown by phase or major cost category]

---

KEY STAKEHOLDERS
[Name] | [Role] | [Interest/influence]
[Name] | [Role] | [Interest/influence]

---

RISKS AND ASSUMPTIONS
Risks:
- [Risk 1]: [Brief likelihood/impact note]
- [Risk 2]: [Brief likelihood/impact note]

Assumptions:
- [Assumption 1]
- [Assumption 2]

---

APPROVALS

Project Sponsor: _________________ Date: _______
Project Manager: _________________ Date: _______
[Additional approver if required]: _____ Date: _______

Project charter examples by industry

The charter format stays consistent across industries, but the content looks different depending on the type of work. Here's how the same ten sections translate across four common contexts.

Notice that in each case, the objectives are measurable and time-bound. The purpose ties back to a business outcome. And the project name is descriptive enough that a new stakeholder could understand what it is without a briefing.

For teams using Waterfall methodology, the charter aligns directly with the project's first gate review. For teams using Agile or Scrum, the charter typically covers the full product initiative while individual sprints operate within that authorized scope.

Common mistakes and how to fix them

Best practices

• Write the charter with the sponsor, not for the sponsor. Collaboration during drafting surfaces disagreements early and builds shared ownership of the document.
• Use plain language. Charters fail when they're full of jargon that non-technical stakeholders skip over without reading. The sponsor needs to understand and stand behind every word.
• Keep it short enough to read in 15 minutes. If it takes longer, it's too detailed. Save the detail for planning documents.
• Version and date every revision. Charters sometimes get updated as new information emerges. Track changes so everyone knows which version is current.
• Distribute the signed charter to all key stakeholders. It's not enough to have a signed copy in a folder. The people who will execute the work should know what they're authorized to do.
• Reference the charter in planning kickoffs. Start every planning meeting by reviewing the charter objectives. This keeps planning aligned with what was actually approved.
• Review the charter at major milestones. If the project scope or objectives shift significantly, update the charter and get re-approval rather than quietly deviating from the original authorization.
• Link the charter to the PERT chart and Gantt chart that come later. Showing how the detailed schedule traces back to charter milestones reinforces discipline and makes deviations visible.

Frequently asked questions

Who writes the project charter? The project manager typically drafts the charter, but the project sponsor provides the input and must approve it. In practice, the best charters are co-authored. The sponsor brings the business case and budget authority. The project manager brings the operational structure and ensures the document is actionable. Some organizations have a PMO that owns a standard charter template, which the PM customizes for each project.

How long should a project charter be? Two to six pages covers most projects. Simple internal projects can be one page. Large, cross-functional initiatives in regulated industries may run longer due to compliance requirements. The goal is completeness, not length. If you can cover all ten sections in two pages, that's better than padding it to six.

Is a project charter the same as a scope statement? No. The charter is written in the Initiating phase, before planning begins, and provides high-level authorization. The scope statement is written during Planning and goes into detail about deliverables, acceptance criteria, and exclusions. The scope statement is part of the scope baseline that lives inside the project management plan. The charter comes first and is shorter.

Does Agile use project charters? Yes, though the format is sometimes lighter. Agile teams often use a "project brief" or "team charter" that covers the same ground: purpose, outcomes, stakeholders, and constraints. The Scrum framework doesn't mandate a charter, but the underlying need to authorize work and align stakeholders doesn't go away just because you're working in sprints. Most agile organizations write a charter for the initiative, then let sprint planning handle the details.

Who signs the project charter? At minimum, the project sponsor signs the charter. Many organizations also require the project manager's signature, and some require sign-off from a functional manager or a PMO representative. What matters is that at least one person with organizational authority has formally authorized the project to proceed and agreed to the stated objectives, budget, and scope.

---

The project charter won't guarantee a project succeeds. But it sets the conditions that make success possible. Teams that skip it spend the back half of the project relitigating decisions that should have been made at the start. Sign the charter, distribute it, and build everything else on that foundation.

And if you're ready to move from authorization into execution, the next step is turning the charter's high-level milestones into a full project plan with a work breakdown structure and a schedule built from the critical path method.