The project charter is the document that formally authorizes the existence of a project and gives the project manager the authority to apply organizational resources to project activities. Without a charter, there is no project — it's just an idea.
In PMBOK terms, the charter is the primary output of the Initiating process group. It's typically created by the project sponsor (not the project manager) and serves as a contract between the project and the organization.
Why It Matters
- Formal authorization: It gives the project legitimacy within the organization. Without it, a project manager has no authority to request resources, make decisions, or allocate budget.
- Alignment: It forces stakeholders to agree on the project's purpose, objectives, and high-level scope before work begins — reducing misunderstandings later.
- Reference point: Throughout the project, the charter serves as the "North Star" that the team can refer back to when scope disputes or priority conflicts arise.
- Accountability: It names the sponsor and project manager, making ownership explicit.
What Goes Into a Charter
A good charter answers the essential questions: Why are we doing this? What will we deliver? Who is responsible? What are the boundaries? Here's a typical charter structure:
Project Name
A clear, descriptive name that everyone can reference
Project Purpose
Why this project exists — the business need or problem it solves
Objectives
Measurable goals (SMART: Specific, Measurable, Achievable, Relevant, Time-bound)
High-Level Scope
What is included and — equally important — what is explicitly excluded
Key Deliverables
The major outputs the project will produce
Milestones
High-level timeline with key dates or phases
Budget Summary
Estimated cost or approved budget range
Stakeholders
Key people involved — sponsor, PM, team leads, affected departments
Assumptions
Things assumed to be true (e.g., "Team will be co-located")
Constraints
Fixed limitations (e.g., "Must launch before Q4", "Budget capped at $500K")
Risks (High-Level)
Known risks that could threaten the project's success
Success Criteria
How will we know the project succeeded? What defines "done"?
Sign-off
Sponsor and key stakeholder approvals
How to Create a Charter
01
Gather Context
Meet with the sponsor. Understand the business case, strategic alignment, and what triggered the project.
02
Identify Stakeholders
List everyone who has an interest or influence. Interview key stakeholders for their expectations and concerns.
03
Define Objectives
Translate the business need into measurable objectives. Use SMART criteria to ensure clarity.
04
Outline Scope & Boundaries
Define what's in and what's out. Being explicit about exclusions prevents scope creep later.
05
Estimate Timeline & Budget
Provide rough-order-of-magnitude estimates. These will be refined during detailed planning.
06
Document & Get Sign-off
Write the charter, circulate for review, incorporate feedback, and obtain formal approval from the sponsor.
Common Mistakes
- Too vague: Objectives like "improve the system" are useless. Be specific: "Reduce order processing time from 48 hours to 4 hours."
- Too detailed: The charter is not a project plan. Keep it high-level — 1 to 3 pages is typical. Details come during planning.
- Skipping it entirely: Some teams jump straight into work without a charter. This almost always leads to scope confusion, resource conflicts, and lack of executive support when problems arise.
- No exclusions: Failing to state what's out of scope is as dangerous as not defining what's in scope. Stakeholders will assume everything is included.
- No sponsor sign-off: A charter without formal approval is just a document. The sign-off is what gives the PM authority.
The charter is a living reference, not a filing cabinet artifact. A well-written charter saves countless hours of debate later in the project. When someone asks "why are we doing this?" or "is this in scope?" — the answer should be in the charter. Keep it accessible and refer back to it often.