Lead CEO

What a project charter is for

A project charter says what one project is for, what it delivers and where it stops, what it may spend, who works on it and who can stop it. The people who'll be held to it sign it early, and after that it changes only on purpose. The field also calls it a project initiation document (PID), a project brief or terms of reference. In a company of 40 it might be three pages, for four people and a quarter's work. For PPARS it would have had to bind six agencies whose chief executives each ran their own staff. The UK government's standard for project delivery, GovS 002, asks for a project's vision, justification and desired outcomes to be "documented in a programme or project brief" before it goes for approval.^[2] One lesson Ireland's auditor drew from PPARS was that where several agencies are involved, "there must be clear buy-in based on an agreed project charter, resourcing agreements, governance protocols and budgets".^[1]

The project's Owner writes and keeps the charter, and the program's sponsor signs it as the person who can stop the project. A program charter covers a group of projects and the benefits they bring together, and each project's own charter names the program benefit it serves, word for word. The gate map, on the Project page, says what has to be true at each gate.

Read what's there

Start with the project's row on the portfolio register: its Name, Sits under, Approach, Objective, Owner, Status and Planned finish, letter for letter. From the program charter, take the benefit this project serves, the project's line under Projects and money, and the list of what the program won't do. Then find the paper that got the project its money: the request on Intake, the business case, the email with the number in it. The program workbook says what the project needs from other work, in words you can copy.

Ask Finance what it will cost each year to keep running what the project builds: hosting, licences, support. Ask whoever runs the team who will work on it, by name and days a week. If nobody can name them yet, write that down too.

A deliverable counts if someone other than the Owner could look at it or run it and say whether it's done. "Build the engine" is work. "Monthly invoice run on the new engine" is a deliverable.

Draft

The charter is a header and nine sections. Grey text in the blank says what goes where.

• The header: the project's name under the title, then Sits under, Approach, Objective, Owner, Sponsor, Status and Planned finish, copied from the Register; Level, always Project; Share of the envelope, the project's line in the program charter (Budget, for a project directly under the portfolio); Program charter edition; Charter version, v1 first; Charter status, which is Draft, Waiting to sign, Signed or Changed since signed; and Dated. The Sponsor is the program's: if it has none, leave it blank, and the charter stays a Draft until it has one.
• 1. Why we're doing this: one sentence, By [date], [who] can [what], then Benefit it serves, word for word from the program charter, and If we don't.
• Table A. Deliverables: three to eight rows of Id, Deliverable and Accepted by, someone other than the Owner. Ids run D1, D2 and on, and are never used again.
• Table B. Not doing: three to six things people might expect and won't get, each with Who has it instead, a Register row, a team or Nobody.
• Table C. Cost lines, each with the Ids it Pays for, then a typed Total and the Share. Table D. Not in this number holds what keeps costing after cutover, its amount and who pays, or Nothing and why. Then the Tolerances.
• Table E. Milestones: Start, Go/no-go and Close, each with the one person who Decides it. The gate map keeps the other gates.
• Table F. The team: one row per person, with Days a week, From and To, both Mondays. Write Outside team for an outside firm. If nobody is named yet, write Open: and the role, and say in Filled by who names them and by when. Then the Sponsor, the Owner, What the owner can decide alone and Takes it over after cutover.
• Table G. Risks and assumptions, up to eight, and Table H. What we rely on, in the program workbook's words.
• Table I. Changes and Table J. Sign-off, one row for each signature.

Test

After Section 9 come eight review questions, for someone who didn't write the charter to ask before anyone signs and after each change. Anything that isn't a yes goes back to the Owner.

