---
name: project-charter
description: Use when asked to write a formal project charter — purpose, scope, objectives, deliverables, stakeholders, assumptions, risks, budget, and schedule — as distinct from a collaborative agile chartering session (see agile-charter), which co-creates alignment rather than producing an approved document.
---

# Project Charter

A project charter is a formal document outlining a project's purpose,
scope, objectives, and stakeholders — a foundational reference for
planning, execution, and monitoring, created during project initiation
and approved by the project sponsor and other key stakeholders.

## Key components

- **Purpose** — why the project exists, its benefits, and how it aligns
  with the organization's strategic goals.
- **Scope** — the project's boundaries: what's included, and just as
  importantly, what's explicitly excluded.
- **Objectives** — desired outcomes stated in [[smart-criteria]]
  terms (specific, measurable, achievable, relevant, timely).
- **Deliverables** — the tangible products or services the project will
  actually produce.
- **Stakeholders** — the individuals, groups, and organizations impacted
  by, or able to impact, the project.
- **Assumptions** — factors taken for granted but not validated; naming
  them explicitly means they can be checked and challenged later rather
  than silently driving decisions.
- **Risks** — potential events or circumstances that could negatively
  affect the project (see [[project-management]]'s risk-management
  section for handling these ongoing).
- **Budget** and **Schedule** — the estimated cost and milestone
  timeline.

## Why it matters as a formal document

Unlike an agile chartering *session* (see [[agile-charter]]), a
project charter's value comes partly from being a written, approved
artifact — it's the reference stakeholders and the project team can point
back to when scope, purpose, or authority is later disputed, and the
formal approval signals genuine sponsor commitment rather than informal
buy-in.

## Keeping it current

A project charter is a living reference, not a one-time artifact — it
should be updated as new information becomes available, since a stale
charter (still describing an outdated scope or budget) stops functioning
as the authoritative document it's meant to be.

## Common pitfalls

- **Vague scope with no explicit exclusions** — "what's out of scope" is
  as important as "what's in scope" for preventing later disputes about
  what the project was actually meant to deliver.
- **Objectives that aren't SMART** — see [[smart-criteria]]; an
  unmeasurable objective can't later confirm whether the project actually
  succeeded.
- **A charter approved once and never revisited** — as the project
  evolves, an unchanged charter increasingly misrepresents the actual
  agreed scope/budget/schedule.
- **No named stakeholders, only role titles** — makes it unclear later
  who specifically approved what, or who to escalate a scope question to.

## Learn more

- [[agile-charter]] for the collaborative, session-based counterpart to this formal document.
- [[smart-criteria]] for the objective-quality check a charter's objectives should pass.
- [[statement-of-work]] for the closely related contractual-delivery document a charter often precedes or pairs with.
- [[project-management]] for the ongoing risk/schedule/scope discipline a charter feeds into.