Project charter of project [Template & Example]

If you’ve ever kicked off a project without knowing who’s in charge, what you’re trying to achieve, or how much budget you have to work with, you already know what happens: endless meetings, scope creep, and in the worst case, a cancelled project. The Project Charter exists precisely to prevent that scenario. It’s the document that transforms an idea into an official project — one with a name, defined authority, and a clear direction from day one.

In this article you’ll find everything you need to know: what a Project Charter is, what it’s for, what goes in it, how to write one step by step, a real-world example, and a structured template. By the end, you won’t just understand what a Project Charter is — you’ll know how to use one to give your projects a head start.

What Is a Project Charter?

The Project Charter — also known as a Project Initiation Document or Project Mandate — is the document that formally authorizes a project to exist within an organization. In short, it’s the project’s birth certificate.

According to the PMI’s PMBOK Guide, the Project Charter is the document that gives the Project Manager the authority to assign organizational resources to project activities. Without it, the project doesn’t officially exist, and the Project Manager has no formal backing to make decisions. If you want to dive deeper into the PM’s role and responsibilities, check out our guide on what a Project Manager does.

It’s important not to confuse a Project Charter with an executive summary or a detailed project plan. The Charter operates at a high level: it defines the “why” and the “who’s in charge,” without getting into the execution details that belong in the project plan.

What Is the Purpose of a Project Charter?

The purpose of a Project Charter goes well beyond a bureaucratic formality. It serves four strategic functions that shape the success of a project before it even begins.

1. Officially authorizing the project 

Without formal approval, a project is just an informal initiative that can be shut down at any time. The Charter turns the idea into an institutional commitment. Once signed, the organization has decided to invest time and resources in that direction.

2. Giving the Project Manager real authority 

This is one of the most underappreciated aspects of the Charter. It defines the Project Manager’s level of authority: what decisions they can make independently, when they need to escalate, and what resources they can count on. A PM without formal authority is a meeting coordinator, not a project leader.

3. Getting all stakeholders aligned from the start 

Before anyone writes a single line of code or designs a single deliverable, the Charter gets everyone on the same page about the goal, the scope, and expectations. It prevents costly misunderstandings that typically surface mid-project, when it’s too late to fix them without blowing the budget.

4. Connecting the project to organizational strategy

Every project needs to be justified in relation to the company’s goals. The Charter makes that case: why this project, why now, what value it delivers, and how it fits into the broader portfolio or program. Projects without this alignment tend to lose funding when resources get tight.

According to PMI’s Pulse of the Profession Report, projects with formal initiation documentation have a significantly higher success rate than those that kick off without it.

Who Creates and Who Approves the Project Charter?

Confusion about roles around the Project Charter is common, even among experienced professionals. Here’s how responsibilities break down:

• Sponsor: The sponsor is the person with organizational authority who issues the Charter. Formally, the sponsor authorizes the project and takes executive responsibility for ensuring the resources exist to carry it out. They don’t just sign — they’re accountable to leadership if the project fails.
• Senior Leadership or PMO: In organizations with mature portfolio management, Charter approval goes through a committee or PMO that validates strategic alignment before the sponsor signs. This prevents local projects from conflicting with corporate priorities.
• Project Manager: While the PM doesn’t technically “issue” the Charter, they typically lead the writing of it. They translate the sponsor’s expectations into a structured document, identify initial risks, and propose the high-level scope. The sponsor then reviews and signs off.
• Stakeholders: Department heads, internal clients, and other key stakeholders may be involved in validating the Charter. Their input at this stage is critical — they can surface constraints, needs, and dependencies the PM isn’t yet aware of. Getting them involved now prevents vetoes down the road.

Important: Signing the Charter is not optional. An unsigned document is just a proposal. The signature is what turns it into a formal agreement with real consequences.

Project Charter vs. Project Plan vs. Project Scope vs. Business Case

