Skip to content

Project Charter

At a glance

  • Purpose: Formally authorise a project, name who is accountable, and bound what it will do — in one or two pages.
  • Use it when: At initiation, before planning. Without it, nobody has the authority to spend the project's first day.
  • Owner: The sponsor authorises it; the project manager drafts and maintains it.
  • Related: Module 02 · Lab 01

A charter formally authorises a project and bounds it. It is deliberately short — one to two pages. If it is longer, it has become a plan.

Copy the skeleton below and replace the bracketed text.

Charter skeleton

# Project Charter — [Project name]

| | |
| --- | --- |
| **Date** | [YYYY-MM-DD] |
| **Version** | [0.1] |
| **Sponsor** | [Name, role] |
| **Project manager** | [Name] |

## 1. Purpose

[Two or three sentences: why this project exists and what problem it solves. Write it so
someone outside the project understands the point.]

## 2. Success criteria

[Observable, testable statements. Avoid "users are happy"; prefer "a student can publish an
event without staff assistance".]

- [ ] [Criterion 1]
- [ ] [Criterion 2]
- [ ] [Criterion 3]

## 3. Scope

**In scope (first release):**

- [Item]
- [Item]

**Out of scope:**

| Excluded | Reason |
| --- | --- |
| [Item] | [Why it is excluded from this release] |

Explicit exclusions prevent the most common source of disputes.

## 4. Key deliverables

| Deliverable | Description | Owner |
| --- | --- | --- |
| [Name] | [What it is] | [Who] |

## 5. Constraints

[Fixed facts the project cannot change — deadlines, required integrations, budget ceiling,
available people.]

- [Constraint]

## 6. Assumptions

[Things believed true but not confirmed. Flag any that would invalidate the plan if false.]

| Assumption | Risk if false |
| --- | --- |
| [Assumption] | [Consequence] |

## 7. Milestones

| Milestone | Target date | Definition of done |
| --- | --- | --- |
| [Name] | [YYYY-MM-DD] | [What must be true] |

## 8. Governance and authority

- **Sponsor:** [Name] — accountable for the business outcome.
- **Approves scope and budget changes:** [Name or role]
- **Project manager authority:** [What the PM may decide alone]
- **Escalation path:** [Who is contacted, and when]

## 9. Budget summary

[Total budget, or an explicit statement of how it will be determined.]

## 10. Initial risks

| Risk | Impact if it occurs |
| --- | --- |
| [Risk] | [Impact] |

Develop these fully in the risk register.

## 11. Approval

| Role | Name | Date |
| --- | --- | --- |
| Sponsor | [Name] | [Date] |
| Project manager | [Name] | [Date] |

How to use this template

  1. Write section 1 (purpose) in language someone outside the project understands. If it needs technical vocabulary, the purpose is not yet clear.
  2. Make every success criterion testable. "A student can publish an event without staff assistance" can be observed; "users are happy" cannot.
  3. Populate out of scope before the in-scope list. Exclusions are the decisions you have actually made, and an empty table means none were.
  4. State authority explicitly — who approves a change, and what the project manager may decide alone. Most later conflicts trace back to this section being vague or absent.
  5. Keep it to one or two pages and stop. If it is longer than that, you have written a plan, and the charter's authority will be diluted.
  6. Treat an approved charter as a baseline: changes to scope, budget, or authority go through the change request process.

Field descriptions

Section What goes in it Watch out for
Purpose Why the project exists and what problem it solves Restating the solution
Success criteria Observable, testable statements Adjectives that cannot be observed
Scope In-scope deliverables and exclusions An empty exclusions table
Key deliverables Named outputs and their owners Deliverables nobody owns
Constraints Fixed facts: dates, integrations, ceiling, people Constraints invented by the team
Assumptions Beliefs not yet confirmed, with consequences if false Assumptions presented as facts
Milestones Target dates and what must be true at each Milestones with no definition of done
Governance Sponsor, change authority, PM authority, escalation path "Escalate as necessary"
Budget Total, or how it will be determined A figure with no included or excluded costs
Initial risks The few risks that could stop the project A charter turned into a risk register

Worked example

From Lab 01, on the university learning management system — invented criteria for teaching. Two versions of the same section:

Weak success criterion Workable version
"Improve the student experience" "A student can self-enrol on a module without staff intervention, verified with 20 students on the live system"
"A modern, reliable platform" "A published announcement reaches all enrolled students within 5 minutes, measured on the production instance"
"Reduce administrative effort" "The records office reduces manual enrolment corrections from the observed baseline to under 20 per term"

The right-hand column is not more ambitious — it is verifiable, which is what makes it usable at closure. Note also the third row: it names an existing baseline. Where no baseline exists, say so in the charter and make establishing one part of the work.

Common mistakes

  • Keep it short. A charter that nobody reads cannot authorise anything.
  • Out of scope is mandatory. An empty exclusions table means you have not made decisions.
  • Separate constraints from assumptions. Constraints are fixed; assumptions can be tested and may turn out false.
  • Define authority. Ambiguity about who can approve changes causes real conflict later.
  • Success criteria nobody can test. This is the most common defect, and it surfaces at closure when acceptance must be argued rather than demonstrated.
  • A charter written after planning. If it is reverse-engineered from the plan, it authorises what has already been decided rather than what was agreed.
  • Sign-off without the sponsor reading it. Authority that was never exercised is not authority.