How to Write a Project Charter (With Example)

What a Project Charter Actually Is

A project charter is the document that formally authorizes a project and gives the project manager the authority to use organizational resources. It is the first real deliverable in the project lifecycle, produced during Initiation, before any detailed planning begins.

Think of it as the project's birth certificate. It answers four questions a sponsor cares about: Why are we doing this? What does done look like? Who is accountable? What are we agreeing to spend? If those answers are vague, the project starts on sand.

The charter is not a plan. It does not contain a full schedule, a work breakdown structure, or a detailed budget line item by line item. Those come later, during Planning. The charter sets the boundaries and the mandate. Keep it tight, usually one to three pages, written so a busy executive can read it in five minutes and sign it.

Two things make a charter real rather than decorative:

• •A named sponsor signs it. Without a signature, the PM has no authority and no air cover when priorities collide.
• •It defines success in advance. If you cannot state how you will measure success before you start, you will argue about it at the end.

If you want the wider context for where the charter sits among other documents, see our guide on project management deliverables explained.

The Sections Every Charter Needs

Charter templates vary by organization, but a strong one covers the same core sections. Here is the working set, with what each one is for:

• •Project purpose / business case — the problem and the reason this project exists now. One or two sentences. Tie it to a business outcome, not an activity.
• •Objectives and success criteria — specific, measurable statements of what done looks like. "Migrate workloads with zero unplanned downtime over the cutover window" beats "improve infrastructure."
• •Scope (in and out) — what the project will deliver and, just as important, what it explicitly will not. The out-of-scope list is your best defense against scope creep.
• •Key deliverables — the tangible outputs the project hands over.
• •High-level milestones — major checkpoints with target dates, not a full schedule.
• •Budget summary — the funding envelope and any major assumptions behind it.
• •Stakeholders — who is the sponsor, who is the PM, and who are the key parties with influence. Pair this with stakeholder management for project managers to map their competing agendas early.
• •High-level risks and assumptions — the handful of things that could derail the project, named up front.
• •Roles and authority — who decides what, and the limits of the PM's authority.
• •Sign-off — the sponsor's approval.

A practical rule: every line in the charter should be something a stakeholder could later hold you to. If it cannot be measured or owned, it is filler. Cut it.

A Worked Example

Abstract sections are hard to learn from, so here is a short, illustrative charter for a realistic project. This mirrors the kind of scenario you run inside a simulation of a cloud migration, like the one based on an RBC-style Azure migration. The details below are a fictionalized example, not real facts about any company:

Project Purpose: Aging on-premises infrastructure is driving rising maintenance cost and limiting the ability to scale. Migrating priority workloads to the cloud reduces operating cost and improves resilience.

Objectives & Success Criteria:

• •Migrate the agreed workload set within the approved budget envelope.
• •Achieve cutover with no unplanned production downtime outside the approved maintenance windows.
• •Decommission the legacy environment after a stable validation period.

In Scope: Discovery, migration, and validation of the priority workloads; user acceptance testing; legacy decommissioning.

Out of Scope: Application re-architecture, net-new feature development, and non-priority workloads (deferred to a later phase).

Key Milestones: Charter approved, then migration plan baselined, then first wave cutover, then final wave cutover, then closure.

Sponsor: VP, Infrastructure. Project Manager: named, with authority to direct the assigned project team.

Key Risks: Hidden workload dependencies; cutover window contention; vendor capacity. Each gets an owner before kickoff.

Notice what the example does not do: it does not promise a percentage cost saving it cannot defend, and it does not list every server. It draws a clean boundary and defines success in terms anyone can verify. That discipline is the whole point of a charter.

You Write a Charter for Real at the Charter Gate

Reading about a charter and producing one a sponsor will actually sign are different skills. The gap shows up the moment a stakeholder pushes back on your scope or your budget envelope is tighter than the work requires.

On The Eddie System, you write a charter as the first phase gate in every simulation. You run a realistic 27-day IT project as the project manager, moving through Initiation, Planning, Execution, and Closure. The Charter gate is where you commit to purpose, scope, success criteria, and budget before the project is authorized to proceed.

What makes this more than a worksheet:

• •Named stakeholders with competing agendas react to the boundaries you set. Over-promise on scope and it surfaces later as schedule pressure.
• •A live project-health dashboard tracks budget, schedule, scope, risk, and stakeholder sentiment, so weak charter decisions have visible downstream consequences.
• •You produce a real charter deliverable you keep. Alongside the plan, SteerCo deck, and closure documents, it goes into a portfolio you can show employers.

Want to practice on a different shape of project? Build a charter inside a simulation of a Target-style data lake build or an Apple-style NOC build-out. Each forces different scope and stakeholder trade-offs. Browse the full catalog on the explore page, or run the free first day with no account to write your first charter before you commit to a plan.

How to Write a Project Charter Without These Common Mistakes

Most weak charters fail in the same few ways. Watch for these:

• •No measurable success criteria. "Improve the system" cannot be verified. State the target so closure is unambiguous.
• •Empty out-of-scope section. If you do not name what is excluded, every request looks reasonable and scope creep is inevitable.
• •No named sponsor or no signature. An unsigned charter gives the PM no authority. Get the signature before work starts.
• •Treating it as a plan. Cramming a full schedule and detailed budget into the charter makes it slow to approve and quickly out of date. Keep it high level.
• •Ignoring risks and assumptions. Naming three or four real risks up front, each with an owner, is worth more than a polished document that pretends the project is safe.
• •Writing it alone. A charter the sponsor and key stakeholders helped shape gets signed. One you draft in isolation gets rewritten.

The charter is short, but it sets the terms of everything that follows. Get it right and Planning has a foundation. Get it wrong and you spend the rest of the project relitigating decisions you could have settled on page one.

If you are still building toward your first PM role, pairing real charters with other deliverables is how you close the experience gap. See how to get project management experience with no experience.