Project Charter Template: Free Guide & Examples
A project charter is a short, sponsor-approved document that formally authorizes a project and gives the project lead authority to use agreed resources. It defines why the work exists, the outcome it should produce, its scope boundaries, key stakeholders, milestones, risks, budget, and approval conditions before detailed planning begins.
Use the free project charter template below to turn an idea into a clear, reviewable agreement. Adapt it to software, product, operations, marketing, traditional, or Agile work.
At a glance
- Create the charter during project initiation, before detailed planning or execution.
- Keep it high level and proportionate to the project's risk and governance needs.
- Ask the sponsor to approve the purpose, boundaries, resources, and project lead's authority.
- Revise it only when a material change makes the approved direction inaccurate.
Copy-ready project charter template
Copy this template into a document and replace the bracketed prompts. If a field is unknown, write “TBD,” name the owner who will resolve it, and add a decision date instead of inventing detail.
Download the free project charter template
Choose the format that fits your workflow. Both versions include editable prompts for scope, objectives, roles, milestones, risks, budget, approvals, and the pre-approval checklist. No signup is required.
Project name: [Clear, specific name]
Charter version and date: [Version] — [Date]
Project sponsor: [Name or role with authority to approve the work]
Project lead: [Name or role responsible for coordinating delivery]
Purpose / business need: [What problem or opportunity justifies this project? Why now?]
Objective: [Deliver a measurable outcome for a defined audience by a target date or review point.]
Success metrics:
- [Metric, current baseline, target, and measurement window]
- [Quality, adoption, financial, or operational measure]
- [Required acceptance or compliance threshold]
In scope:
- [Included deliverable, process, product area, or audience]
- [Included deliverable, process, product area, or audience]
Out of scope:
- [Related work that people may reasonably assume is included]
- [Future phase, excluded platform, or unsupported use case]
Key deliverables: [Three to seven high-level outputs]
Stakeholders: [Sponsor, customers or users, affected teams, approvers, subject-matter experts]
Roles and decision rights:
- Sponsor: [Approves charter, funding, and material changes]
- Project lead: [Coordinates work and escalates decisions]
- Delivery owner(s): [Own defined outcomes or deliverables]
- Approver(s): [Accept specified outputs or controls]
Milestones:
- [Milestone or decision gate] — [Target date or project week]
- [Milestone or decision gate] — [Target date or project week]
- [Launch, handoff, or closeout] — [Target date or project week]
Budget and resources: [Approved ceiling, staffing assumptions, key tools, vendors, or equipment]
Dependencies: [External decisions, systems, teams, data, or vendors required]
Assumptions: [Conditions believed to be true but not yet confirmed]
Constraints: [Fixed deadline, policy, capacity, technology, or cost limit]
Top risks and responses:
- [If condition occurs, then impact may follow. Owner: role. Response: action.]
- [If condition occurs, then impact may follow. Owner: role. Response: action.]
Approval requirements: [Who must approve the charter, deliverables, launch, and material changes?]
Approval: [Name / role] — [Decision] — [Date] — [Signature, comment, or recorded confirmation]
What is a project charter used for?
The charter converts a proposed initiative into authorized work. The Project Management Institute's explanation of project charters emphasizes two linked functions: authorizing the project and granting the project lead authority to apply organizational resources.
That makes the charter an initiation document, not a detailed execution schedule. It should answer the questions a sponsor needs to approve the work and the questions a team needs before planning it:
- Why should this project exist?
- What outcome is the team expected to achieve?
- What is included, and what is explicitly excluded?
- Who can make which decisions?
- What limits apply to time, money, people, and quality?
- How will the sponsor decide whether the project has succeeded?
The sponsor issues or approves the charter because authorization must come from someone who controls the relevant resources. A project manager or product lead can draft it, and contributors should challenge unclear assumptions, but drafting is not the same as approval.
A small, low-risk project may use one page and a recorded approval comment. A regulated, expensive, or multi-vendor project may need more governance detail and formal signatures. For quick communication rather than authorization, use a project one-pager template.
What should a project charter include?
A useful charter is complete enough to support a decision but short enough to review. Formal templates commonly include business need, results, scope, exclusions, stakeholders, assumptions, authority, and approval. The California Project Management Framework, for example, places the charter in initiation and describes it as the document that formally authorizes a project to use organizational resources.
| Charter element | What to write | Quality check |
|---|---|---|
| Purpose | The problem, opportunity, or obligation behind the work | Explains why the project matters now |
| Objective | A specific outcome, audience, and target point | Describes a result, not a list of activities |
| Success metrics | Baseline, target, data source, and measurement window | Lets two reviewers reach the same conclusion |
| Scope | Products, processes, users, locations, and deliverables included | Sets meaningful boundaries |
| Out-of-scope work | Plausible adjacent work that is not authorized | Prevents “I assumed that was included” confusion |
| Stakeholders | People affected by, contributing to, funding, or approving the project | Includes users and operational owners, not only executives |
| Roles | Sponsor, project lead, delivery owners, reviewers, and approvers | Names decision rights as well as responsibilities |
| Risks | Uncertain events that could affect an objective | Gives each major risk an owner and response |
| Assumptions | Unverified conditions used for the initial decision | Can later be tested or replaced with evidence |
| Milestones | Major outcomes, gates, or approval points | Stays high level; avoids becoming a task schedule |
| Budget | Approved ceiling or estimate, staffing, and material resources | Makes the resource boundary explicit |
| Approvals | Who authorizes the project and accepts key outputs | Records the decision, date, and any conditions |
Also record constraints and dependencies when they can change feasibility. A fixed launch window is a constraint. Access to a partner API is a dependency. “The partner API will be available by Week 3” is an assumption until it is confirmed. Keeping those categories separate makes review and risk ownership much clearer.
How to write a project charter in six steps
1. Start with the decision, not the template
Identify the sponsor, proposed project lead, and decision the charter must support. Gather the business case, user evidence, relevant policies, estimates, and prior decisions. The template organizes that material; it does not replace the conversations needed to produce it.
2. Write the purpose and measurable objective
State the current problem or opportunity in plain language. Then turn the intended change into an objective: “Deliver [outcome] for [audience] by [target point], subject to [important constraint].” Add a small set of success metrics with baselines where available. If there is no baseline yet, assign the measurement work and deadline.
3. Draw the scope boundary
List included deliverables and affected areas, then name adjacent work that is not included. Good exclusions are specific enough to settle likely disputes. “Native mobile apps are out of scope for this release” is more useful than “additional features are out of scope.” Detailed requirements and work breakdowns can follow among the project planning phase deliverables.
4. Confirm people, authority, and resources
List the sponsor, project lead, delivery owners, stakeholders, and approvers. For critical decisions, show who recommends, decides, and must be consulted. Add the budget ceiling, expected staffing, and limits on procurement, technology, or vendor use.
5. Pressure-test the proposal
Review assumptions, dependencies, constraints, and top risks with the people closest to the work. Ask what must be true for the objective, schedule, and budget to remain credible. Convert vague risks into a condition, potential impact, owner, and planned response. Keep the full risk register outside the charter if it needs operational detail.
6. Review, approve, and baseline it
Ask stakeholders to review the sections they know best, then ask the sponsor for an explicit approve, revise, or reject decision. Record the date and any conditions. After approval, use the charter as a baseline for scope and governance—not as a reason to ignore new evidence. If purpose, authority, budget, or scope changes materially, revise and reapprove the charter.
Traditional vs. Agile project charters
Traditional and Agile teams both need a shared reason for the work, boundaries, authority, and success criteria. The difference is how much of the solution is fixed at initiation and how the charter supports learning.
| Aspect | Traditional charter | Agile charter |
|---|---|---|
| Primary emphasis | Authorize a defined project and its high-level delivery boundaries | Align people around a product vision, intended outcome, and working agreements |
| Scope | High-level deliverables may be approved early | Outcome and guardrails stay stable while features can be refined through feedback |
| Planning | Supports a more detailed schedule, budget, and project plan | Supports iterative planning through releases, backlogs, and short feedback cycles |
| Success | Delivery and business acceptance criteria | Customer or product outcome plus release criteria and quality expectations |
| Team agreements | Often documented in governance or communications plans | Often includes decision rules, collaboration norms, and a shared meaning of done |
| Change | Formal change control is common for approved baselines | Learning is expected, but material changes to purpose, funding, or authority still need approval |
Agile Alliance's project-chartering guidance describes a visible, high-level summary of objectives, scope boundaries, and agreements with external stakeholders. The practical lesson is not to fill every blank mechanically. Use the template to facilitate agreement, then keep the final charter concise enough that the team can actually refer to it.
An Agile project charter does not replace a product goal, roadmap, product backlog, sprint plan, definition of done, or team charter. It sits above those working artifacts. It explains why the initiative is authorized and which outcomes and constraints should guide iteration.
Project charter vs. project plan
The charter authorizes and frames the project; the project plan explains how the authorized work will be delivered and controlled. Do not overload the charter with task-level detail that belongs in planning.
| Comparison | Project charter | Project plan |
|---|---|---|
| Main question | Why should this project exist, and what is authorized? | How will the team execute, monitor, and close it? |
| Created | During initiation | After authorization, during planning |
| Detail | High-level purpose, scope, authority, risks, milestones, and resources | Detailed work, schedule, dependencies, costs, quality, communications, and controls |
| Owner | Sponsor issues or approves; project lead often drafts | Project manager or delivery lead develops with the team |
| Approval | Authorizes the project and use of resources | Baselines the execution approach where governance requires it |
| Changes | Updated when the approved direction or authority materially changes | Updated as estimates, sequencing, risks, and execution details evolve |
Completed project charter example: SaaS onboarding redesign
This fictional example shows the right level of specificity for a product project. Its numbers are illustrative targets, not industry benchmarks.
Project name: Guided Onboarding Release
Sponsor: Vice President of Product
Project lead: Senior Product Manager
Purpose / business need: New workspace owners often reach an empty product state without understanding the first action that creates value. The project will test and release a guided onboarding path that helps qualified new users complete that action.
Objective: Release guided onboarding to all eligible web-app sign-ups by the end of Week 8 and improve new-workspace activation during the first 30 days after full release.
Success metrics:
- Increase seven-day activation from the current 38% baseline to at least 48% within 30 days of full release.
- Reduce median time to first completed workspace from 14 minutes to 9 minutes or less.
- Maintain at least 99.5% crash-free onboarding sessions during rollout.
- Reduce onboarding-related support tickets per 1,000 new workspaces by 15% within 30 days.
In scope: Web onboarding checklist; sample workspace; CSV import entry point; event instrumentation; accessibility review; staged release; support documentation.
Out of scope: Native mobile onboarding; billing changes; enterprise provisioning; localization; redesign of the core editor; lifecycle email campaigns.
Key deliverables: Approved journey and requirements; interactive prototype; instrumented web experience; accessibility test report; release and rollback plan; support handoff; results review.
Stakeholders: Product sponsor; Growth, Design, Web Engineering, Data, Accessibility, Support, Security, and selected customer-research participants.
Roles and decision rights: The sponsor approves funding, scope changes, and full release. The product manager owns outcome definition and prioritization. The engineering lead owns technical delivery and rollback readiness. Design owns the end-to-end interaction. Data validates event definitions and results. Accessibility and Security approve their respective release criteria.
Milestones: Baseline and event definitions approved—Week 1; prototype tested—Week 3; build complete in staging—Week 5; controlled rollout begins—Week 6; full-release decision—Week 8; results review—30 days after release.
Budget and resources: Up to $85,000 in internal labor allocation and research incentives; one product manager, one designer, three engineers, and part-time Data, Accessibility, Security, and Support contributors for eight weeks.
Dependencies: Analytics event pipeline; feature-flag service; recruitment of research participants; Security and Accessibility review availability.
Assumptions: The current activation event is a valid indicator of early value; the feature-flag service supports the required audience rules; no account-architecture migration is needed.
Constraints: Eight-week delivery window; existing identity and permissions model; no changes to billing or native mobile apps.
Top risks and responses: If event quality is insufficient, the team may be unable to evaluate the release; Data owns a Week 1 instrumentation audit. If the sample workspace creates privacy or performance issues, Engineering will ship a static, account-local fallback. If usability tests show the checklist adds friction, Product will stop rollout and revise the interaction.
Approval requirements: Sponsor approval to start; Security and Accessibility approval before controlled rollout; sponsor go/no-go decision before full release; sponsor reapproval for budget increases above 10% or any addition to the excluded scope.
Approval: Vice President of Product—Approved—[Date]—Recorded in the charter decision log.
The example does not contain a backlog, sprint assignments, a full research plan, or daily dates. Those belong in execution artifacts; the charter stays focused on authorization, outcomes, boundaries, resources, and decision gates.
One-page project charter checklist
Use this checklist before requesting approval. Open boxes may signal that the proposal needs discovery first.
- The project has one accountable sponsor and one named project lead.
- The purpose explains the problem or opportunity and why it matters now.
- The objective describes an outcome, audience, and target point.
- Each success metric includes a target and a way to measure it.
- In-scope deliverables and affected areas are explicit.
- Out-of-scope work addresses the most likely misunderstandings.
- Stakeholders include users and teams affected after launch.
- Roles state decision authority, not only participation.
- Major milestones are outcomes or gates rather than task lists.
- The budget, staffing, and resource limits are visible.
- Assumptions, dependencies, and constraints are separated.
- Each top risk has an owner and a practical response.
- Approval requirements cover initiation, key outputs, and material changes.
- The sponsor's decision, date, and conditions can be audited later.
- The document is concise enough for stakeholders to read before approving.
Create a project charter in AFFiNE
You can write the formal charter in AFFiNE Page mode, using headings, tables, and checklists to keep the approved version readable. Start with the copy-ready template, remove prompts that do not apply, and add a small decision log for approval and material revisions.
Then use the AFFiNE whiteboard to map stakeholders, milestones, dependencies, and risks around the same project context. A stakeholder map, milestone path, or dependency diagram can expose gaps that are easy to miss in prose. Keep the signed-off boundaries in the page and use the canvas as a visual planning companion.
AFFiNE is the workspace for drafting and visually organizing these artifacts; it should not be treated as automated project-management, time-tracking, or calendar software. Once delivery begins, choose an appropriate reporting cadence and decide how to track project progress against the approved objective and metrics.
Frequently asked questions
What is a project charter template?
A project charter template is a reusable structure for documenting a project's purpose, objectives, scope, stakeholders, roles, risks, assumptions, milestones, budget, and approvals. It helps teams prepare a complete charter without starting from a blank page, but its fields still need evidence, discussion, and sponsor approval.
Who creates and approves a project charter?
The sponsor issues or approves the project charter because the sponsor authorizes the work and resources. A project manager, product manager, or business lead often drafts it with input from the delivery team, affected stakeholders, finance, operations, and specialists who can validate risks and constraints.
How long should a project charter be?
Most project charters should be concise—often one to three pages. A one-page charter suits a small, low-risk initiative; a complex or regulated project may need more detail or referenced appendices. Length matters less than whether decision-makers can clearly understand the authority, boundaries, resources, and approval conditions.
When should a project charter be created?
Create the charter during project initiation, before detailed planning and significant resource use. Some discovery may be needed to estimate feasibility. If too much is unknown, charter a smaller discovery phase with its own objective, budget, deadline, and approval gate rather than pretending the full project is ready.
Can a project charter change after approval?
Yes. Revise and reapprove the charter when a material change affects its purpose, scope boundary, authority, funding, success criteria, or major constraints. Routine task, sequence, and estimate changes usually belong in the project plan. Keep a version history so the team knows which direction is currently authorized.
Is a project charter required for Agile projects?
An Agile team can benefit from a concise charter even when its delivery framework does not require one. The charter aligns the sponsor and team on vision, outcomes, guardrails, resources, and release criteria while leaving room to refine features through feedback. It should support iteration, not freeze a speculative solution.
Start with authorization, then plan the work
A project charter template is useful when it leads to an explicit agreement—not when it becomes paperwork for its own sake. Define the purpose, measurable outcome, boundaries, authority, resources, risks, and approval path; get the sponsor's decision; then build the detailed plan around what has actually been authorized.
