Project Charter: Template, Examples, and How to Write One
Most project charters are written, signed off, and forgotten. They look impressive at kickoff. A month later they live in a shared drive folder nobody opens, and the team improvises against weekly demands. Three months in, the charter and the work no longer match each other. By month six, the charter is wallpaper.
This guide covers the project charter as it actually works in 2026. The 7 essential elements. The lean vs full split. The difference between a charter, an SOW, and a project plan. Plus a 5-step process to write one in under an hour. Run the picker below to find out whether your project needs a lean or full charter before you start writing.
Lean charter or full charter?
Answer 4 questions for a recommendation on the right depth.
1. Duration
2. Team size
3. Budget
4. Audience
Start over
Quick answer. A project charter is the document that formally authorizes a project. It captures purpose, objectives, scope, stakeholders, timeline, budget, and risks in 1 to 2 pages. Use a lean charter (1 page, 4 sections) for short, low-budget, single-team work. Use a full charter (2 pages, all 7 sections plus sign-off) for cross-team initiatives, regulated work, or client-facing engagements. The charter is not the project plan, and it is not the SOW.
What a project charter is for
The project charter has a specific job in project management. It authorizes the work to start, names who has authority over what, and creates a written record of what was agreed before any tasks were assigned. Without it, scope creep is unprovable, sign-off is verbal, and accountability is whoever was in the room at kickoff.
"A document issued by the project initiator or sponsor that formally authorizes the existence of a project, and provides the project manager with the authority to apply organizational resources to project activities." - PMI, PMBOK Guide (6th edition)
The PMBOK definition captures the function. The charter is the authorization document. Three things follow from that. First, the sponsor is the person who signs it; for client work, that is the client lead with budget authority, not your internal account manager. Second, the charter is written before the project plan, not after. The plan operationalizes the charter. Third, the charter stays as the reference point through the project. Material changes to scope, timeline, budget, or stakeholders go back to the charter and trigger a re-sign-off, not a Slack message. The project roadmap is what visualizes those phases over time so stakeholders can see them at a glance.
For more on how scope is captured inside the charter, see our project scope guide. For the legal-contract side of client engagements, see our scope of work template, which compares cleanly to the charter further down this page.
The 7 essential elements
The charter is built around 7 elements. Each captures a distinct part of the work and a distinct kind of risk. Skip an element and the charter has a hole that scope creep eventually fills.
| Element | What it captures | Common mistake | Agency example |
|---|---|---|---|
| Purpose | Why the project exists, the problem it solves, cost of inaction | Vague mission language ("improve customer experience") | "Cut checkout abandonment from 22% to 15% to recover $1.2M in annual revenue" |
| Objectives and success criteria | 2 to 4 SMART objectives with baselines and targets | Activities listed instead of outcomes | "Ship redesigned checkout by Sept 30; reduce 3-step checkout from 47s to 25s median" |
| Scope | In-scope deliverables and an explicit out-of-scope list | Skipping the out-of-scope list (the strongest defense against scope creep) | In: checkout redesign + payment integration. Out: account management, marketing email flows |
| Stakeholders and roles | Sponsor, project manager, core team, approvers | Listing 15 names without clarifying decision authority | Sponsor: client VP Product. PM: agency lead. Approvers: client legal for payment terms |
| Timeline and milestones | Kickoff, end date, 4 to 6 major milestones | Mistaking the charter for the project plan and adding too much detail | Kickoff Aug 1, design freeze Aug 22, dev complete Sept 19, launch Sept 30 |
| Budget and resources | Headline budget, internal effort, external costs | Burying the number; the charter needs the headline visible | "$45K total: $32K agency fees, $8K Stripe integration, $5K user testing" |
| Risks and assumptions | Top 3 to 5 risks with owner and mitigation; key assumptions | Listing risks without owners or mitigations | "Stripe API changes (PM owns; mitigation: lock SDK version). Assumption: client legal turnaround under 5 days" |
Two notes on the elements. The out-of-scope list inside Scope is the strongest single defense against scope creep. It costs 5 minutes to write and saves weeks of re-litigation. Write it explicitly, by name. "Account management is out of scope. Marketing email flows are out of scope." Vague exclusions get ignored.
The Risks element is the most commonly skipped. Teams write the charter, capture the obvious risks, and forget that risks need owners and mitigations. A risk listed without an owner is a problem nobody solves. Assign each risk to a named person, write down the mitigation in 1 sentence, and re-read at major milestones.
Lean charter vs full charter
Not every project needs a 2-page charter. The same is true in reverse: a 1-pager is not enough for a $200K cross-team initiative with regulatory exposure. Match the charter depth to the project size before you start writing.
| Aspect | Lean charter | Full charter |
|---|---|---|
| When to use | Under 8 weeks, single team, under $50K, internal | 8+ weeks, cross-team, $50K+, regulated, or client-facing |
| Length | 1 page (or 1 short Note) | 1 to 2 pages (or 1 longer Note with all 7 sections) |
| Time to draft | 30 to 60 minutes | 2 to 4 hours, plus 1 to 3 days for review and sign-off |
| Sections included | Purpose, Objectives, Scope (in/out), Sign-off | All 7 elements plus Sign-off log |
| Risk treatment | One sentence on top risk; mitigation in project plan | 3 to 5 risks with owners and mitigations |
| Stakeholder list | Sponsor and PM only | Sponsor, PM, core team, approvers (RACI optional) |
| Sign-off | Sponsor approval inline (single signature) | Sponsor + relevant approvers (legal, finance for client work) |
| Re-read cadence | At end of project for closeout | At each major milestone or scope change |
The lean version covers 4 of the 7 elements (Purpose, Objectives, Scope with in/out, Sign-off). It takes 30 to 60 minutes to draft and gets sponsor approval the same day. Use it for short engagements with low scope-creep risk.
The full version covers all 7 elements plus a Sign-off log. It takes 2 to 4 hours to draft and 1 to 3 days for review. Use it whenever the project crosses one or more thresholds: 8+ weeks, 4+ team members, $50K+ budget, regulated industry, or client-facing. Any one of those is enough to justify the longer version.
Most charters that fail are picking the wrong depth. A lean charter on a 6-month client engagement leaves too much room for scope drift. A full charter on a 2-week internal task wastes hours and signals over-process. The picker at the top of this page makes the call in under 2 minutes.
Charter vs SOW vs project plan
Three documents get confused at the start of agency engagements. The project charter, the statement of work (SOW), and the project plan. They have different purposes, different audiences, and different signers. A team that conflates them ends up with one bloated doc that does none of the three jobs well.
| Aspect | Project Charter | Statement of Work (SOW) | Project Plan |
|---|---|---|---|
| Primary purpose | Authorizes the project to start | Defines what will be delivered (often contractual) | Specifies how the work will get done |
| Audience | Sponsor, executive, client lead | Buyer and seller (legal-binding) | Project team and PM |
| Length | 1 to 2 pages | 5 to 30 pages depending on scope | 10 to 100+ pages or a structured workspace |
| Signed by | Sponsor (and major approvers) | Buyer and seller (legally binding) | PM (no formal sign-off needed) |
| When written | At project initiation, before authorization | During contract negotiation, before kickoff | After charter is signed, before execution begins |
| Key sections | Purpose, scope, stakeholders, budget headline | Deliverables, acceptance criteria, terms, payment | WBS, schedule, resource plan, communication plan, risk register |
| Mostly used in | All formal projects (internal and client work) | Client engagements and procurement | Mid-to-large projects past kickoff |
| Failure mode | Dies in a Word doc; team forgets the original scope | Becomes legalese nobody re-reads after signing | Goes stale within weeks of kickoff if not updated |
The charter authorizes. The SOW contracts. The plan executes. In sequence: SOW gets signed during procurement (legal-binding), charter gets signed at project initiation (authorization), and plan gets built once the charter is approved (operational).
For a typical agency client engagement, all three exist. The SOW lives with the client legal team and gets referenced when payment terms or acceptance criteria come up. The charter lives in the project workspace where the team works daily. The plan lives in the PM tool with the task board and the schedule. Treating them as one document is the most common cause of charters that fail to authorize anything.
How to write a project charter
The 5-step process below works for both lean and full charters. The difference is depth at each step, not the steps themselves.
Step 1: Build the business case. Write 2 to 3 sentences on why the project exists. What problem it solves, what the cost of inaction is, and what success looks like at a high level. If you cannot write this in 30 seconds, the project is not ready to start.
Step 2: Define scope explicitly. List the in-scope deliverables in 3 to 8 lines. Then list the out-of-scope items in 3 to 8 more lines. The out-of-scope list takes longer to draft because it forces you to name what you are NOT doing. That is the point. Specific exclusions block scope creep at the source.
Step 3: Set SMART objectives. Write 2 to 4 measurable success criteria with baselines and targets. "Reduce checkout abandonment from 22% to 15% by Sept 30." Vague goals like "improve conversion" cannot be evaluated at project close. The team will declare success regardless of the actual outcome.
Step 4: Name stakeholders and roles. Sponsor signs off on the charter. Project manager is accountable for delivery. Core team is 3 to 6 names with roles. Approvers are anyone who signs off on key decisions outside the sponsor. For client work, the sponsor is the client lead with budget authority. Document their full name, role, and contact.
Step 5: Capture risks and route for sign-off. List the top 3 to 5 risks with owners and mitigations. List the top 3 to 5 assumptions. Then send the charter to the sponsor for formal approval. Once signed, the charter authorizes the project to proceed and material changes need re-approval.
The 5 steps fit inside an hour for a lean charter and inside an afternoon for a full one. The single biggest predictor of charter quality is whether someone other than the project manager reads the draft before sign-off. Get a second pair of eyes on it. The errors are usually in the Scope section.
Project charter examples
Two worked examples, one lean and one full.
Example 1: Agency client engagement (lean charter).
Project name: Brand refresh for software company client.
Purpose: Update the client brand identity to match a Series B repositioning. Cost of inaction: continued mismatch between sales messaging and brand voice.
Objectives: Ship new logo, type system, and brand guidelines by August 15. Capture client approval at the end of week 4.
Scope: In: logo, type system, color palette, brand guidelines doc, 4 brand asset templates. Out: website redesign, email templates, social ad creative.
Sponsor: Client VP Marketing. PM: Agency creative lead.
Timeline: 8 weeks, kickoff June 18, delivery August 15.
Budget: $32,000 fixed-fee.
Sign-off: Client VP Marketing, signed June 17.
This lean charter is ~150 words. It fits on one page. It authorizes the project, names the sponsor, and locks scope. Anything outside the in-scope list needs a change order.
Example 2: Internal initiative (full charter).
Project name: CRM migration to HubSpot.
Purpose: Replace legacy CRM with HubSpot to reduce per-seat cost and unify sales and marketing data. Cost of inaction: $80K annual licensing premium plus blocked attribution reporting.
Objectives: 1) Cut CRM licensing cost from $120K to $40K annually. 2) Migrate 100% of contact records by Sept 30. 3) Sales team trained and operating in HubSpot by October 15.
Scope: In: contact migration, deal pipeline configuration, sales-marketing data model, training for 35 sales reps. Out: marketing automation rebuild, custom reporting dashboards (separate project), Salesforce data archive (kept, not migrated).
Stakeholders: Sponsor: VP Revenue. PM: RevOps lead. Core team: IT director, sales ops manager, marketing ops manager, 2 RevOps analysts. Approvers: CFO (budget over $150K), VP IT (data residency).
Timeline: Kickoff July 8, data migration Aug 8, training Sept 1-15, go-live Oct 15. 6 milestones.
Budget: $180,000 (HubSpot license $90K, data migration vendor $50K, internal effort 280 hours, training contractor $40K).
Risks: Data integrity during migration (PM owns; mitigation: 2-week dry run). Sales team adoption (RevOps owns; mitigation: phased training, 1:1 office hours). Vendor delay (PM owns; mitigation: 2-week buffer in schedule).
Sign-off: VP Revenue + CFO + VP IT, signed July 5.
This full charter is ~250 words. It authorizes a 14-week internal initiative with clear scope boundaries, named risks, and sign-off from 3 approvers. Material changes (new scope, budget overage, timeline slip) trigger a re-sign-off. For more on resource modeling at this stage, see our capacity planning guide.
Project charter template
The Rock project charter template ships as a workspace, not a Word doc. The charter lives as a Note pinned to the project space. Kickoff actions live on a task board next to it. Sponsor sign-off is logged at the bottom of the same Note, with version history visible. Clients can join the space cross-org at no extra cost, so sign-off happens inline instead of in a separate email thread.
The template includes 2 notes (orientation and the charter itself), a 5-card kickoff task board, and a budget sheet stub in Files. It works for both lean and full charters; readers skip the optional sections for the lean version.