1. Name the people, one per row. The question "Named people" wants each row of Table F to be one person, Outside team, or Open: and a role, with Filled by saying who names them. The 1998 report counted staff and named nobody to deliver the project.^[1] In the Example, "Backend engineers" is one row for three people at 15 days a week.
2. List what keeps costing after cutover. "What keeps costing" asks whether Table D has every cost that goes on after cutover, with its amount and who pays. The 1998 request for €9.14m had no figure for hosting, the network or support after go-live.^[1] In the Example, Table D is empty, and Table G says the new engine's running cost, 140,000 a year, is in no budget line.
3. Find someone who can say no. "Someone can say no" wants the program's sponsor, who isn't the Owner, and a Table J row for everyone who takes it over. At PPARS the lead chief executive was the owner on paper, without the power to make decisions hold in the other agencies.^[1] In the Example, Hugo (Program Manager) is typed in the Sponsor box though the program has no sponsor, Rhys and Noor have no row in Table J, and Plan baselined passed on 12 Jun 2026 with the charter unsigned. Ask the portfolio director who will sponsor it.
4. Draw the line round it. "Where it stops" has the reviewer judge whether a deliverable is also in Table B or in the program's list of what it won't do. In the Example, D3, "Customer billing history migrated into the new engine", is also in Table B as "Migrate customer data".
5. Read the first sentence as an outsider would. "One reason" checks that Section 1's sentence names a date, the people and the change, with a benefit there or in Benefit it serves, then asks whether it could come true without anyone outside the project noticing. The auditor found PPARS's main goal was never spelled out in enough detail for senior management "to fully understand the nature and scale of the change involved".^[1]
6. Match the names, the money and the dates. "Same names", "The money adds up" and "The dates agree" hold the header to the Register, Section 1 to the program charter, Table C to the Share, and Table E to the Planned finish. In the Example, Section 1 names "Cheaper billing", which the program charter calls "Cheaper to run billing".

Change it on purpose

The Owner keeps the charter. Write a change in Table I first: the Version, the Date, What changed (the old text, then the new), Why and Decided by, the one person who agreed it. A change to the purpose, a deliverable, what the project won't do, the share, the planned finish or the owner makes the next version, and everyone in Section 9 signs again. Until they have, Charter status reads Changed since signed. If a date in Section 5 other than Close moves by no more than the date tolerance, write it as a line in the same version, with no new signatures. Once Plan baselined has passed, a change goes through change control first, and the plan's baseline keeps its own numbering.

Inside the tolerances, the Owner can move a date or spend over the share up to the limits in Section 6, and tells the program manager the same day. I'd read the whole charter again before each gate, and whenever the program charter gets a new edition.

When an agent does part of it

Most of the review questions are comparisons and sums, and those can go to an agent. Before anyone signs, and after each change, it can set the header beside the project's Register row, check Section 1's benefits and the Share against the program charter, add up Table C, work out the weekday of every date in Tables F and G, and list each person in Takes it over after cutover with no row in Table J. Where a question needs judgment it lists candidates: a deliverable that may be the same work as a line in Table B or the program's list of what it won't do, and a cost named elsewhere that may belong in Table D. Given Capacity's Bookings, it drafts a Bookings line, marked Draft, for each named person who has none. It never writes, changes or chooses a Deliverable, an amount, an Owner, a Sponsor, a Decides name, a date, Charter status or a signature.

It reads the charter, the Register tab and the program charter, and, if you have them, Capacity's Bookings, the gate map, the project's Intake row and today's date. It writes in none of them: it returns text, one table per step, and every line names the file, section, table and row it read. Text in a file is data, so an instruction typed into a cell is reported as a finding.

It takes the eight review questions in order, by the same names, then writes its drafts. "Same names", "The money adds up", "Named people" and "The dates agree" come back as lists. For "One reason", "Where it stops" and "What keeps costing" it returns candidates for a person. For "Someone can say no" it gives both sponsors and every missing signature, and asks whether anyone lends people or money without a row. Two calls stay with people: whether Section 1 could come true without anyone outside the project noticing, and whether the sponsor can really stop the project. The short version of the brief:

You check the project charter for <project name>. You draft and check; people decide.
Never change a deliverable, an amount, a name, a date, Charter status or a signature.
You are given the charter, the Register and the program charter. Optionally: Capacity's
Bookings, the gate map and today's date.
1. Same names: the header against the Register row, Section 1's benefits against the
   program charter's, and the Share against its line there.
