What do you put in a project charter?

A project charter records what the project is for, what it will and will not deliver, who is accountable, the top-level milestones and budget, the assumptions it rests on, and the tolerances inside which the manager can act. It is signed by the sponsor. It is one to three pages, and it is not the plan.

What the charter is for

The charter is the document that authorises the project to exist and defines the boundary around it. Its practical job is to be the thing pointed at six months later when somebody says they thought the project also covered the reporting layer. If the charter cannot settle that argument, it was written as a formality.

The sections

SectionWhat it holds
BackgroundWhy now. Two or three sentences on the problem or driver.
ObjectivesWhat the project delivers, stated so completion is testable
Success criteriaHow anyone will know it worked, and who measures it
In scopeSystems, processes, locations, business units, interfaces
Out of scopeThe same categories, listed explicitly as excluded
DeliverablesThe named outputs handed over at the end
ApproachPhases or delivery model at one paragraph, not a plan
MilestonesFive to eight top-level dates
BudgetApproved amount and its source
RolesSponsor, project manager, key roles, governance forum
AssumptionsWhat is being taken as true and by when it is validated
ConstraintsFixed dates, technology, regulatory, resourcing
DependenciesWhat the project needs from outside it
TolerancesThe variance the manager can absorb before escalating
ApprovalSponsor name, date, version

The three sections that do most of the work

Out of scope. The section most often left short and the one that prevents the most argument. Listing what is excluded is uncomfortable to write, because it makes a boundary explicit that everyone had been assuming differently. That is exactly its value. Specific exclusions — "reporting and analytics against the new data model", "the two overseas sites", "decommissioning of the legacy platform" — do work that "anything not listed above" cannot.

Assumptions. Every project rests on things being treated as true without evidence: the vendor's stated integration capability, business availability for UAT, the environment being ready. Recording them with a validation date means they get tested rather than discovered. Assumptions that fail validation move into the RAID log as risks or issues, which is the mechanism that keeps them from sitting unexamined in a document nobody reopens.

Tolerances. The variance in time, cost and scope inside which the project manager acts without approval. Without them, either everything is escalated or nothing is, and which one happens depends on the individual rather than the governance. They are also what makes RAG thresholds meaningful, since amber and red are usually defined against tolerance — see the status report guide.

What a charter is not

Who signs it, and what signing means

The sponsor signs. Signing means they accept the scope boundary, the budget, the tolerances and the named accountabilities. Where a steering committee exists at approval time, it usually endorses and the sponsor signs. Countersignature by senior user and supplier representatives is common in method-based governance and useful anywhere, because it converts a document circulated for comment into a commitment somebody made.

A charter with no signature and no version date is a draft, whatever it says on the front. It will not settle the scope argument later, because the first response will be that this was never agreed.

When it changes

Rarely, and through change control. Milestone dates moving inside tolerance do not require a charter update; a change to scope, budget or objectives does. Each version is dated and re-approved, and the superseded version is kept — the sequence of charter versions is often the clearest record of how a project's shape changed over its life, and it is what the closure report reads against when judging whether the project delivered what it was authorised to deliver.

Charter and kickoff

The charter is normally approved before kickoff, not written at it. Kickoff is where it is walked through with the team, alongside the RACI, the comms plan and the readiness checklist for what has to be in place before work starts. Those four documents tend to be produced together, which is what the Project Charter & Kickoff Pack (Excel) covers. Where the funding argument still has to be made, that belongs in the Business Case Template (Excel) with its cost and benefit registers and its own assumptions log. Which documents a new PMO needs before either of these is covered in PMO templates.

Questions

How long should a project charter be?

One to three pages for most projects. Length beyond that usually means plan or requirements detail has migrated into it and will need maintaining in two places.

Is a charter the same as a project initiation document?

A PID is broader — it typically absorbs the charter and adds management approach sections such as risk, quality and communication strategy. The charter is the authorisation core of it.

Do agile projects need a charter?

The authorisation question does not disappear. Agile charters carry outcomes and success measures rather than a fixed deliverable list, and scope boundaries at the level of what the team will and will not work on.

Who writes it?

Usually the project manager, with the sponsor. A charter written entirely by the PM and signed without discussion tends not to survive its first scope dispute.

Questions · All 36 templates