A project charter is the document that formally authorizes a project. It names the sponsor and the project manager, states the objective and how success will be measured, draws the boundary around what is in and out of scope, records the budget and its funding source, and grants the project manager authority to spend that money and draw on those people. It is signed at the moment a project stops being a proposal and becomes a commitment.
Almost every organization already owns a charter template. Very few own charters anyone reads after the second week. The difference is never the format. It comes down to whether the document names exactly one accountable sponsor, states a success condition you could actually measure, and writes down what is deliberately excluded, because those are the three lines people return to when the project is in trouble and the argument starts.
Key takeaways
- The charter authorizes. The business case justifies. If your charter is arguing for the project, it was written too early.
- Two to four pages. A charter long enough to need a contents page has already stopped being a charter.
- One sponsor name, not a committee. The signature line is the whole point of the document.
- The out-of-scope list is the most valuable section and the one most often left blank.
- Success criteria must be measurable by someone other than the project team, or the closure review has nothing to test.
- The charter is a baseline, not a diary. Changes to it go through change control, not through a quiet edit.
- At portfolio level the charter is the handoff artifact: intake produces it, gate one tests it, benefits review scores it.
What is a project charter?
A project charter is a short, formally approved document that authorizes a project to begin, appoints its project manager, and defines its objective, scope boundary, budget, high level schedule, and success criteria. Its defining function is authority: it is the artifact that lets a project manager commit money and people without asking permission for each decision.
The word charter is borrowed deliberately. A charter in the older sense grants a body the right to exist and act within stated limits, and that is exactly what this document does for a project. Everything inside the boundary is delegated. Everything outside it has to come back to the sponsor. Read that way, the sections that look like paperwork start to make sense: the scope boundary and the budget are not descriptions, they are the edges of the delegated authority.
PMI treats the charter as the output of the initiating process group and insists it is issued by someone external to the project, usually the sponsor or a portfolio body, precisely so that authority flows from outside the team rather than the team granting it to itself. PRINCE2 splits the same content across the project brief and the project initiation documentation. The vocabulary differs; the function does not.
What goes in a project charter
A workable charter has eleven sections and a signature block. Anything beyond that belongs in the project plan, which is a different document written later by the project manager rather than issued to them.
| Section | What it states | The test of a good one |
|---|---|---|
| Business need | The problem or opportunity, in two or three sentences | Someone outside the project can restate it correctly |
| Objective | What this project will deliver, singular | It is one sentence, not a list of five ambitions |
| Success criteria | The measures that decide whether it worked | A finance analyst could verify them without asking the team |
| Scope: in | The work, systems, sites and groups included | Specific enough to price |
| Scope: out | What is explicitly excluded | It contains at least one thing somebody expected to be included |
| Key deliverables | The tangible outputs | Nouns you could put on a receipt, not activities |
| Milestones | Four to eight dated checkpoints | Dates tied to decisions, not to the calendar |
| Budget and funding source | The approved amount and which cost center carries it | Finance has already seen the number |
| Roles | Sponsor, project manager, key stakeholders, governance body | Exactly one sponsor, named as a person |
| Assumptions and constraints | What is being taken as true, and what cannot move | Each assumption has an owner who will confirm or kill it |
| High level risks | Three to six risks that could stop the project | They are project-ending risks, not a full register |
| Authorization | Signature, name, role, date | Wet or electronic, but dated and retrievable |
Swipe to see more →
The two sections teams skip are out-of-scope and assumptions, and they are the two the charter exists for. Everything else is recorded somewhere anyway. Nothing else in your organization captures the fact that the finance team assumed the vendor would handle data migration while the vendor assumed you would.
Project charter template, section by section
Here is what to actually write in each section, with the traps that make each one useless.
Business need. Two or three sentences on the problem, in the language of the person paying for it. Not "to implement a unified platform" but "three regional teams close the month on different systems, group reporting takes eleven days, and the audit found two reconciliations nobody owns". If the business need reads like a solution description, the project was scoped before the problem was understood.
Objective. One sentence. If you need the word "and" twice, you have two projects or a program. Deciding which is a governance question rather than a semantic one, and the distinction between the two is set out in program management versus project management.
Success criteria. Three to five, each with a number, a date, and a source. "Month end close reduced from eleven days to five, measured from the finance calendar, by the second close after go live." The source clause matters more than the number. A criterion nobody can independently verify becomes a debate at closure, and the team that spent two years on the project always wins that debate.
Scope in and scope out. Write in-scope by naming systems, sites, entities, processes and user groups. Write out-of-scope by naming the things a reasonable stakeholder would assume are included. Historical data before a stated date, the fourth region, mobile access, integration with the legacy warehouse, retraining of the contact center. If the out-of-scope list is empty or generic, nobody has done the work of asking around.
Deliverables. Outputs, not activities. "Migrated chart of accounts", "signed vendor contract", "trained superuser group of twelve". Activities belong in the plan.
Milestones. Four to eight, each tied to a decision or a handoff rather than to a month boundary. Contract signed, design approved, pilot region live, all regions live, benefits review. If the milestone list is the phases of your methodology, it carries no information.
Budget and funding source. The approved figure, split between capital and operating where that matters, plus which cost center or portfolio pot it comes from. Name the contingency separately and say who releases it. A charter that says "budget to be confirmed" is not a charter, it is a request.
Roles. One sponsor, one project manager, the governance body the project reports to, and the key stakeholders whose agreement is needed. Where decision rights are genuinely contested, the charter is the right place to point at a RACI matrix rather than to relitigate them in prose.
Assumptions and constraints. An assumption is something you are treating as true without proof, and each one needs an owner and a date by which it will be confirmed. A constraint is a fixed limit: a regulatory date, a system freeze, a headcount cap, a currency. Unowned assumptions are how projects fail politely. Once the project is running, these move into the RAID log and get reviewed on a cadence.
High level risks. Three to six things that could stop the project outright, not a risk register. The register comes later and lives in a different document.
Authorization. Name, role, signature, date. One sponsor signature is mandatory. A governance body approval reference is normal. Countersignatures from six functions mean nobody is accountable.
Project charter example
Generic templates are easy to find and hard to learn from. Here is a filled example for a plausible mid-size internal project, kept short on purpose, because the discipline of a charter is compression.
| Section | Content |
|---|---|
| Project | Regional expense system consolidation |
| Business need | Three regions run separate expense systems. Group reporting is manually consolidated each month, takes nine working days, and produced two audit findings last year relating to unreviewed approvals. |
| Objective | Move all three regions onto a single expense platform with one approval policy by the end of Q2. |
| Success criteria | 1. Group expense reporting available on working day three, from the finance calendar, by the second close after go live. 2. Zero unreviewed approvals in the quarterly control sample. 3. Manual consolidation effort reduced by at least 15 days per month, measured from the finance team timesheet. |
| In scope | All three regions. Employee expense claims and corporate card reconciliation. Integration to the general ledger. Policy harmonization. Training for approvers and finance staff. |
| Out of scope | Purchase requisitions and purchase orders. Historical claims before January of the current year. The fourth region, which is under divestment review. Travel booking. Any change to the approval limits themselves. |
| Key deliverables | Harmonized expense policy. Configured platform. General ledger interface in production. Migrated approver hierarchy. Trained superuser group. Decommission plan for the two retired systems. |
| Milestones | Vendor contract signed. Policy approved by the finance leadership team. Region one live. All regions live. Legacy systems decommissioned. Benefits review. |
| Budget | $310,000, of which $240,000 capital and $70,000 operating, from the finance transformation portfolio. Contingency of $30,000 held by the sponsor and released only against a logged change. |
| Sponsor | Group Financial Controller (single named individual) |
| Governance | Reports to the finance transformation steering committee, monthly |
| Assumptions | The fourth region stays out for the full duration (owner: Head of Corporate Development, confirm by end of month one). Vendor delivers the general ledger connector as standard rather than custom (owner: project manager, confirm at contract). Regional finance leads can each release one analyst for two days a week (owner: resource manager, confirm before region one build). |
| Constraints | No production changes during the year end freeze. Data residency requires the European region on European hosting. |
| High level risks | Policy harmonization stalls because one region will not give up a local exception. Analyst availability collides with the year end close. The general ledger connector turns out to need custom development. |
Swipe to see more →
Notice how much work the out-of-scope row is doing. It has already settled four arguments that would otherwise arrive in month three, and one of them (the fourth region) is the difference between a $310,000 project and a $500,000 one.
How to write a project charter
The drafting itself takes a couple of hours. Getting the answers takes longer, and the sequence below is arranged so the slow conversations start first.
- Start from the approved business case, not from a blank template. The need, the benefits and the budget were argued and settled there. Copying them forward keeps the charter consistent with what was actually approved, and any discrepancy between the two is a signal worth chasing before you write another line.
- Get the sponsor named and agreed before anything else. Not a function, not a committee, a person. If nobody will take the line, the project is not ready to charter and no amount of drafting will change that.
- Write the success criteria next, with the person who will be measured on them. Doing this second, while the document is still easy to change, is what stops criteria being reverse engineered later to match whatever the project delivered.
- Draw the scope boundary by interviewing the people who will be surprised. Ask three or four stakeholders what they assume is included. Everything they name that you did not plan to deliver goes in the out-of-scope list, in writing, now.
- Confirm the money and the people separately. Finance confirms the budget and the cost center. The resource manager confirms the named roles are genuinely available for the stated period. A charter approved with unconfirmed resource is the most common cause of a project that starts on paper and not in practice.
- Draft the assumptions with owners and confirmation dates. An assumption without an owner is a wish. This is the section that converts cleanly into the register once delivery starts.
- Take it to the sponsor and the governance body together. Read the out-of-scope list out loud in the room. That single act surfaces more disagreement than the rest of the review combined, and surfacing it in the approval meeting costs an hour instead of a month.
Who writes the project charter and who signs it
The project manager usually drafts it and the sponsor issues it. That split confuses people, because the person writing the document is not the person whose authority it carries. PMI is strict on this point for a reason: authority the team grants itself is not authority.
| Role | Contribution | Signs? |
|---|---|---|
| Project manager | Drafts the document, chases the answers, owns the version | Acknowledges, does not authorize |
| Project sponsor | Supplies the objective and success criteria, defends the scope boundary | Yes, and this is the signature that matters |
| Portfolio or steering body | Confirms the project belongs in the portfolio and the priority is real | Approval recorded in minutes, referenced in the charter |
| Finance | Confirms the budget figure and the funding source | No, but the number is not written until they have seen it |
| Resource manager | Confirms the named roles are actually available | No, but an unconfirmed line here should block approval |
| PMO | Owns the template, checks completeness, files and version-controls it | No, this is assurance rather than authority |
Swipe to see more →
If the person who would sign is genuinely unclear, that is diagnostic rather than administrative, and it usually means the sponsor role itself has never been defined in your organization. What a sponsor is actually accountable for is covered in the project sponsor role.
Project charter versus business case, scope statement, and PMO charter
Four documents get confused with each other, and the confusion is worth clearing up in one paragraph each rather than in a table that repeats what other pages already cover properly.
The business case comes first and answers "should we do this at all", with options, costs, benefits and a recommendation. The charter comes after that question is answered and takes the decision as given. The full comparison, including a section-by-section breakdown, is on the business case in project management.
The scope statement comes after the charter and goes far deeper: detailed deliverables, acceptance criteria, and the work breakdown that flows from them. The charter draws the boundary in a paragraph; the scope statement surveys the land inside it.
The PMO charter is a different animal entirely. It establishes the project management office as a permanent function with its own authority, services and decision rights, and it is written once rather than per project. One of its standing powers is usually to require that every project have a charter and to define what that charter must contain. The structure of that document is covered in the PMO charter.
Where project charters go wrong
The failures repeat across organizations with unusual consistency.
- Written after the project started. Backfilled charters describe what is happening rather than authorizing it, so they carry no constraint and settle no argument.
- Objectives that are really benefits. "Improve customer satisfaction" is a benefit the project contributes to. The objective is the thing the project actually delivers. Confusing the two makes the project accountable for outcomes it cannot control alone.
- An empty out-of-scope section. The single strongest predictor that the project will grow. What that growth looks like, and the controls that catch it, are covered in scope creep.
- A committee in the sponsor field. Shared accountability is no accountability, and it means every escalation goes to a meeting instead of a person.
- Quiet edits. The charter is a baseline. Once approved, changing the scope, budget or dates is a controlled change, routed through the change control process and recorded, not a document update someone makes on a Tuesday.
- Length. Nine pages of methodology boilerplate around one page of content trains everybody not to read it.
- Never referenced again. If the charter is not open on the screen at gate reviews and at closure, it was theater.
The project charter in portfolio governance
Most guidance treats the charter as a project team document. Inside a functioning portfolio it is better understood as the handoff artifact between four governance processes, which is why the PMO cares about it more than the project manager usually does.
Intake produces it. A request arrives, gets scored, gets prioritized, and the ones that survive get chartered. The charter is the last step of intake rather than the first step of delivery, and treating it that way stops projects starting before they have been selected. The funnel that feeds it is described in the project intake process.
Gate one tests it. At the first formal review, the charter is the thing being reviewed: are the assumptions confirmed, is the resource real, has the scope already moved. A gate that reviews a status report instead of the charter is reviewing progress against an unstated plan. The mechanics are in the stage gate process.
Change control measures against it. The charter's scope, budget and milestone lines are the baseline. Every change request is, in effect, a proposal to amend the charter, and the approval thresholds should be set relative to the chartered budget rather than to an arbitrary figure.
Benefits review scores it. At closure, the success criteria written in the charter are the questions the review answers. This is the loop most organizations never close, and it is the reason vague criteria are so expensive: a charter written carelessly in month one makes the closure review unanswerable two years later. How that review is run is set out in the post implementation review.
Seen across all four, the charter stops being paperwork and becomes the only document that follows a project from selection to benefit. That also explains why the PMO, not the project manager, should own the template and the archive. Where these documents live, and who can find them eighteen months later, is part of the wider question of project documentation and portfolio data.
Frequently asked questions
What is the purpose of a project charter?
Its purpose is authorization. The charter formally starts the project, appoints the project manager, and delegates the authority to spend an agreed budget and use agreed people within a stated scope boundary. Everything else in the document exists to define the limits of that delegation, which is why the scope and budget sections carry the most weight.
Who approves a project charter?
The project sponsor signs it, and where a portfolio or steering body exists, that body's approval is recorded alongside. The signer must sit outside the project team, because a charter is authority granted from above rather than claimed from within. Finance confirms the budget figure but does not usually sign.
How long should a project charter be?
Two to four pages for most projects, up to about six for a large program. Length is a reliable warning sign: charters get long when they absorb content that belongs in the project plan or the business case. If yours needs a contents page, the extra material is almost certainly duplicated from another document.
What is the difference between a project charter and a project plan?
The charter authorizes the project and is issued to the project manager. The plan describes how the work will be done and is written by the project manager afterwards. One is short, external and fixed as a baseline; the other is long, internal and updated continuously. Confusing them produces a charter nobody can approve.
What is the difference between a project charter and a scope statement?
The charter states the scope boundary in a paragraph or two, enough to authorize the work. The scope statement elaborates it into detailed deliverables, acceptance criteria and exclusions, and forms the basis of the work breakdown structure. The charter comes first and constrains the scope statement, not the other way around.
Can a project charter be changed?
Yes, but only through change control, and rarely. Because the charter is the baseline that scope, budget and milestone changes are measured against, editing it directly destroys the reference point. The correct route is an approved change request that explicitly amends a named charter section, with the version and approval date recorded.
Do agile projects need a project charter?
Yes, and the reason is funding rather than method. Agile changes how scope is decided inside the boundary, not whether a boundary exists. Agile charters tend to be shorter, replace a fixed deliverable list with a product vision and clear success measures, and state the funding envelope and cadence instead of a milestone plan.
What is a team charter?
A team charter covers how a group will work together: roles, ways of working, communication norms, decision rules and escalation paths. It is about behavior, not authority, and it carries no budget or scope. Some teams write both, and the two documents genuinely do different jobs, so neither replaces the other.
What happens if a project has no charter?
The predictable pattern is disputed scope, an unclear sponsor, and no agreed definition of success at closure. Without a signed boundary, every request looks reasonable and nothing can be refused on principle. The cost usually shows up late, when the project is judged against expectations nobody wrote down at the start.
A charter is worth exactly as much as the conversation it forces. Drafted alone at a desk and circulated for comment, it produces a tidy file and changes nothing. Drafted by asking four stakeholders what they assume is included, then read aloud to a sponsor who has to defend the exclusions, it does the only job the document has: it converts a set of unexamined expectations into one agreed, dated, signed boundary that everyone can be held to later. For where the charter sits in the full sequence from request to benefit, see the project portfolio management process.
Last updated August 2026.