A project charter is a short document that formally authorizes a project to exist and gives the project manager the authority to use organizational resources (people, money, equipment) to get the work done. Creating one doesn’t require a specific template or format. It can be as simple as a structured memo or as detailed as a multi-page document with appendices. What matters is that it answers three questions: what is this project, why does it matter, and who has the authority to run it?
What a Project Charter Actually Does
The charter serves two purposes. First, it’s a formal agreement between the project sponsor (the executive or decision-maker funding the work) and the project manager. The sponsor signs off to confirm three things: the project should exist, this person should lead it, and they have authority over the budget, team, and resources needed to deliver it.
Second, the charter acts as a reference point for the entire project. When scope questions come up six weeks in, when a stakeholder asks why certain features aren’t included, or when priorities shift, the charter is the document everyone returns to. A well-written charter prevents arguments about what the project was supposed to accomplish in the first place.
The Essential Sections to Include
There’s no mandatory format, but every effective charter covers the same core information. You can organize these into whatever layout works for your organization.
- Project name and description: A concise summary of what the project will produce. One to three sentences is enough. If you can’t describe the project briefly, the scope probably isn’t clear yet.
- Business case and justification: Why this project matters to the organization. This should connect to a real business need: revenue growth, cost reduction, regulatory compliance, customer retention. Include return on investment if you can quantify it.
- Objectives and success criteria: What “done” looks like, stated in measurable terms. Instead of “improve customer satisfaction,” write “reduce average support ticket resolution time from 48 hours to 24 hours within six months of launch.”
- Scope summary: A high-level description of what’s included and, just as importantly, what’s excluded. You don’t need granular detail here, but the boundaries should be clear enough that someone reading the charter understands what the project will and won’t deliver.
- Summary schedule and milestones: Key dates and phases, not a full project plan. Think major deliverables and decision points: kickoff, design complete, testing begins, launch.
- Budget estimate: A rough order of magnitude for how much the project will cost. This number will get refined later, but the charter should establish a ballpark so the sponsor knows what they’re approving.
- Assumptions and constraints: Assumptions are things you’re treating as true but haven’t verified (e.g., “the vendor will deliver hardware by March 1”). Constraints are fixed boundaries you can’t change (e.g., “the project must launch before the fiscal year ends” or “the team is limited to four developers”).
- Key stakeholders: The people or groups who have a direct interest in the project or influence over its outcomes. List them by name and role so everyone knows who needs to be consulted and informed.
- Project manager and sponsor: Name both explicitly. The charter is what gives the project manager their authority, so this section is non-negotiable.
- Risks: A brief list of the biggest known risks at this stage. You’ll build a full risk register later, but the charter should flag anything that could derail the project before detailed planning begins.
How to Draft the Charter Step by Step
Start by talking to the project sponsor before you write anything. The sponsor typically isn’t the one drafting the charter, but they’re the one who needs to approve it. Your first conversation should clarify what problem the project solves, what outcomes the sponsor expects, and what resources are available. Without this conversation, you’re guessing at the business case.
Next, identify your key stakeholders and gather their input. A stakeholder is anyone affected by the project or who has influence over its direction: end users, department heads, IT teams, compliance officers. Focus on the people with a direct stake rather than trying to interview everyone in the organization. Their input will shape your scope, requirements, and assumptions.
Then write the first draft. Keep it short. Most charters run one to three pages. The goal is clarity, not comprehensiveness. You’re not writing the project plan yet. You’re documenting what the project is, why it exists, and who’s responsible for it. Use plain language that anyone in the organization can understand, not just people familiar with the technical details.
Circulate the draft to your sponsor and key stakeholders for feedback. This review step often reveals misaligned expectations. One stakeholder may assume the project includes a feature the sponsor never intended. Another may flag a constraint nobody mentioned. Better to surface these disagreements now than three months into execution.
Finally, get formal sign-off from the sponsor. The signature (or email approval) is what makes the charter official. Without it, you have a planning document but not an authorized project.
Writing Scope That Prevents Creep
Scope creep, where the project gradually expands beyond its original boundaries, is one of the most common reasons projects run over budget and past deadline. The charter is your first line of defense, but only if the scope section is specific enough.
A vague scope like “redesign the company website” invites interpretation. Every stakeholder will fill in the blanks with their own expectations. A tighter version would be: “Redesign the public-facing marketing website, including the homepage, product pages, and contact form. The project does not include the customer portal, blog migration, or e-commerce functionality.”
Explicitly stating what’s out of scope is just as valuable as stating what’s in scope. When someone later asks, “Can we also redo the blog while we’re at it?” you can point to the charter and have a structured conversation about whether that change warrants a formal scope adjustment rather than letting it slip in unchecked.
That said, the charter captures scope at a high level. You’ll decompose it into detailed requirements and a work breakdown structure during the planning phase. The charter sets the boundaries; the project plan fills in the details within those boundaries.
Adapting the Charter for Agile Projects
If your team uses agile methodology, the charter still matters, but it looks different. Traditional (waterfall) projects define detailed requirements up front and lock them into a sequential plan. Agile projects use lightweight descriptions of required functionality that evolve as the team learns more about what the customer needs.
For an agile charter, keep the business case, objectives, and stakeholder sections the same. But adjust the scope and schedule sections to reflect the iterative nature of agile work. Instead of listing specific deliverables, describe the product vision and the outcomes you’re targeting. Instead of a milestone schedule with fixed dates, outline the cadence of your sprints or iterations and identify when you’ll reassess priorities.
The key difference is flexibility. A waterfall charter locks scope early and treats changes as exceptions. An agile charter acknowledges that requirements will be refined over time, but still sets clear boundaries around budget, timeline, and the overall problem the project is solving. You’re not giving the team a blank check to build whatever they want. You’re authorizing them to solve a specific problem within defined constraints, while giving them room to figure out the best solution as they go.
Who Writes It vs. Who Approves It
In practice, the project manager usually writes the charter even though it’s formally issued by the sponsor. Most sponsors aren’t familiar with the format or the level of detail needed, so the project manager drafts it based on conversations with the sponsor and stakeholders.
The sponsor’s role is to review, refine, and approve. Their approval is what gives the document its weight. A charter that only the project manager has signed is just a planning exercise. The sponsor’s sign-off is what formally commits organizational resources and establishes the project manager’s authority.
Stakeholders contribute input during the drafting process but don’t typically approve the charter. Their buy-in matters, but the authorization comes from the sponsor. If your organization has a project governance board or portfolio management office, they may also need to review the charter before it’s finalized.
Keeping the Charter Useful After Kickoff
A common mistake is filing the charter away once the project starts and never referencing it again. The charter should stay visible throughout the project. When a new stakeholder joins and wants to understand the project’s purpose, hand them the charter. When the team debates whether a requested feature is in scope, check the charter. When the sponsor asks whether the project is still aligned with its original objectives, pull up the charter.
If the project’s direction changes significantly, update the charter. A major budget increase, a shift in objectives, or a change in project manager all warrant a revised version with fresh sponsor approval. Treat the charter as a living agreement, not a one-time formality.