Project Charter

What a project charter is

A project charter is a short, formal document that authorises a project to begin. In two or three pages it answers the questions a sponsor and a steering group need settled before anyone is asked to commit time or budget: why this project exists, what it will and will not do, who is accountable for it, roughly what it will cost, and how everyone will know whether it succeeded. The charter is the moment a vague intention ("we should do something about our customer data") becomes a recognised, funded piece of work with a name, an owner, and a mandate.

The charter is deliberately brief. It is read by busy senior people who are deciding whether to back the work, not by the team that will execute it day to day. Its value is not in detail but in clarity and authority: by the end of it, a reasonable reader should be able to say what the project is for, who is in charge, what is in scope, and what "done well" looks like — and a named sponsor should have signed to say "yes, proceed".

Why a charter authorises a project

The single most important thing a charter does is confer authority. A project without a charter has no clear answer to two awkward questions: who decided we are doing this, and who is allowed to make calls when things get hard. The charter answers both. It names the sponsor — the senior person who owns the business outcome, holds the budget, and removes obstacles — and it names the project manager or lead, to whom the sponsor delegates day-to-day authority over the work.

That authority matters in practice. It is what lets a project manager pull people from other teams, approve spend within an agreed limit, and say a firm "no" to requests that fall outside the agreed scope. When a dispute arises about priority or direction, the charter is the document people return to: it records what was agreed, by whom, and on what terms. A signed charter is, in effect, the contract between the sponsor and the project — the mandate everything else hangs from.

What a charter contains

A good charter is short but complete. Most contain the following, each in a few lines rather than a few pages:

• Purpose and business justification — why the project is worth doing. State the problem or opportunity, the expected benefit, and what happens if nothing changes. This is the "why" that justifies the spend.
• Objectives — the specific, measurable things the project must achieve. Good objectives are concrete enough to be judged later ("reduce average quote turnaround from 5 days to 1"), not aspirations.
• Scope and out-of-scope — what the project will deliver and, just as importantly, what it deliberately will not. The out-of-scope list is the project manager's first defence against scope creep.
• Key stakeholders and roles — who the sponsor is, who is leading, who must be consulted, and who is affected. Naming roles early prevents the "I thought you were deciding that" confusion later.
• High-level milestones — the handful of dates that matter, enough to show the project is real and bounded, not a full schedule.
• Budget — a rough order-of-magnitude cost and any spending authority delegated to the project manager. The charter does not need a line-by-line budget; it needs a number the sponsor is approving.
• Risks and assumptions — the few things that could derail the project, and the conditions you are taking as given. Surfacing them at the start is far cheaper than discovering them mid-flight.
• Success criteria — how everyone will agree, at the end, whether the project succeeded. Tie these back to the objectives so success is a fact you can check, not an opinion you argue about.
• Sponsor authority and sign-off — the named sponsor and the signature (or recorded approval) that turns the document from a proposal into a mandate.

If you find yourself writing pages of detail under any of these headings, that detail belongs in the plan, not the charter. The charter's discipline is to stay high-level.

Charter versus plan

The charter and the project plan are often confused, but they do different jobs at different times. The charter authorises; the plan organises. The charter comes first and is short: it establishes that the project should happen, who owns it, and roughly what it involves. The implementation plan comes after the charter is approved and is detailed: it breaks the work into tasks, assigns owners and dates, sequences dependencies, and turns the charter's high-level milestones into an actual schedule.

A useful way to hold the distinction: the charter is read by the people deciding whether to fund the project; the plan is read by the people doing it. The charter changes rarely — only when the fundamental mandate changes — while the plan is a living document updated as work progresses. You cannot meaningfully write the plan until the charter has settled what the project is for and what is in scope, which is why a project that jumps straight to planning often ends up replanning once the unasked "why" and "who decides" questions finally surface.

The charter also sits alongside, but differs from, a statement of work. A statement of work is typically a contractual document between a buyer and a supplier that pins down deliverables, acceptance, and commercial terms. A charter is an internal mandate that authorises the project and names its sponsor; the two often coexist, with the charter framing the project and the statement of work governing the supplier relationship inside it.

Common mistakes

• Skipping the charter entirely. Starting work with energy but no mandate feels efficient and usually is not: without a named sponsor and agreed scope, the project drifts, stalls on the first disagreement, or quietly dies when its informal champion moves on.
• Writing the plan instead of the charter. Cramming task lists, Gantt detail, and resource breakdowns into the charter buries the decisions a sponsor actually needs to approve. Keep the detail for the plan.
• No named sponsor. A charter signed by a committee, or by no one in particular, has no real authority. One accountable senior owner is worth more than a long distribution list.
• Vague objectives. "Improve customer experience" cannot be judged at the end. Make objectives measurable so success and failure are both observable.
• No out-of-scope section. Listing only what is in scope invites every adjacent idea to creep in. Naming what is explicitly excluded is one of the most valuable lines in the whole document.
• Treating it as a formality. A charter copied from a template and never genuinely discussed records agreement that does not exist. The conversation that produces the charter matters as much as the document.
• Never revisiting it. If the project's purpose, scope, or budget shift fundamentally, the charter should be updated and re-approved — otherwise people are operating under a mandate that no longer matches reality.