Writing a Project Charter your board approves first time

Most project charters are not rejected because they are badly written. They are rejected because someone on the board asks a question the document does not answer, and then there is a second round. That costs two weeks. The sections below are exactly where those questions come from.

What a charter formally does

A charter authorises a project. That is an organisational and quasi-legal act, not a communication exercise. It records that a specific person releases budget and mandate to a specific project manager, within specific limits, for a specific outcome.

Those four words — person, mandate, limits, outcome — are the test. Can you extract all four from your charter within thirty seconds? If not, you have written a project description, not a charter.

PRINCE2 draws sharper lines than PMBOK. What PMBOK calls the charter splits in PRINCE2 into the Project Brief (starting up) and the Project Initiation Documentation (initiation). If you work in an organisation that claims to follow PRINCE2 but wants a single document, say explicitly which of the two you are delivering. Otherwise you will be told halfway through that "there is no PID".

The six sections where it goes wrong

1. Objectives that are not measurable

"Improve customer satisfaction" is not an objective, it is a direction. A board cannot judge whether it was achieved, so the project can never be formally closed.

A usable objective contains a quantity, a baseline, a target and a measurement moment: "NPS among business customers rises from 12 to 25, measured in the Q3 2027 quarterly survey." Without the baseline there is no starting measurement, and you will argue about the reference point afterwards.

Do not know the baseline? Write that in — "baseline measurement to be taken before 1 October; target set thereafter" — rather than inventing a number that later turns out to be wrong.

2. Scope that only says what will happen

Every scope section has two halves. The half everyone writes is "in scope". The half that prevents the arguments is "out of scope".

Explicitly list what people could reasonably expect but will not get. On an EV charging rollout: no fleet replacement, no solar panels, no maintenance after handover. On a system migration: no data older than five years, no report rework, no end-user training.

The rule: if someone could assume it, it belongs under "out of scope". What is not written down is later expected for free.

3. Missing tolerances

This is the section most often left empty in PRINCE2 organisations, and the one most badly missed.

A tolerance is the room within which the project manager may decide alone. Without tolerances every deviation has to go back to the board — or, more realistically, you decide yourself and the board finds out afterwards. Both are bad.

Record at minimum: cost tolerance (say ±10%), time tolerance (say +4 weeks on the end date), and scope tolerance (which deliverables may be dropped under pressure and which absolutely may not). Add what happens when a tolerance is about to be breached: an Exception Report within five working days, followed by a board decision.

4. Stakeholders without a role

A list of names and departments is not a stakeholder analysis. What the board needs is who decides what.

Use a RACI table at deliverable level, not project level. "Who is responsible for the project" always produces the same answer. "Who accepts the delivered grid connection" is the question that causes a delay six months later.

Watch the classic error: exactly one A (accountable) per row. Two A's means nobody decides.

5. Risks with no owner and no response

A risk register containing only descriptions is a worry list. A usable register has five columns per risk: description, probability, impact, response strategy and owner.

The response strategy is one of four: avoid (remove the cause), reduce (lower probability or impact), transfer (insure it or push it to a supplier contractually), or accept (deliberately do nothing and hold a reserve). "Monitor" is not a strategy; it is postponement.

The owner is a person, not a department. "Procurement" never calls back.

6. Assumptions written down as facts

If the brief says "the existing grid connections have sufficient capacity" and nobody has tested that, it is an assumption and belongs in the Assumptions section — not in the background as though it were established.

This is the difference between a charter that protects you later and one that is used against you. Assumptions recorded explicitly and approved shift the risk to the board. Assumptions you quietly wrote down as fact remain yours.

A workable chapter structure

This order works in both PRINCE2 and PMBOK environments and adapts easily to a corporate template:

If your PMO mandates a fixed template, use it. A charter that deviates from house style attracts comments on form instead of substance, and that costs a round.

Before you send it

Run these five checks. They catch the majority of second rounds.

Does every objective carry a number and a measurement moment. Does the scope section contain at least three items under "out of scope". Does every risk name a person. Are tolerances expressed as numbers rather than words like "limited". Is every unverified assumption actually marked as an assumption.

If all five are yes, the questions from the board are likely to be about substance rather than about gaps.