What Is a Project Charter? Definition, Purpose, and Examples

Every project starts as an idea. Someone believes a change is worth making, a team should be formed, or money should be spent. But an idea becomes a project only when someone with authority says so — and says it in writing. That written authorization is the project charter, and it is the document that separates “we are thinking about doing this” from “this project exists.”

This guide explains what a project charter is, why it matters, what it contains, who creates and approves it, how it differs from related documents like the project plan and business case, and what a real charter looks like. If you manage or sponsor projects, this is the one initiation document you should understand completely.

Quick Answer: What Is a Project Charter?

A project charter is a concise, formal document that officially authorizes a project to begin and grants the project manager the authority to use organizational resources to execute it. It captures the project’s purpose, high-level objectives, scope, key stakeholders, summary milestones, summary budget, assumptions, constraints, and high-level risks.

In practice, the charter is the answer to “why does this project exist, and who said it could?” It is written during initiation, signed by the sponsor or approving body, and becomes the reference point for scope management and change control for the rest of the project. It is deliberately high-level — the detailed planning happens afterward in the project plan.

What Is the Definition of a Project Charter?

The project management standard PMBOK defines the charter as the document that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities. More broadly, a charter is a statement of a project’s scope, objectives, and participants — a preliminary delineation of roles and responsibilities that identifies the main stakeholders and defines the project manager’s authority.

Different organizations call it different names — project definition, project statement, or team charter in team-level contexts — but the job is the same. It is the founding contract of the project: the first document created, the one that turns an intention into an authorized endeavor.

The charter is usually short. It explains the project clearly and concisely and refers to more detailed documents for additional information. That brevity is deliberate: a charter that requires a week of reading is not a charter; it is a plan wearing the wrong name.

Why Does a Project Need a Charter?

A charter does four jobs that nothing else in the project can do.

Authorization. The charter formally confirms the project exists and enables it to be prioritized and approved — typically by alignment with organizational strategy or return on investment. Before the charter, the project has no official status. After it, the project is real, and competing demands have to argue around it.

Authority for the project manager. In a matrix environment, where team members report to functional managers, the project manager’s authority is not automatic. The charter assigns it explicitly. It tells the organization that this person leads this project and may use its resources — which is why a signed charter is the project manager’s most important asset in a resource dispute.

Alignment. A charter gives the sponsor, the team, and key stakeholders a shared, high-level understanding of the project’s purpose, scope, and objectives. Everyone reads the same page, so the team is not inventing its own definition of success.

A baseline for control. The charter acts as the reference point for scope management, change control, team meetings, and ongoing governance. When someone proposes to change the project, the first question is always “does this stay within the charter?” If it does not, the change needs formal approval.

There is a research angle too: studies of teams that formalize roles and task structures at the outset have found they tend to show improved performance trajectories. The charter is the simplest form of that formalization — a written agreement about who does what and why.

What Goes Inside a Project Charter?

The exact sections vary, but a strong charter covers the elements below. The rule is high-level: enough to authorize and align, not enough to plan.

Project purpose. The “why.” It should connect the project to the organization’s goals — not “we are building a portal” but “we are building a portal to reduce customer support tickets by automating order status queries.”

High-level objectives. The “what success is.” Strong objectives are measurable: a 25% reduction in onboarding time, a launch by a specific quarter, a budget ceiling. If you cannot measure it, it is not an objective yet.

Scope. What is in and what is out. The out-of-scope list is often the most valuable part of the charter, because it is the first line of defense against scope creep.

Summary milestones and budget. Rough dates for major checkpoints and a rough cost envelope. Detailed scheduling and cost planning happen in the project plan.

Stakeholders and roles. The sponsor, the customer, the project manager, and the key people who approve or depend on the work. It should be explicit that the project manager is authorized to manage the project and its resources.

Assumptions, constraints, and risks. Assumptions are things taken for granted (“the vendor contract will be renewed”), constraints are limits (“the launch must use the existing infrastructure”), and risks are the few high-level things that could derail the project.

Who Creates and Approves the Project Charter?

