---
{
  "title": "Project charters",
  "summary": "Establish why the project exists and who can direct it.",
  "topic": "delivery",
  "level": "Beginner",
  "updated": "2026-10-12",
  "units": [
    6
  ],
  "aliases": [],
  "sources": [
    {
      "title": "UK Government: Project Delivery Functional Standard",
      "url": "https://www.gov.uk/government/publications/project-delivery-functional-standard"
    }
  ],
  "published": "2026-10-02",
  "editorialVersion": 2
}
---

## The idea

A project charter records purpose, intended outcomes, high-level scope, sponsorship, authority, and major constraints. It gives a common starting point for planning and decision-making. Keep it concise enough to use, while making exclusions and success conditions explicit. A charter is not the entire project plan. It should be updated or revisited when the objective materially changes.

## In practice

A charter authorizes an access-review improvement, identifies the sponsor and affected services, and defines the outcome as verified removal of inappropriate access.

## A common misunderstanding

A vague goal such as “improve security” is hard to accept or measure without an observable outcome.

## Check your understanding

What distinguishes a useful objective?

**Think it through:** It describes an outcome, affected scope, and evidence that would show success.


## Turning an intention into authority

A charter is useful when it makes a proposed security change discussable before people commit substantial resources. Describe the affected service, the problem, and the improvement the organization wants to observe. Name a sponsor who can authorize the effort and a delivery lead who coordinates it. Those roles can be held by different people: paying for work does not automatically make someone responsible for its technical design.

Scope boundaries matter as much as ambitions. A charter for stronger employee authentication might include enrollment and recovery for the workforce identity platform, while excluding customer accounts and a replacement of every application. Write exclusions plainly so they can be challenged early. Initial estimates and assumptions remain estimates; the charter should not present uncertain dates as guarantees.

## A fictional approval conversation

Imagine a small academy whose staff share administrative passwords. Its charter proposes named administrator accounts and stronger authentication, with a pilot before wider rollout. The sponsor agrees to fund the pilot only if support can handle account recovery and the teaching team can still access its tools. This exposes two workstreams that buying an authentication product alone would miss.

A measurable outcome could be that the agreed administrative applications use individual identities and that a tested recovery procedure exists. The team will need evidence from access configuration and a recovery exercise, rather than a slide claiming that security improved. The exact measures should fit the actual environment.

## Draft a one-page mandate

Choose a harmless improvement such as documenting ownership of a training platform. Write its problem, sponsor, boundaries, expected benefit, major assumption, and decision needed next. Ask a classmate to identify one ambiguity that could change the cost. Revise the charter so that a new contributor could explain why the project exists without hearing the original conversation.

## Keep exploring

- [[project-lifecycle]]
- [[project-planning]]
- [[acceptance-criteria]]