If you prefer a static Word or PDF charter, plenty of options exist (Asana, Smartsheet, ProjectManager.com all publish free downloads). The structural difference is that a Word doc gets signed at kickoff and forgotten. A workspace-based charter stays in front of the team daily because it lives where the work happens. For a similar workspace-style approach to other PM artifacts, see our project management framework guide and stakeholder map walkthrough.
What we recommend
The honest answer is that the charter format matters less than whether the team re-reads it. Most charter failures are not about which template you used. They are about charters that get signed at kickoff and never reopened.
Pick a workspace-based charter when the project will run more than 4 weeks. Or when the client or sponsor needs visibility into status. Or when scope changes are likely (most agency client work). Charter as a Note in the project space stays visible. The team sees it daily. Sign-off is inline.
Pick a Word doc charter when your organization has compliance requirements that force PDF sign-off. Or when the sponsor only uses email and Office. Or when the project is internal with no daily team-client contact. The Word doc is fine for these cases. Just schedule re-reads at major milestones to avoid the wallpaper failure.
Skip the charter when the project will run under 1 week. Or when the work is fully automated routine (recurring monthly reports). Or when an existing master agreement or SOW already contains the same elements. In that last case, link the SOW from the project space and skip the charter.
The pattern we see at Rock is consistent. Agencies running multiple client engagements get the most value from a charter living in the same workspace as their chat, tasks, and files. Cross-org makes sponsor sign-off literal: the client opens the Note, types their approval, and it logs with a timestamp. No PDF chasing, no separate email thread, no version drift between agency and client copies.
FAQ
What is the difference between a project charter and a project plan?
The charter authorizes the project at high level (purpose, scope, stakeholders, budget headline). The project plan operationalizes the charter (work breakdown, schedule, resource plan, communication plan). The charter is signed at initiation by the sponsor. The plan is built after sign-off by the PM and team. A charter is 1 to 2 pages; a project plan can be 10 to 100+ pages or a full workspace.
Who writes the project charter?
The project manager writes the charter. The sponsor signs it. For client engagements, the sponsor is the client lead with budget authority. The PM drafts, routes for review, captures stakeholder input, and gets formal sign-off before the project starts.
How long should a project charter be?
One page for a lean charter, two pages for a full charter. Anything longer is creeping into project plan territory. The charter is meant to be re-read at major milestones, which only happens if it is short enough to scan in 5 minutes.
Can a project charter prevent scope creep?
It cannot prevent scope creep on its own, but it gives you the tool to defend against it. The out-of-scope list is the strongest single mechanism. When a stakeholder requests something outside the explicit out-of-scope list, the charter is the artifact that triggers a change order discussion instead of a quiet expansion of the work.
Do small projects need a charter?
Not always. Projects under 1 week or with under $5K in effort usually do not need a formal charter. Projects under 8 weeks with under $50K in effort can use a lean 1-page charter (the picker at the top of this page makes the call). Skip the formality when the work is genuinely small. Add it back when the project crosses a threshold.
Is a project charter the same as a statement of work?
No. The charter is internal authorization (signed by the sponsor). The SOW is contractual (signed by buyer and seller, often with legal review). For client engagements both usually exist: the SOW with client legal, the charter inside the project workspace. The charter references the SOW; the SOW does not replace the charter.
The right charter is the one your team re-reads. Rock keeps the charter, the kickoff actions, and the sign-off log in one project space. Flat pricing, unlimited users, clients included. Get started for free.