The sponsor typically initiates the charter — often by delegating its development to the project manager — and the charter is approved by the sponsor, executive leadership, or a steering committee. The person or body that approves the charter is the source of the project manager’s authority.

In practice, the project manager leads the drafting. They work with the sponsor, customers, subject matter experts, the PMO, and other stakeholders to shape the purpose, scope, and constraints, then they facilitate meetings, brainstorming, and conflict resolution to reach agreement. But the authority to sign comes from above the project manager — usually the sponsor, the one who owns the business case and can commit organizational resources.

This separation matters. A charter drafted by a project manager but never signed by anyone with authority is a memo, not a charter. Approval is what turns the document into authorization.

Where Does the Charter Fit in the Project Lifecycle?

The charter is created in the initiating process group, which is the very start of the project — before detailed planning, budgeting work, or execution. In the PMBOK view, developing the charter and identifying stakeholders are the two main actions of initiation.

The sequence is: business case or statement of work defines the opportunity → the charter authorizes the project and the project manager → the project plan turns the charter into detailed execution → the team executes against the plan, using the charter as the scope and governance baseline.

For large, multi-phase projects, a charter can be created for each phase. There may be an initial charter during the scope and seek phase, followed by a planning charter and an execution charter during the build phase. Each phase gets its own authorization because each phase commits new resources and scope.

The charter does not disappear after approval. It stays live as the reference for scope changes and governance — when a proposed change conflicts with the charter, it needs formal approval to move forward.

Project Charter vs Related Documents

People constantly confuse the charter with documents that look similar. Here is the honest distinction.

Charter vs project plan. This is the most common confusion. The charter is one to three pages and authorizes. The plan is comprehensive and guides execution. You cannot write the plan before the charter exists, because the plan is built on the authority and scope the charter establishes.

Charter vs business case. A business case justifies a large investment with financial analysis and ROI; it is often an input to the charter. A charter assumes the decision to proceed and defines how the project will run.

Charter vs project brief. A brief is a summary of the plan, created after approval to keep the team aligned. The charter comes first and is about authorization, not summarization.

A Project Charter Example

Here is a condensed, illustrative example of a marketing project charter (names and figures are examples, not real data).

Project name: Q3 Lead Generation Campaign Refresh Sponsor: VP of Marketing Project manager: Jordan Lee Purpose: Rebuild the quarterly lead generation campaign to reduce cost per qualified lead, which is projected to reach 120% of target by year-end. Objectives: Reduce cost per qualified lead by 20% within two quarters; deliver 15% more SQLs with the same budget; launch the new campaign by July 15. Scope (in): Email nurture flows, landing page refresh, and analytics setup. Out of scope: New CRM implementation, brand redesign, paid media strategy overhaul. Summary milestones: Concept approved June 10; assets finalized July 5; launch July 15. Summary budget: $40,000 including tooling, content production, and testing. Key stakeholders: Marketing director (approver), sales operations lead, analytics lead. Assumptions: Email platform contract renews at current pricing; two marketing contractors are available in Q3. Constraints: Launch must not coincide with the product release window in early July. High-level risks: Limited contractor availability; landing page conversion uncertainty. Approval: Signed by VP of Marketing on May 28.

Notice what the example does not include: no task list, no day-by-day schedule, no detailed cost breakdown. That level of detail belongs to the project plan. The charter gives decision-makers everything they need to say yes, and the project manager everything they need to start.

Project Charter Scenarios: How Charters Play Out in Practice

Scenario 1 — A charter that wins a resource dispute. A project manager needs two engineers who report to a functional manager already running a backlog at 90% capacity. Without a charter, the functional manager can refuse and the project stalls. With a signed charter stating the project manager’s authority and the sponsor’s priority, the resource request escalates on paper, and the sponsor reprioritizes two engineers for six weeks. The project starts on time because the authority was written down before the dispute happened.

Scenario 2 — A charter that stops scope creep with a number. A client contract is worth $150,000 and the scope statement in the charter explicitly lists “data migration” as out of scope. Mid-project, the client asks for migration “as a small extra.” The project manager opens a change request showing the addition at 180 hours and $22,000. The client approves it separately, the baseline stays intact, and the project’s margin is protected — all because a one-line exclusion existed in the charter.

