What is a project charter?

A project charter is the short document that authorizes a program and aligns everyone on why it exists and what it will and will not do. It names the sponsor and the program manager, states the problem, lists the objectives, draws the line on scope, identifies key stakeholders, and sets milestones, success metrics, and known risks. It is the contract the whole team can point back to when scope starts to drift.

What should a project charter include?

At a minimum: a problem statement that says why the work matters, clear objectives, an explicit scope split into what is in and what is out, the sponsor and program manager, the key stakeholders, the major milestones, the metrics that define success, and the known risks. The out-of-scope list is the part teams skip and later regret, because it is what stops scope creep before it starts.

What is the difference between a charter and a project plan?

A charter says why the program exists and what it is allowed to do. A plan says how and when it gets done. The charter comes first and stays short, so it can authorize the work and align stakeholders before a detailed plan is built. The plan is a living, detailed schedule of tasks, owners, and dates that flows from the boundaries the charter set.

Who writes the project charter?

Usually the program or project manager drafts it, then the sponsor reviews and approves it. The act of drafting forces the hard conversations early: what problem are we actually solving, who owns it, and what are we explicitly not doing. Getting the sponsor to sign off on those answers is what gives the charter its authority later.

Project Charter Generator

Draft the document that authorizes your program and aligns everyone before the work starts. Fill in the form on the left and the charter builds on the right, then copy it or print to PDF. Everything saves in your browser. No signup.

Project name

Sponsor

Program Manager

Problem statement

Objectives

Scope: in

Scope: out

Key stakeholders

Milestones

Success metrics

Risks

How to write a project charter

A charter exists to authorize a program and align everyone before the first line of work. It answers four questions in one short document: why are we doing this, what will it and will it not include, who owns it, and how will we know it worked. If the team cannot agree on those answers, the charter has done its job by surfacing the disagreement early, while it is still cheap to fix.

Keep it short and concrete. The problem statement should make the cost of doing nothing obvious. The objectives should be few and measurable. The out-of-scope list deserves as much care as the in-scope list, because it is the line you point to when a stakeholder tries to bolt on "just one more thing." Get the sponsor to approve it, and the charter becomes the reference everyone returns to when the program is under pressure.

Common mistakes to avoid

Vague objectives. "Improve the platform" is not an objective. "Cut payment latency to under 200ms" is.
Skipping the out-of-scope list. Naming what you will not do is how you stop scope creep before it starts.
No named sponsor. A charter without an accountable sponsor has no authority when a hard call is needed.
Writing it once and filing it. Revisit the charter at major phase gates so it keeps matching the program you are actually running.

For more on framing and running programs, see the Insights notes on scope, stakeholders, and governance.

Built by Arsenii Samoilov, a Senior Technical Program Manager with 19+ years at Intuit, Atlassian, Adobe, Salesforce, Roku, and Apple. If your team needs help standing up program governance, get in touch.

Read the Insights →