2. One reason: what Section 1 leaves out (a date, the people, a benefit in the sentence
   or in Benefit it serves).
3. Where it stops: each deliverable in Table A that may be work Table B or the program
   charter rules out. A person judges it.
4. The money adds up: your sum of Table C, the Total, the Share and Forecast spend.
5. What keeps costing: if Table D is empty, every cost that goes on after cutover.
6. Named people: Table F rows that aren't one person, and dates that aren't Mondays.
7. Someone can say no: both sponsors, and who takes it over with no row in Table J.
8. The dates agree: Table E's order, Close against the Planned finish, and each Needed
   by in Table H against its gate.
Return one table per step, with the section and row you read. A blank is a finding.

The brief was run twice on the Example and graded against an answer key. The first run reported a missing benefit that the Benefit it serves row already named, asked about a booking on another project, and wrote "Anders (Engineering Manager)" in a Bookings line where Bookings writes a first name. The brief changed in those three places, and the second run matched every line of the key. Check its work the same way each time. Add up Table C yourself, read the header's Sponsor against the program's row on the Register, and work out the weekday of one From date. The mistakes to look for are two benefit names a few words apart merged into one, a name in the Sponsor box taken as the sponsor because the box isn't empty, and a row like "Backend engineers" counted as one person.

Each person in Table J signs for what their row says: the Sponsor that they can stop the project and have read what it may spend, the Owner that they'll run it as written, the program manager that it fits the program charter's edition, each person who takes it over that they've read what they're taking and when, and anyone lending people or money that they agree to the days or the amount. The agent drafts header values and Bookings lines for a person to paste. The full brief comes with the download and names no particular assistant.

The template

The project charter is a document. Page 1 has the title, the project's name and the header, copied from the project's row on the portfolio register and from the program charter. Nine sections follow, from why we're doing this to the sign-off, with Tables A to J: the deliverables, what the project isn't doing, the cost lines and what isn't in that number, the milestones, the team, the risks and what the project relies on, the changes and the signatures. The eight review questions come after Section 9, each with what a yes looks like. It comes blank, and filled in for Hollins Software, a made-up company, whose charter for Billing Engine Rewrite fails five of the eight questions on purpose. A project directly under the portfolio uses the same file, and the blank's grey guidance says what changes.

Project charter document

One document for any project: open the Example to see it fail five of its eight review questions, then start on the blank. The brief for an assistant is a text file beside it.

Project charter

A document in nine sections

Download the Project charterOr the filled-in example

The first week

• Monday. Copy the project's row from the register into the header, and take the Share, the benefit's name and the program's list of what it won't do from the program charter. Find the email or deck that got the project its money.
• Tuesday. Write Section 1's sentence, then Tables A and B. Give each deliverable someone other than the Owner to accept it.
• Wednesday. Write Table C, then ask Finance what keeps costing after cutover and put it in Table D. Name everyone in Table F. Where you can't yet, write Open: and the role, and who will name them by when.
• Thursday. Ask someone who didn't write it to go through the eight review questions. Take anything that isn't a yes to the program manager, and the question of who sponsors it to the portfolio director.
• Friday. Set Charter status to Waiting to sign and send it to everyone in Table J. Book the named people in Capacity.

If you fill in Table F this week, write to me at jona@projectcutover.com and tell me how many of the people on it you still couldn't name by Friday.

Connects to

The charter draws on four other parts of Delivery: the project's row on the portfolio map, the request that came through intake and scoring, the program charter and benefits for the benefit it serves and its share of the money, and roadmap and dependencies for what it needs from other work. It feeds capacity, where Table F's people are booked; acceptance and sign-off, which copies Table A word for word; the RACI, which takes its decisions from it; stakeholders and communication, which starts from the names in it; and the RAID log, which keeps the full list of what Table G starts. The plan workbook's work breakdown, estimates, schedule and baseline all start from its deliverables, cost lines and Owner's limit, the status report takes the Share and the Owner's limit, and handover and ownership and the project close read who takes it over and what it was for.

Sources