Scenario 3 — The charter that was never signed. A team starts work after the project manager writes a charter but the sponsor never signs it. In week five, a higher-priority initiative appears and the sponsor cancels the project without notice. Because nothing was formally authorized, there is no recorded commitment, no compensation for the five weeks, and no escalation path. The cost of the missing signature is the entire project investment.

Scenario 4 — Phased charters on a big build. A construction program is broken into scope, planning, and execution phases, each with its own charter. The planning-phase charter authorizes $80,000 for design work only. When the design comes in 15% over the estimate, the team cannot start construction — that scope was not authorized yet — so the sponsor reviews the numbers before committing the larger execution budget. The phase gate protects the organization from spending construction money on unapproved designs.

Does Every Project Need a Charter?

Yes — but the form scales. A formal two-page charter with a steering-committee review is overkill for a two-week internal task. A short one-page charter or even a clearly written project kickoff email that states purpose, scope, owner, and approval is still a charter: it still authorizes the work and names the authority.

The risk of skipping a charter entirely is real. Without one, scope decisions default to whoever talks loudest, the project manager has no documented authority to ask for resources, and a change in sponsorship leaves the project with no recorded basis. For projects inside a matrix organization — where team members have other bosses — the charter is close to non-negotiable, because it is the only document that formally assigns the project manager authority over them.

The trade-off is time. Writing and negotiating a charter takes a few hours to a few days, and it requires the sponsor to pay attention. That investment is small compared with the cost of running a project whose authority and scope were never agreed.

Common Mistakes With Project Charters

• Treating the charter as a project plan. Filling a charter with tasks, dependencies, and day-by-day detail makes it unreadable and unapprovable. High-level is a feature, not a flaw.
• Never getting it signed. A charter that is written but not approved grants no authority. If no one above the project manager has signed, the project does not actually exist.
• Writing vague, unmeasurable objectives. “Improve customer satisfaction” authorizes nothing measurable. “Raise the satisfaction score from 72 to 80 by Q4” gives the project a target it can be held to.
• Forgetting the out-of-scope list. A charter with only “what we will do” leaves scope creep an open door. Explicitly naming what you will not do is what protects the project.
• Letting the project manager approve it. The approver must hold authority the project manager does not. Self-approval defeats the purpose.
• Never updating it. A charter is a living document. When major parameters change, the charter should be revised and re-approved, with the revision date recorded.
• Skipping it because “we all know what we’re doing.” Shared understanding is not shared until it is written. The conversation that produces the charter usually reveals disagreements nobody knew existed.

Know This Before You Choose

Before you finalize your charter — and choose the tool you build it in — answer these questions.

• Can you state the project’s purpose in one sentence that connects to an organizational goal?
• Are your objectives measurable, with a number and a date?
• Have you written down what is out of scope, and will stakeholders accept it?
• Is the person who approves the charter actually senior enough to grant the project manager authority?
• Do your summary milestones and budget match reality closely enough to survive scrutiny?
• Have you recorded the assumptions, constraints, and top risks, and do you have owners for them?
• Will the charter be stored somewhere the whole team can find it, with version control?

For teams that want their charter, plan, risks, and milestones to live in the same workspace as the tasks they authorize, Doitify’s project management workspace supports that workflow — you can attach the charter to the project, track milestones, and manage changes beside the work itself. To be transparent: Doitify is our product, which is why we know its capabilities from the inside; for a very small project, a one-page document in a shared drive is often enough.

Conclusion

The project charter is the founding document of project management: the short, high-level authorization that turns an idea into a real project and gives the project manager the authority to run it. It captures purpose, objectives, scope, milestones, budget, stakeholders, assumptions, constraints, and risks — and, critically, it is approved by someone senior enough to grant authority.

Write it early, keep it to one to three pages, get it signed, and use it as the baseline for every scope decision that follows. A project with a clear charter knows why it exists, who runs it, and what it must achieve. A project without one runs on memory and hope — and both run out.