Vact How to Write a Project Charter That Actually Gets Read
A project charter is a one-to-three page document that authorizes the project, defines its purpose, and establishes the PM’s authority to spend organizational resources. It is the first artifact a project produces and the document people reference when they forget why the project exists.
How to Write a Project Charter That Actually Gets Read
Most project charters are either too short to be useful or too long to be read. A 20-page charter with detailed requirements, risk analysis, and resource plans is really a project plan mislabeled. A one-paragraph charter that says “build the new website” provides no guidance. The sweet spot is a focused document that answers seven questions clearly.
The Seven Questions Every Charter Must Answer
1. Why Does This Project Exist?
State the business problem or opportunity in concrete terms. Avoid corporate jargon.
Weak: “To enhance our digital presence and leverage synergies across customer-facing platforms.”
Strong: “Customer support call volume increased 40% in Q3 2024 because the existing self-service portal lacks the top 15 requested features. This project builds those features to reduce call volume by 25% within 6 months of launch.”
The “why” should connect to a measurable business outcome — revenue, cost reduction, customer satisfaction, or risk mitigation. If you cannot articulate a measurable benefit, the project may not be worth doing.
2. What Will the Project Deliver?
List the major deliverables in specific terms. Each should be something you can point to and say “this is done” or “this is not done.”
- Redesigned self-service portal with 15 new feature modules
- Migration of existing user accounts to the new platform
- Training materials for customer support team
- API integration with the existing CRM system
This is not a detailed work breakdown structure — that comes later in planning. The charter establishes what the project will produce at the highest level.
3. What Is NOT in Scope?
Explicitly listing out-of-scope items prevents the number one source of scope creep: assumptions. If stakeholders might reasonably expect something to be included, list it as excluded.
- Mobile app (separate project, planned for Q4)
- Migration of historical support tickets (manual process, handled by ops team)
- Redesign of the main marketing website
4. Who Are the Key Stakeholders?
| Role | Person | Responsibility |
|---|---|---|
| Project Sponsor | VP Customer Experience | Funding, executive decisions |
| Product Owner | Director of Support | Requirements, acceptance |
| Project Manager | [Name] | Planning, execution, reporting |
| Technical Lead | [Name] | Architecture, technical decisions |
| Key Stakeholders | Support Team Leads | User feedback, UAT |
This table establishes who makes decisions, who needs to be consulted, and who is accountable. It prevents the “I thought I was in charge of that” conversations. See stakeholder management for frameworks to identify and categorize stakeholders.
5. What Are the Constraints?
Constraints are non-negotiable boundaries the project must work within:
- Budget: $150,000 total project cost, capital expenditure
- Timeline: Launch by September 1, 2025, to align with fiscal year planning
- Resources: Current team only, no additional headcount approved
- Technical: Must integrate with existing Salesforce CRM instance
- Regulatory: Must comply with GDPR data handling requirements
Constraints differ from scope. Scope defines what you build; constraints define the boundaries you build within.
6. What Are the Major Risks?
The charter does not need a full risk register, but it should flag the three to five risks that could kill the project. This signals to the sponsor that you have thought about what could go wrong.
- Salesforce API rate limits may require architectural changes (mitigate: prototype integration in week 2)
- Key developer shared with Project Y, may have competing priorities (mitigate: confirm allocation with resource manager before kickoff)
- Customer support team may resist changing workflows (mitigate: include support leads in design reviews)
7. How Will Success Be Measured?
Define two to three measurable success criteria that will be evaluated after the project delivers:
- Customer support call volume decreases by 25% within 6 months
- Self-service portal task completion rate exceeds 80%
- Customer satisfaction score (CSAT) for support interactions improves by 10 points
These metrics connect back to the “why” from question one. They give the team a clear target and provide the basis for the eventual post-mortem evaluation.
Writing Tips
Keep it short. If your charter exceeds three pages, you are including planning details that belong in the project plan. The charter is an authorization document, not a planning document.
Use plain language. The charter should be readable by anyone in the organization, including executives who do not know the technical details. Replace jargon with specifics.
Get it signed. The charter must be approved by the project sponsor. This approval is what gives the PM authority to request resources, spend budget, and make project decisions. Without a signed charter, the PM has no formal authority — every resource request becomes a personal favor.
Store it visibly. The charter should be linked in the project’s documentation hub, pinned in the project Slack channel, and referenced in the kickoff meeting. It is the document people return to when scope discussions get contentious: “Here is what we agreed to.”
Charter Anti-Patterns
The charter that lists everything. Including detailed requirements, full risk analysis, and resource Gantt charts in the charter creates a document nobody reads. Those details belong in dedicated planning artifacts.
The charter that commits to nothing. “We will build a great product on time and on budget.” This charter gives the PM no leverage when stakeholders request changes because nothing specific was agreed to.
The charter written after the project starts. Sometimes projects begin informally and the charter is written retroactively to satisfy a process checklist. This misses the entire point — the charter’s value is in forcing alignment before work begins.
The charter nobody signed. An unsigned charter is a proposal, not an authorization. It protects nobody and commits nobody. Get the sponsor’s signature before spending any significant effort on planning.
A well-written charter takes two to four hours to draft and one meeting to finalize. That investment saves weeks of misalignment downstream. Every time a stakeholder asks “Can we add…” or “I thought the project was supposed to…”, the charter is the document that resolves the question.