What Is a Project Charter and What Goes In It?

Most charters fail for one of two reasons: they are written as a formality nobody reads, or they are so vague that they cannot settle a disagreement when one arises. A useful charter is short, specific, and revisited.

This guide covers what a charter does, the eight sections it contains, how to write one people use, and the mistakes that make them pointless.

Quick answer: A project charter is a short document that formally authorises a project and records what everyone agreed at the start — the purpose, objectives, scope, key stakeholders, high-level timeline, budget and success criteria. It is signed by whoever is funding the work, and it exists so that months later there is a reference point for what was actually agreed.

What a Project Charter Actually Does

A charter does two things: it gives the project manager formal authority to spend resources and make decisions, and it records the agreement so it can be checked later.

It authorises the project

The charter is the moment a project stops being an idea and becomes work with a budget. It names who is accountable, who is sponsoring it, and what authority the project manager has.

Without that authorisation, a project manager is asking colleagues for favours. With it, they are asking for something the organisation has already committed to, which is a different conversation entirely.

It records what was agreed

Six months into a project, memories diverge. Someone recalls the scope including a feature that was never discussed. Someone else believes the deadline was indicative rather than fixed.

The charter settles this without argument, provided it was specific enough. This is its most practical day-to-day value, and it is why the scope and success criteria sections deserve the most care.

How it differs from a project plan

The charter says what the project is and why it exists. The plan says how it will be delivered — tasks, sequence, dates, dependencies.

The charter is written first, is much shorter, and changes rarely. The plan is written after approval and changes constantly. Confusing them produces either a charter nobody can read or a plan nobody has authorised.

What Goes In a Project Charter

Section Answers Typical length Purpose and business case Why are we doing this? 1 paragraph

Objectives What will be different? 3–5 bullets Success criteria How will we know it worked? 3–5 measurable items Scope What is included? Short list Out of scope What is explicitly excluded? Short list

Stakeholders and roles

Who is involved and accountable?

Table Milestones What are the key dates? 4–6 items Budget and resources What does it cost? 1 paragraph Risks and assumptions What could derail it? 3–5 items Approval Who authorised it? Names and date

The Eight Sections of a Charter

Every charter covers purpose, objectives, scope, stakeholders, milestones, budget, risks and sign-off — with the scope and success criteria sections carrying most of the value.

Purpose and business case

One paragraph explaining the problem and why solving it is worth the investment. Not a description of the solution.

If the business case cannot be stated in a paragraph, the project is probably not clearly understood yet.

Objectives and success criteria

Objectives describe what will be different. Success criteria describe how you will know, in measurable terms.

"Improve the onboarding experience" is an objective. "Reduce time from signup to first completed project from 4 days to 1" is a success criterion. Projects without measurable criteria cannot be evaluated, so they are judged on feeling instead.

Scope and out of scope

List what the project will deliver, and — more importantly — what it will not.

The out-of-scope section prevents more trouble than any other part of the document. It is where you record the adjacent things people will later assume were included.

Stakeholders and roles Name the sponsor, the project manager, the decision-makers and anyone whose approval is required.

Ambiguity here causes delay throughout the project. Knowing who signs off on what, before you need it, avoids the common situation where work is complete but nobody is sure who approves it.

Milestones and timeline

Four to six high-level dates, not a schedule. Kickoff, key deliverables, review points, completion.

Detail belongs in the plan. The charter needs enough for a sponsor to see the shape of the commitment.

Budget and resources

The financial envelope and the people required, at a level sufficient to understand what is being committed.

Risks and assumptions

Three to five significant risks, and the assumptions the plan depends on.

Assumptions matter as much as risks. "Assumes the data migration can use the existing export" is the kind of statement that, when it proves wrong, explains a three-week delay.

Approval and sign-off

Names, roles and date. An actual approval, not an implied one.

Writing a Charter That Gets Used

Keep it to two pages, write the out-of-scope section before the scope section, and get a real sign-off rather than assumed agreement.

Keep it to two pages

A twenty-page charter is read once. Two pages is read at kickoff, referenced during the project, and checked at the end.

Length is the enemy here. Anything that belongs in the plan should be in the plan.

Write the out-of-scope section first

Listing exclusions first forces the conversation that scope definition is supposed to produce.

People discover they had different assumptions, and they discover it in week one rather than week fourteen.

This inversion is a small trick that consistently improves charters.

Get an actual signature

A charter nobody approved is a proposal. The signature — digital or otherwise — is what makes the commitment real and what allows you to refer back to it credibly.

Store the charter where the project lives rather than in a folder. Linking it to the project workspace, as a Doc attached to the project in a tool such as Taskzin, means it stays visible instead of being retrieved only when there is a dispute.

Common Project Charter Mistakes

The three failures are writing the charter after work has started, using unmeasurable success criteria, and never opening it again.

Writing it after the project starts

A charter written retrospectively documents decisions rather than shaping them. Its main value — forcing agreement before commitment — is lost.

Vague success criteria

"Improve efficiency" cannot be assessed. At project close, everyone forms their own view, and the project is judged on impressions.

Make every criterion something you could check with a number or an observation.

Filing it and never returning to it

Review the charter at each major milestone. Are the assumptions still valid? Has scope drifted?

Do the success criteria still make sense?

A charter checked three times during a project is a control. One filed at kickoff is paperwork.