Project Charter Template
A ClickUp Doc project charter template with eight structured sections, a scaling guide for small, medium, and large projects, an approval sign-off block with e-signature status tracking, and a linked project task for charter status monitoring.
What This Includes
- Section 1: Project Overview — project name, project manager, sponsor, creation date, and version number
- Section 2: Business Case and Purpose — problem statement, expected benefit, and consequence of not acting
- Section 3: Scope and Deliverables — high-level deliverables list and a dedicated scope exclusions subsection
- Section 4: Stakeholders and Roles — stakeholder table with name, role, responsibility, and contact
- Section 5: Budget and Timeline — order-of-magnitude budget range, expected start and end dates, and key milestones
- Section 6: Risks and Constraints — known risks table and constraint list
- Section 7: Assumptions — documented assumptions that the project plan depends on
- Section 8: Approval Sign-Off — signature block with project sponsor, project manager, and key stakeholder fields and approval date
- Linked project task with Charter Status custom field tracking: Draft, Under Review, Approved, or Amended
Who This Is For
PMs who need formal authorization from multiple departments before allocating resources and beginning planning.
Consultants and agencies who need a signed authorization document that defines scope boundaries before kickoff.
PMs who want a structured starting point for their first formal project charter without having to design the document from scratch.
How to Use This Template
Open the Template and Update the Header
Open the Doc in ClickUp and update the header fields: project name, project manager name, project sponsor name, creation date, and version number (start at v1.0). The version number matters because charters sometimes require amendments mid-project: tracking versions prevents confusion about which version was signed and when.
Draft the Business Case Section First
Start with Section 2 (Business Case and Purpose) before any other section. Write three sentences: what problem does this project solve, what is the expected benefit when it is solved, and what happens to the organization if it is not solved. If you cannot write those three sentences clearly, the project is not ready to be chartered. Stakeholders who review the charter will look here first: a vague business case signals a project without a clear justification.
Define Scope Inclusions and Exclusions Together
In Section 3, list the high-level deliverables the project will produce. Then complete the Scope Exclusions subsection: list specifically what the project will not deliver. Common exclusions that generate disputes when undefined include: ongoing maintenance after launch, training for more than a defined number of users, integration with systems not listed in the inclusions, and features requested but not approved in the business case. The exclusions section is where scope disputes are prevented before they happen.
Build the Stakeholder Table
In Section 4, complete one row for each stakeholder: their name, their role in the project (sponsor, product owner, technical reviewer, approver, or informed party), and their specific responsibility. For the project manager, list the decisions they are authorized to make independently versus decisions that require sponsor escalation. Defining that boundary in the charter prevents the PM from being undermined when they make a reasonable decision that a senior stakeholder later disputes.
Record Constraints and Assumptions
In Section 6, list every constraint: hard deadlines, budget ceilings, required technology choices, team size limits, and regulatory requirements. In Section 7, list every assumption the project plan depends on: that a specific vendor will be available, that a particular team member will not be reassigned, that a regulatory approval will be granted by a specific date. Documenting assumptions serves as a risk management checkpoint: each assumption is a potential risk if proven wrong during execution.
Circulate for Review and Collect Sign-Off
Share the Doc with the sponsor, key stakeholders, and any approvers listed in Section 4. Collect comments in ClickUp Docs’ comment feature. Update the charter to reflect agreed changes and increment the version number (v1.1, v1.2). When all parties agree, complete the Section 8 approval block with each signatory’s name and the approval date. Update the linked project task’s Charter Status field to Approved. The project is now formally authorized to proceed to planning.
The most commonly skipped section in a project charter is the scope exclusions: what the project will not deliver. Completing it forces a conversation about boundaries that most teams defer until the boundary is crossed and a dispute arises. This template includes a dedicated exclusions subsection within the scope section precisely because of how often it gets omitted. See the Project Charter overview for guidance on each section’s purpose and the difference between a charter and a project plan.
Common Questions About Project Charter Template
How long should a project charter be?
One to three pages for most internal projects. Five to ten pages for large external-client projects with significant compliance or contractual requirements. The charter should be long enough to answer every section’s core questions and short enough that all signatories will actually read it before signing. A 20-page charter that no one reads before signing provides less governance than a two-page charter that every stakeholder reviews carefully.
Can I use this template for Agile projects?
Yes, with modifications. For agile projects, replace the fixed scope deliverables in Section 3 with a product vision statement and a description of what the first product increment will include. Replace the detailed timeline in Section 5 with the expected duration of the first Program Increment or quarter. Keep the business case, stakeholder, budget, and sign-off sections unchanged. The result is a lightweight agile charter that establishes authorization and stakeholder alignment without creating a false sense of fixed scope.
Who needs to sign the project charter?
At minimum: the project sponsor (the executive who controls the budget and has the authority to authorize the project) and the project manager. For cross-functional projects, add the senior representative from each department committing resources. For external client projects, add the client’s authorized representative. Do not include stakeholders who are informed but not committing resources or authority: their signature adds weight without adding meaningful accountability.