Project Charter: The One Document That Says a Project Exists
A business case argues that a project should happen. A project charter says that it will, who is in charge, and what they are authorized to do. Most projects that drift had a weak one.
By Capstera Business Architecture Staff · Updated
11 min read
A project charter is a short document, issued by the project's sponsor, that formally authorizes a project to begin and gives the project manager authority to use organizational resources for it. It records the project's purpose, objectives, high-level scope, key deliverables and milestones, budget, main risks, stakeholders and success criteria, so everyone starts from the same agreement.
Three weeks into a project, a team lead asks the project manager whether the new reporting feature is in scope. The project manager thinks not; the sponsor, asked in a corridor, thinks it might be; the finance analyst who joined last week assumed it was the main point. Nobody is wrong, because nothing was written down that could settle it. A project charter exists for exactly this moment, and for the hundred like it that follow. It is not a plan and it is not a business case. It is the agreement that says what this project is, why it exists, how much it may spend, and who decides.
Key Takeaways
- A project charter authorizes a project and gives the project manager authority. Without one, the project manager's authority rests on goodwill.
- It is short: a few pages. Detail belongs in the project plan, and justification belongs in the business case.
- The sponsor issues and signs it; the project manager usually drafts it.
- Its most important sections are the objectives, the scope boundaries (what is out as well as in) and the success criteria.
- Name the business capability the project changes and its target maturity, so success is measured by the change, not just the deliverables.
- Revisit the charter when the project changes materially. A charter nobody reads after week one cannot settle the arguments it exists to settle.
What Is a Project Charter?
In the vocabulary of the Project Management Institute, the charter is the document that formally authorizes the existence of a project and gives the project manager the authority to apply organizational resources to it.
That definition contains the charter's two jobs. The first is authorization: before the charter, a project is an idea; after it, the organization has committed to doing it, within stated limits. The second is delegation: the charter tells everyone that this person, the project manager, may spend this money, use these people's time and make these decisions on the sponsor's behalf.
Other methods use other names for similar documents. PRINCE2 builds the same agreement through a project brief and, in more detail, the project initiation documentation. Many organizations call it a project mandate, a terms of reference or a statement of work. The names matter less than the content: a short, signed statement of what the project is, why, within what limits, and who decides.
Project Charter vs. Business Case vs. Project Plan
Three documents, three questions. Confusing them produces charters that are too long and plans that are too vague.
The business case comes first and argues whether to invest, comparing options including doing nothing. Once the investment is approved, the charter authorizes the chosen option as a project and sets its boundaries. The project plan then describes in detail how the work will be done, and changes as the work proceeds. A charter that tries to be a plan becomes a long document nobody rereads; a plan that tries to be a charter lacks the sponsor's authority.
| Business case | Project charter | Project plan | |
|---|---|---|---|
| The question | Should we invest, and in which option? | Is this project authorized, and within what limits? | How exactly will we deliver it? |
| When | Before the investment decision | At the start of the project | After the charter; updated throughout |
| Owner | Sponsor | Sponsor (drafted by the project manager) | Project manager |
| Length | As long as the decision needs | A few pages | As detailed as the work needs |
| Changes | Revisited at major decision points | Rarely; a material change needs re-approval | Continually, within the charter's limits |
What Does a Project Charter Include?
A charter covers the same core sections in most organizations. Each one exists to settle a predictable argument before it starts.
| Section | What it records | The argument it prevents |
|---|---|---|
| Purpose | Why the project exists, linked to the business case | "Why are we doing this again?" |
| Objectives | Measurable results the project must achieve | "Is this a success?" |
| Business capability changed | The capability affected, with its current and target maturity | "What will the business be able to do differently?" |
| Scope: in and out | High-level boundaries, including what is explicitly excluded | "Is that in scope?" |
| Key deliverables | The main outputs that will be handed over | "What are we actually producing?" |
| Milestones | A summary schedule of major dates | "When will we see something?" |
| Budget | The approved funding and any contingency | "Can we afford this change?" |
| Main risks and assumptions | What could stop the project and what it depends on | "Why didn't anyone mention that?" |
| Stakeholders | Who is affected and who must be consulted | "Why wasn't my team involved?" |
| Roles and authority | Sponsor, project manager and decision rights, including spending limits | "Who decides?" |
| Success and exit criteria | How the result will be accepted, and when the project closes or stops | "Are we done?" |
| Approval | The sponsor's signature and date | "Was this ever agreed?" |
How to Write a Project Charter
A good charter takes days, not weeks. The work is in the conversations, not the typing.
- Start from the approved business case. Copy its decision, chosen option and benefits; do not re-argue them.
- Agree the objectives with the sponsor in measurable terms. If an objective cannot be checked at closing, rewrite it.
- Name the business capabilities the project changes, with current and target maturity. This is the bridge from deliverables to outcomes.
- Write the scope boundaries, starting with what is out. Exclusions settle more disputes than inclusions.
- List the key deliverables and a handful of milestones. Leave the detailed schedule for the plan.
- State the budget, the contingency and who can release it.
- Record the main risks, assumptions and dependencies, especially on other teams or projects.
- Define roles and decision rights: what the project manager can decide alone, what needs the sponsor, and what needs a steering group.
- Agree how the result will be accepted and when the project ends, including when it should be stopped early.
- Have the sponsor sign it, and share it with everyone named in it.
A Project Charter Example
An illustrative example. The organization and figures are invented, and abbreviated to show the shape of a charter rather than every line.
A mid-sized insurer has approved a business case to improve how claims move from intake to adjudication. The charter for the first project reads, in summary:
Purpose: deliver the first phase of the approved claims modernization business case, option B.
Objectives: claims returned to intake as incomplete fall to half their current share by the end of the project's second quarter after go-live; intake and adjudication work in one shared case record.
Business capabilities changed: Claims Intake, from maturity 2 to 4; Claims Adjudication, from 2 to 3 in this phase.
In scope: property claims, the intake checklist, the shared case record, migration of open property claims. Out of scope: motor claims (phase two), payment changes, broker portal changes.
Key deliverables and milestones: configured intake and case management, migrated open claims, trained intake and adjudication teams; go-live at the end of month eight.
Budget: as approved in the business case for this phase, with a contingency the sponsor alone can release.
Main risks: data quality in open claims; adjusters continuing old workarounds.
Roles: the Chief Claims Officer as sponsor; a named project manager with authority to approve changes within the contingency; a steering group of claims, IT and finance leads meeting monthly.
Acceptance and exit: accepted when property claims run end to end in the new case record for one full month; stopped and returned to the sponsor if data migration fails two rehearsals.
Every later scope question, such as "can we add motor claims now?", has an answer on the page.
Project Charters and Business Architecture
One line in the charter, naming the capability the project changes, connects the project to everything business architecture knows.
When a charter names the business capabilities it changes, the project inherits their context: how important each one is to the strategy, how well it performs today, which value streams depend on it, and which other projects are already changing it. That last point matters most at portfolio level. Two charters claiming to raise the same capability are a conversation to have before both projects start, not a conflict to discover in testing.
It also changes how success is judged. Deliverables can be accepted on the day the project closes; a capability's maturity can be reassessed a few months later. A charter that records both lets the organization tell the difference between a project that was delivered and a project that worked.
Go further
- Business case: how to write one — The document the charter builds on, with a free template.
- Business Case Builder (free) — Records the capabilities, risks and measures a charter needs.
- Project plan — The detailed plan that works within the charter's limits.
- Project management — Phases, methods, and the project manager's role.
Common Project Charter Mistakes
Most weak charters fail in one of a few predictable ways.
- Too long. A charter that runs to thirty pages has become a plan, and nobody will check it against a scope question.
- Objectives that cannot be measured. "Improve efficiency" cannot be judged at closing; "halve the share of claims returned as incomplete" can.
- No exclusions. Without an explicit out-of-scope list, every adjacent request looks reasonable.
- Authority left vague. If the project manager's decision rights and spending limits are not written down, every decision escalates.
- Signed by the wrong person. A charter needs the signature of someone with authority over the budget and the people.
- Filed and forgotten. A charter should be the first document opened when scope is questioned, and revised formally when the project changes materially.
Frequently Asked Questions
What is a project charter?
A short document, issued by the project sponsor, that formally authorizes a project and gives the project manager authority to use organizational resources for it. It records the project's purpose, objectives, scope boundaries, key deliverables, milestones, budget, risks, stakeholders and success criteria.
What is the purpose of a project charter?
To authorize the project, delegate authority to the project manager, and give everyone involved a single agreed statement of what the project is, why it exists, what it may spend and who decides.
Who writes and approves a project charter?
The project manager usually drafts it, and the project sponsor approves and signs it, because the authority it grants belongs to the sponsor.
What is the difference between a project charter and a business case?
A business case argues whether to invest and in which option. A project charter comes after that decision and authorizes the chosen option as a project, setting its scope, budget, roles and success criteria.
What is the difference between a project charter and a project plan?
The charter is a short, signed statement of what the project is and within what limits. The project plan is the detailed description of how the work will be done, and is updated throughout the project within the charter's limits.
What should a project charter include?
Purpose, measurable objectives, the business capabilities changed, scope (in and out), key deliverables, milestones, budget, main risks and assumptions, stakeholders, roles and decision rights, success and exit criteria, and the sponsor's approval.
How long should a project charter be?
Usually a few pages. Enough to settle scope, authority and success questions; detail belongs in the project plan.
Is a project charter the same as a project initiation document?
They serve related purposes. In PRINCE2, the project brief and the more detailed project initiation documentation together establish what a charter establishes, with the initiation documentation also covering how the project will be managed.
Pro Tips
- Write the out-of-scope list first. It is shorter, and it settles more arguments.
- Put decision rights in a small table: who decides what, up to which amount.
- Name the business capability the project changes and its target maturity in one line.
- Include an exit criterion that would stop the project early. It is easier to agree before anyone is invested in continuing.
- Open the charter at every steering meeting where scope is discussed.