← All postsHow-to

Project charter: the one page that says what you agreed to do

A project charter names the objective, the boundaries, the sponsor and the person authorised to run the work. Its main use comes months later, when people disagree about what was agreed.

How-toP

A project charter is a short document, agreed at the start, stating what a project is meant to achieve, what is inside and outside its scope, who is accountable for it, and who has authority to run it. In a large organisation it is a formal artefact with signatures. In a company of twenty it can be one page — and the one page is worth far more than the formality suggests.

The reason is unglamorous. Four months in, two people will remember the objective differently, and the version that gets acted on will be whichever is asserted more confidently. A charter replaces that with a sentence everybody agreed to when nobody was under pressure.

What a project charter contains

  • The objective in one or two sentences — the outcome, not the activity.
  • Why now: the problem or opportunity, stated concretely enough to be checked later.
  • Success criteria that can be measured, or at least judged, without further argument.
  • What is in scope, and — more usefully — what is explicitly out.
  • The sponsor: the person accountable, who resolves disputes and pays for it.
  • The project lead, and what decisions they may take without asking.
  • Key stakeholders and who has to approve what.
  • High-level budget, timescale and the main constraints.
  • The top three risks, and the assumptions the plan depends on.

The out of scope list is the section that earns its keep. In-scope statements are usually agreed easily because everyone reads their own hopes into them. Naming three or four things the project will not do exposes the disagreement immediately — which is uncomfortable in week one and cheap compared with week twenty.

Authority is the point people skip

A charter that describes the work but not who may decide things produces a project that stops every time a choice appears. State plainly what the project lead can settle alone, what needs the sponsor, and what needs a wider group. It is the difference between a two-hour delay and a two-week one, repeated every time.

The sponsor should be one person. Shared accountability sounds collaborative and functions as an escalation path to nobody, which is the failure that shows up as a project quietly losing momentum without anyone deciding to stop it.

Writing one

  1. Draft the objective first, in one sentence, and rewrite it until it survives being read aloud.
  2. Write the out-of-scope list before the in-scope list — it is more informative and harder to fudge.
  3. Name the sponsor and the lead, and write down the decision rights explicitly.
  4. State success criteria you could actually check in six months.
  5. List the assumptions the plan rests on. Most project failures are an assumption that quietly turned out false.
  6. Circulate the draft and collect disagreement now, when changing it costs nothing.
  7. Keep it to a page for small work, two for large.
  8. Revisit it at each phase boundary and record any change deliberately rather than by drift.

Charter, business case, scope statement

These three get confused, and the distinction is practical rather than academic. The business case argues that the project is worth doing and belongs to the decision about whether to start. The charter authorises it and names who runs it. The scope statement, written later, details the deliverables and acceptance criteria in a way the charter deliberately does not.

For a small company the business case and the charter often merge into one document, which is fine as long as the authorisation half is not lost. What should not merge is the charter and the plan: a charter that includes a task list becomes obsolete the first time the plan changes, and then nobody trusts any of it.

Where to keep it

Ettex Docs suits this: one document, version history kept so the objective as agreed in March is still readable in September, comments for collecting disagreement during the draft, and a single shared link rather than a copy in several inboxes. Duplicating the last charter is usually the fastest way to start the next one.

There is no charter template built in, no approval workflow and no signature capture — agreement is a comment or a reply, not a recorded sign-off. For work where formal authorisation has to be evidenced, that gap is worth knowing about before you rely on it.

Frequently asked

What is a project charter?

A short document agreed at the start that states the objective, scope boundaries, sponsor, project lead, decision rights, success criteria and main risks.

How long should it be?

One page for small projects, two for large ones. Length is not what makes it authoritative.

What is the most valuable section?

The out-of-scope list. It surfaces disagreement in week one rather than week twenty.

How does it differ from a business case?

The business case argues whether to do the project. The charter authorises it and names who runs it and with what authority.

Can the sponsor be a group?

Better not. Shared accountability functions as an escalation path to nobody.

Should it be updated?

Reviewed at phase boundaries, with any change recorded deliberately. A charter that drifts silently is worse than none.

One page: the objective in a sentence, what is explicitly out of scope, one named sponsor, and who may decide what. Then keep the version you all agreed to.

DK
Written by Daria K.

Part of the Ettex team — writing about product, engineering and the future of work.

More posts
Get the best of the Ettex blogProduct news, guides and tips — straight to your inbox, no spam.