One of the most common mistakes on project teams is using these terms interchangeably. They are not the same thing, and mixing them up creates the wrong expectations right from the start.

What a Project Charter Should Include

An effective Project Charter doesn’t have a set length, but it does need to cover a core set of components. Here’s what each one is and why it matters.

• Purpose and project justification: Explains why the project exists — what problem it solves, what opportunity it captures, or what strategic goal it supports. It should connect directly to the organization’s objectives. Without this justification, any stakeholder can question the investment.
• Measurable project objectives: Objectives should be written in a way that makes it possible to evaluate whether the project succeeded. “Improve customer satisfaction” isn’t enough without a metric: “Increase NPS from 32 to 45 points within six months.” Vague objectives lead to disputes at project close about whether what was promised was actually delivered.
• High-level scope: Defines what’s in scope — and equally important, what’s explicitly out of scope. Scope exclusions are just as valuable as inclusions: they prevent the scope creep that eats budgets and blows deadlines.
• Key deliverables: A list of the products, services, or results the project will produce. You don’t need to detail every task, but you do need to identify the high-impact deliverables the sponsor and stakeholders expect to receive.
• Stakeholders: Identifies the people and groups who have an interest in the project or are affected by it. A full stakeholder analysis isn’t necessary at this stage, but the key players should be documented: sponsor, internal client, involved teams, and anyone with veto power.
• Initial identified risks: Every project has risks that are visible from the start. The Charter should capture the most significant ones, even if only at a preliminary level. Acknowledging risks early doesn’t weaken the project — it shows maturity and sets the team up to address them proactively.
• Estimated budget: A detailed line-item budget isn’t needed here, but an order of magnitude is: the expected investment the sponsor is willing to commit. This number defines the real boundaries of the project and serves as the starting point for detailed financial planning.
• High-level timeline and key milestones: Key dates including the anticipated start, major milestones, and estimated completion. The high-level timeline aligns time expectations between the team and stakeholders before anyone has estimated a single task in detail.
• Success criteria: How will we know the project succeeded? Success criteria go beyond “delivered on time and on budget” — they can include business metrics, quality standards, customer satisfaction levels, or adoption indicators. Defining these now prevents debates at project close.
• Project Manager authority and formal approval: The Charter should explicitly spell out what the Project Manager is authorized to decide on their own, what needs to be escalated to the sponsor, and what resources they can commit to. Finally, the document should carry the signatures of those approving it, with dates.

How to Write a Project Charter: Step by Step

Creating a Project Charter doesn’t take weeks, but it does require a structured process. These six steps will take you from initial information to a signed document.

Step 1: Analyze the Business Case and strategic objectives 

Before writing a single word, review the approved Business Case — or if one doesn’t exist, sit down with the sponsor to understand the project’s rationale. Ask: What problem are we solving? What happens if we don’t do this? How does this fit into the company’s current strategy? The answers to these questions feed directly into the purpose and justification section.

Step 2: Define SMART objectives 

Turn the sponsor’s expectations into objectives that are Specific, Measurable, Achievable, Relevant, and Time-bound. Avoid the trap of writing aspirational objectives that no one can verify. If the sponsor says “we want to be more efficient,” your job is to translate that into something like “reduce order processing time from 48 hours to 24 hours in Q1.”

Step 3: Identify key stakeholders 

Do an initial stakeholder mapping. It doesn’t need to be exhaustive, but it should include anyone with blocking power or whose participation is essential. Talk to them to capture their expectations and constraints before finalizing the scope.

Step 4: Define the preliminary scope 

With the information you’ve gathered, define what’s in scope and what’s out. Be just as explicit about exclusions as you are about inclusions. “This project does not include end-user training” is just as valuable as “this project includes migrating historical data.”

Step 5: Identify initial risks and constraints 

Document the most visible risks at this point: critical dependencies, technology uncertainties, resource constraints, immovable deadlines. You don’t have to solve them now — you just need to acknowledge them. A documented risk can be managed; an ignored one can kill a project.

