Guides

How to write a project charter

A project charter is the document that turns an idea into a project. It names the objective, the scope, the money and the person accountable, and someone senior signs it. Everything else you will write — the schedule, the risk register, the status reports — traces back to it. Written well, it takes an afternoon. Written badly, it is the first document in the folder of stale fiction that your stakeholders have stopped reading.

The eight parts of a charter

A charter fits on one to two pages. If yours runs longer, it is a business case or a plan wearing a charter's name. These are the parts, in the order a sponsor reads them.

1.Problem or opportunity
One paragraph, in plain language. Why this project exists and what happens if nothing is done. If you cannot state the pain in a sentence the sponsor would sign, the project is not ready.
2.Objectives and success measures
Two or three outcomes with a number and a date each: "cut invoice cycle time from 9 days to 3 by 31 March". An objective without a measure cannot fail, so it cannot succeed either.
3.Scope, in and out
What the project will produce, and — just as long — what it will not. The out-list is what protects you in month three, when someone remembers a feature they never asked for out loud.
4.Deliverables
The concrete things you will hand over: a migrated system, a trained team, a signed-off procedure. Named so that anyone could check whether the thing exists.
5.Milestones and deadline
Four to seven dated checkpoints between kickoff and the end. More than that on a charter means you are writing a schedule, which comes later.
6.Budget and resources
The money envelope and the people committed, even when the numbers are rough. A charter without a budget authorizes work without limiting it.
7.Sponsor and stakeholders
Who signs, who decides when the sponsor is away, and the handful of people outside the team who can stop the project. Names, not departments.
8.Risks and assumptions
The three to five things that would most likely sink this project, plus what you are assuming to be true. This section is the seed of the risk register you will keep for the rest of the project.

A worked example

A 40-person insurance brokerage moves its paper customer records into a document system. Here is the charter, compressed to the fields that matter.

Problem
Customer records for the brokerage live in four filing cabinets; any answer to a client takes a day.
Objective
All 12,000 records scanned, indexed and searchable within 30 seconds, by 15 December.
In scope
Scanning, indexing, permissions, training. Out of scope: the archive retention policy.
Milestones
Vendor chosen 10 Oct; first 3,000 records verified 7 Nov; cutover 1 Dec; close 15 Dec.
Budget
$18,000, one coordinator at 40 percent.
Sponsor
Operations director. Key stakeholder: the compliance officer.
Top risk
Scan quality below readable for the 1998-2004 paper; assumption: vendor sample passes in week one.

Four mistakes that waste the page

Draft yours from one description

The charter is the first artifact in PMHub360. You describe the project once — what it is, who is involved, the deadline, the money — and the charter comes back drafted, with the objectives, milestones and risks already in the shape the rest of the artifact set will use. The health dashboard is included free with it. PMHub360 is in early access at $29/month when it opens; signing in now reserves your place.

Like every business on NanoCorp, PMHub360 is built and run by AI agents, which is how this guide and the product behind it stay current.