Leadership Framework
How I Write a Project Charter
A charter is the contract a project has with itself. Most projects fail because nobody wrote one, or the one that exists is a slide deck dressed up to look like a contract. This page gives the seven sections of a charter that holds, the done test that tells you it is finished, the version-and-amend discipline that keeps it honest, and a one-page template you can use this week.
Definition
What a charter actually is.
A project charter is the document the project will be measured against from the day it is signed to the day it is closed. It defines what the project is for, what success looks like, what is in scope, what is not, who decides, and how the work will be run. It is the thing the after-action review will compare reality to. If there is no charter, an AAR has nothing to anchor against, and a risk register has no scope to defend.
What a charter is not: a kickoff slide, a status doc, a pitch deck, a wish list, or a Notion page that gets quietly edited every other Tuesday. A charter is signed, dated, and versioned. When it changes, the change is named and dated. When it is silently rewritten, it is not a charter anymore — it is whatever the most recent person to touch it wanted it to say.
The Core Document
The seven sections that hold.
Every charter I have written or relied on uses these seven sections, in this order. Drop any one of them and the document stops doing its job. The first two are load-bearing — if Mission and Objectives are weak, nothing below them recovers.
The seven sections, with Mission and Objectives as load-bearing. The document is not a charter until it is signed, dated, and versioned.
Section 01 · Load-bearing
Mission — one sentence.
Purpose: state what the project is for, in language a stranger can hold in their head.
The mission is one sentence. Not three. Not a paragraph. The military calls this Commander’s Intent, and the discipline is the same: a person two layers removed from the work has to be able to read that sentence and make a reasonable decision on the project’s behalf when nobody is in the room to ask. If you cannot write the mission in one sentence, you do not yet understand what the project is for.
Scenario: a four-person team chartering a customer-feedback program writes a five-sentence mission. After three drafts, the final reads: “Build a defensible, weekly view of customer feedback across the three highest-volume channels and publish it to leadership without manual cleanup.” Everything below the mission gets sharper once the sentence does.
Section 02 · Load-bearing
Objectives with success criteria.
Purpose: convert the mission into things that can be verified.
Each objective is a sentence in the form “we will do X, and we will know we succeeded when Y is observable.” Objectives without success criteria are aspirations. Three to seven is the right range. Fewer than three and the project is too narrow to need a charter; more than seven and you have a program, not a project, and you should split it.
Scenario: the customer-feedback team writes five objectives. Each has a success criterion that names a specific artifact, an observable property of that artifact, and the date by which it has to exist. The objectives are now testable, and the project either meets them or it does not.
Section 03
Scope — in and out.
Purpose: name what is in, and equally name what is out.
Scope is written in two columns. The in-scope column lists what the project will produce; the out-of-scope column lists what stakeholders might reasonably expect but will not get. A charter without an explicit out-of-scope column is an invitation to scope creep, because every assumption a stakeholder makes about what is included becomes a grievance later when it is not.
Scenario: the team puts “competitor sentiment analysis” in the out-of-scope column because two stakeholders had quietly assumed it was in. The conversation that produces that decision takes ten minutes; the conversation it prevents three months later would have taken three days.
Section 04
Stakeholders and decision rights.
Purpose: name who decides, who advises, and who is informed.
A simple RACI is enough — responsible, accountable, consulted, informed — as long as it is filled in by name, not by team. “Marketing” cannot make a decision. A named person can. The single most common cause of stuck projects I have seen is a charter that lists teams instead of names. If you cannot name the people, you have not finished chartering the project.
Scenario: the team puts “Director of Customer Experience” in the accountable column and gets a single name approving the charter. When a scope question comes up four weeks later, the team does not have a meeting to figure out who decides; they email the named person and get an answer by end of day.
Section 05
Phase plan with go / no-go gates.
Purpose: structure the work and name the decision points.
Three to five phases is the right shape for most projects. Each phase has an entry condition, the work it contains, an exit deliverable, and a named gate decision (continue, pause, or retire). Gates are not status reviews; they are decisions. If a phase ends and there is no decision, you do not have a phase plan — you have a Gantt chart pretending to be one.
Scenario: the team writes a four-phase plan: ingest, validate, model, publish. At the end of the validate phase, the team holds a gate review. The data is materially worse than expected. The gate decision is to pause and rescope. Nobody is surprised, because the gate was always there.
Section 06
Risks — pointer to the register.
Purpose: declare that risks are managed somewhere, not pretend the project has none.
The charter does not contain the full risk register, but it names the top three to five risks and points to the live register where they are tracked. The register is the live document; the charter is the contract. The reader of the charter learns what the project is most likely to fail on, and where to look for the current status of those risks. A charter with no risks section is a charter that has not yet been read by anyone with a stake in it.
Scenario: the team lists three top risks — data quality, stakeholder churn, and dependency on a single owner — and links to the risk register. Six weeks later, when the data-quality risk hits, the team is not surprised. They already had a mitigation in the register.
Section 07
Governance and cadence.
Purpose: tell the reader who meets when, who approves what, and how the project communicates.
Governance answers four questions: who runs the project day to day, who approves changes to the charter, what cadence the project reports on, and how decisions are recorded. The cadence section is the one most teams under-write. “Weekly standup, monthly review” is enough, as long as the artifact each meeting produces is named. A meeting that does not produce a named artifact will, over time, stop being attended.
Scenario: the team writes a cadence of weekly fifteen-minute team review, monthly thirty-minute stakeholder review, quarterly go/no-go gate. Each meeting produces a one-paragraph note in the project log. Six months in, the cadence is still being run because everyone knows what each meeting is for.
The Done Test
Five questions before you publish v1.0.
A charter is done when these five questions all have a clean answer. If any answer is “sort of,” the charter is not yet at v1.0.
- Can a person two layers removed from the work read the mission and act on the project’s behalf when nobody is in the room to ask?
- Does every objective name a success criterion that is observable, testable, and dated?
- Is there an out-of-scope column with at least three items in it, and would each of those items have surprised a stakeholder if they had not been named?
- Is every stakeholder role filled by a person’s name, not a team name?
- Does the phase plan name a gate decision — not a status review — at the end of each phase?
Version Discipline
Versions are signed. Amendments are dated. Nothing is silent.
A charter is published as v1.0 on a date with signatures. After that, every change is an amendment. Amendments are numbered (v1.1, v1.2), dated, and accompanied by a one-paragraph note explaining what changed and why. If the change is large enough that the mission or any load-bearing objective moves, that is a v2.0 and triggers a new signature cycle.
The forward-guard against silent edits is simple: the cover page of the charter shows the version, the date, and the last amendment note. If you open the file and the cover page does not match the body of the document, the document has been silently edited and is no longer trustworthy. Treat that as an incident, not as a routine cleanup.
Failure Modes
Where charters go wrong.
Every failure mode I have watched up close shows up as a symptom in the document. Treat the symptom early or the charter will quietly stop being the source of truth.
- The charter is a marketing document. It reads like a pitch — lots of why, no observable success criteria. Fix: rewrite each objective in the “we will do X; we will know it worked when Y” form. If the success criterion is not observable by an outsider, it is not a success criterion.
- The scope section has only an in-scope column. No out-of-scope column means every assumption a stakeholder brings is fair game. Fix: add the out-of-scope column and put at least three items in it that some stakeholder would otherwise have assumed.
- Stakeholders are listed by team, not by name. “Marketing decides” is not a decision rule; it is a delay. Fix: replace each team name with a person’s name. If you cannot name the person, the charter is not yet finished.
- Phases are dated boxes, not gated decisions. The phase plan is a Gantt chart with no decision points. Fix: at the end of each phase, name a gate decision — continue, pause, retire — with the criteria for each.
- The charter is silently edited. The body of the document has moved; the cover page still says v1.0. Fix: revert to the last signed version, then publish the changes as a dated amendment with a one-paragraph note. Silent edits make every other artifact downstream unreliable.
One-Page Template
Copy this and write your v1.0.
This is the cover and skeleton I use. It fits on one page on purpose. If the document needs more than one page to express, the project needs more than one charter — split it.
PROJECT CHARTER Project: ____________________________________________ Version: v1.0 Date: __________ Status: __________ Sponsor: ____________________________________________ Lead: ____________________________________________ 01. MISSION (one sentence) ____________________________________________________________ 02. OBJECTIVES (each with a success criterion) 1. We will _______________________________________________ We will know it worked when _____________________________ 2. We will _______________________________________________ We will know it worked when _____________________________ 3. We will _______________________________________________ We will know it worked when _____________________________ 03. SCOPE IN SCOPE OUT OF SCOPE · __________________________ · __________________________ · __________________________ · __________________________ · __________________________ · __________________________ 04. STAKEHOLDERS (names, not teams) Accountable: __________________ Responsible: __________________ Consulted: __________________ Informed: __________________ 05. PHASE PLAN Phase 1: ______________ Gate decision: __________ by __________ Phase 2: ______________ Gate decision: __________ by __________ Phase 3: ______________ Gate decision: __________ by __________ 06. TOP RISKS (full register at: ______________) · __________________________________________________________ · __________________________________________________________ · __________________________________________________________ 07. GOVERNANCE Cadence: __________ Approver of amendments: __________ SIGNATURES Sponsor: ________________________ Date: __________ Lead: ________________________ Date: __________
Worked Example
See the framework run on a real program.
The clearest live example of this framework on this site is the Workforce Stability program charter, which uses all seven sections and has been carried through twenty-six days of build with no silent edits. Three additional programs on this site were chartered against this same template; each is linked below.
- Workforce Stability — flagship chartered program (Charter v1.0, Build v0.16)
- Veteran Regional Stability Index — charter with KPI coverage ladder and source-failure isolation
- Household Cost Tools (TCBI & TSCI) — two-deliverable charter run as one program
- Veteran Livability Index — charter with explicit clamp and attribution discipline
Next in the Series
The charter declares the work; the risk register defends it.
A charter without a live risk register is a contract you have not stress-tested. The next leadership-framework piece walks the columns, cadence, and escalation rules that turn a risk register from decoration into a working defense.