Step 6: Get formal approval 

Present the Charter draft to the sponsor and relevant stakeholders. Incorporate their feedback, make adjustments where needed, and finalize the document for signatures. The approval meeting matters — it’s not a formality, it’s the official launch of the project.

Project Charter Example (Real-World Case)

To illustrate how this works in practice, here’s a simplified example of an actual Project Charter for a distribution company implementing a new CRM system.

This example shows how a well-written Charter doesn’t need to be more than two pages, yet contains all the information needed to get started with authority. Notice the level of specificity in the objectives and success criteria — there’s no room for ambiguous interpretation.

Project Charter Template

Below is the base structure for a Project Charter you can adapt to any type of project. Fields marked with (*) are required per the PMI standard.

This template can be scaled based on project complexity: for smaller projects, some sections can be simplified, while larger, higher-stakes projects warrant more detailed treatment of risks, stakeholders, and success criteria.

Common Mistakes When Creating a Project Charter

Knowing the most common mistakes is just as valuable as knowing the best practices. Here are the ones that show up most often, even on experienced teams.

• Confusing it with the Project Plan. The most frequent and costly mistake. Some PMs try to pack the Charter with a detailed schedule, a full risk register, or a communications plan. The result is a document so long it takes weeks to approve and is already outdated before it’s signed. The Charter is a starting point, not an execution blueprint.
• Writing it without input from the sponsor or key stakeholders. A Charter written solo by the PM and handed to the sponsor to sign with no prior conversation is a recipe for problems. The document should come out of a real discussion about expectations, constraints, and priorities. What gets agreed to verbally but not put in writing disappears the moment conflict arises.
• Vague or unmeasurable objectives. “Improve operational efficiency” is not an objective — it’s a wish. Without metrics, project close becomes a battleground over whether what was promised was actually delivered. Every objective needs its success indicator defined from day one.
• Failing to define the Project Manager’s authority. A Charter that doesn’t specify how far the PM can go creates constant paralysis: the PM escalates minor decisions to the sponsor, the sponsor becomes a bottleneck, and the project loses momentum. Explicit authority frees the project to move quickly.
• Leaving out scope exclusions. Only documenting what the project includes is not enough. Explicit exclusions are your best defense against scope creep — if it’s not written down that external user training is out of scope, someone will assume it’s in.
• Not updating the Charter when major changes occur. The Charter isn’t sealed forever. When a project undergoes substantial changes — a new sponsor, a significant scope shift, a redistribution of authority — the Charter needs to be updated and re-signed. Operating off an outdated Charter is like navigating with the wrong map.
• Not getting it formally signed. An unsigned Charter is just a draft. The sponsor’s signature is what turns the document into an institutional agreement. Without it, any stakeholder can challenge the PM’s authority or the committed scope.

The Project Charter as the Foundation for Success

The Project Charter isn’t a form you fill out to check a methodology box. It’s the difference between a project that launches with clear direction and one that spends weeks spinning its wheels without anyone having actually decided anything.

A good Charter fits on two pages. It doesn’t need to be exhaustive — it needs to be precise about what matters: why the project exists, what it aims to achieve, who’s in charge, and where the boundaries are. With that foundation in place, the team can operate with real autonomy and the sponsor can delegate with confidence.

The best sign that a Project Charter is well written is that months later, when a dispute arises about scope or the PM’s authority, the document settles the argument. If the team has to guess what the sponsor would have decided, the Charter didn’t do its job.

Use it as the starting point for every new project, share it with all stakeholders before kicking off, and always get it signed. The rest of the project will thank you for it.

Sources and References:

• Pulse of the Profession® 2023 (PMI)
• How to Be an Effective Executive Sponsor (Harvard Business Review)
• Conditions for Project Success (Association for Project Management)
• Project Initiation Document (PID) en PRINCE2
• ISO 21502 sobre dirección de proyectos