Skip the charter, start the work. Sounds efficient. Usually isn't. Projects without a charter drift. Teams disagree on goals mid-flight. Stakeholders surface unexpected requirements after you've built the wrong thing. A charter doesn't take long to write, and it pays back every time someone asks "what are we actually trying to do here?"
What a Project Charter Actually Does
A project charter authorizes a project and gives the project manager the authority to allocate resources. It describes the goal, the business case, constraints, risks, stakeholders, and budget at a high level. It is not a step-by-step execution plan. Think of it as the "why and what" document, while the project plan covers the "how and when."
The PMI, a standards body in project management, calls it a document that the project sponsor signs off on, granting the project manager formal authority to direct organizational resources toward the work.
Key Elements to Include
Every charter needs enough detail to align everyone, but not so much that it becomes a plan. Core elements:
- Business case**: Why is this project being done? What problem does it solve or what opportunity does it capture?
- Goals and scope**: What does success look like? What's explicitly in scope and out of scope?
- Constraints**: Budget, timeline, and resource limits. These define the boundaries the team must work within.
- Risks**: Key risks identified at the outset, even if they're high-level.
- Stakeholders**: Who cares about this project? Name the sponsors, decision-makers, and affected teams.
- Budget**: High-level numbers, not line-item detail. If the budget is still unknown, state the decision process for determining it.
Charter vs. Project Plan
The two documents serve different purposes. The charter is written early and stays stable. The plan is written after approval and evolves as work progresses.
Use the charter to onboard new team members and align stakeholders before kickoff. Use the plan to track tasks, milestones, and deadlines during execution.
How to Write One Efficiently
Don't write a charter in isolation. Gather the relevant people—sponsor, Product Owner, key stakeholders—and discuss the elements together. This conversation is often more valuable than the document itself.
Keep the charter brief. Use bullets and headings. One to two pages is usually enough. If your charter runs longer than three pages, you're probably writing a plan, not a charter.
Our analysis
Teams skip charters for two reasons: speed and uncertainty. They want to start, and they don't have all the answers yet. But a charter doesn't require complete certainty—it requires explicit alignment on what you think is true now. The act of writing it surfaces disagreements early, when they're cheap to resolve.
For Scrum teams, the charter feeds directly into sprint planning. If the team doesn't understand why the project exists or who the stakeholders are, backlog items get prioritized based on whoever speaks loudest, not on business value.
Try this in your next sprint
Say you're starting a website redesign project. Before your next sprint planning session, draft a one-page charter covering the business case (increase conversions by 20%), the scope (marketing pages only, not the support portal), the timeline (three months), and the budget (50k). Share it with the sponsor and Product Owner. Ask them to add any missing stakeholders. When sprint planning starts, the team already knows the boundaries.
What to watch next
Watch for scope creep early. The charter sets the boundaries. When someone proposes adding a new feature or extending the timeline, check it against the charter's scope and constraints. If it doesn't fit, it needs a formal change request, not a quiet addition to the backlog.
Key takeaways
- A charter authorizes the project and aligns stakeholders before work begins.
- Keep it to one or two pages—high-level goals, not task details.
- Write it collaboratively. The conversation matters more than the document.
- Reference the charter when scope debates arise during sprint planning.
Frequently asked questions
Who writes the project charter?
Typically the project manager or Scrum Master drafts it, but the sponsor or project initiator formally issues it. Key stakeholders should review and approve it.
When should a charter be created?
Before any detailed planning begins. It should be in place at project kickoff so the team starts with shared understanding.
Can a charter change during the project?
Yes, but changes should be formally approved by the sponsor. If the business case or scope shifts significantly, update the charter rather than letting the plan drift.
Is the charter the same as a product backlog?
No. The charter covers why and what at a high level. The backlog details how to build it, sprint by sprint.
What format should a charter use?
A simple document in Word, Google Docs, or a shared PDF works fine. The format matters less than the content. Some teams embed it in their project management tool as a reference document.