Most PMOs that fail do not fail because of bad templates or the wrong software. They fail because nobody ever wrote down what the office was allowed to decide. When a senior leader wants to skip the intake process, the PMO has no document to point to, so it folds. The charter is what prevents that. It is the single most important artifact you produce when you stand up a project management office, and it is the one most teams skip.
This guide covers what a PMO charter is, exactly what to include, a section-by-section outline you can adapt, and how to scope the authority that turns the office from an advisory function into a steering one.
Key takeaways
- A PMO charter defines the office's purpose, scope, authority, and who it answers to, in one approved document.
- The authority section is the part that matters most: it states which decisions the PMO owns versus advises on.
- An executive sponsor must sign it. An unsigned charter is a wish list, not a mandate.
What is a PMO charter?
A PMO charter is a short, formally approved document that defines a project management office's purpose, scope of services, authority, and relationship to the rest of the organization. It legitimizes the PMO before the business: it states why the office exists, what it will and will not do, which decisions it owns, and who sponsors it. In practice, the charter is what lets the PMO say no to a powerful stakeholder and have that no stick.
Think of it as the constitution for the function. Everything the PMO does afterward, the project intake process, the governance cadence, the portfolio reporting, draws its authority from the charter. Without one, the office runs on the personal credibility of whoever leads it, which evaporates the moment that person leaves or loses a political fight.
What should a PMO charter include?
A PMO charter should include the office's purpose and background, its objectives and success metrics, an explicit scope of services, a clear statement of authority and decision rights, the team structure and roles, the stakeholders it serves, the governance framework it will run, and an executive sponsor's signature. The scope and authority sections do the heavy lifting; the rest provides context and accountability.
Here is what each core section covers and why it earns its place in the document.
| Section | What it states | Why it matters |
|---|---|---|
| Purpose & background | Why the PMO is being created and the problem it solves | Anchors the office to a business need, not a trend |
| Objectives & metrics | What success looks like and how it is measured | Lets the PMO be held accountable and prove value |
| Scope of services | What the PMO does, and explicitly does not do | Prevents scope creep and unrealistic expectations |
| Authority & decision rights | Which decisions the PMO owns versus advises on | The clause that gives the office teeth |
| Roles & structure | The PMO team and who is accountable for what | Clarifies ownership inside the office |
| Stakeholders | Sponsors, customers, and who the PMO serves | Defines the relationships the office manages |
| Governance framework | How projects are approved, reviewed, and closed | Sets the rules of engagement up front |
| Sponsor sign-off | Executive approval and the date | Converts the document from proposal to mandate |
Swipe to see more →
A PMO charter template outline
You do not need a 40-page document. A strong PMO charter fits on two or three pages. Use this outline and write each section in plain language a busy executive will actually read.
1. Purpose and background. Two or three sentences on why the office exists. Name the specific failure it addresses: projects starting before they are funded, no trustworthy portfolio view, chronic resource overcommitment. Tie it to a business consequence leadership already feels.
2. Objectives and success metrics. List three to five objectives and the metric for each. Avoid activity metrics like number of reports produced. Use outcome metrics: percentage of projects delivered on budget, reduction in active projects per person, decisions made at governance reviews. These are the numbers that prove the office works. As the office grows, a PMO maturity model gives you a structured way to assess where it stands today and what capability to build next.
3. Scope of services. A bulleted list of what the PMO will do, and a short matching list of what it will not. The exclusions are as important as the inclusions: stating that the PMO does not manage individual project teams, for example, heads off the most common misunderstanding before it starts.
4. Authority and decision rights. The clause that matters most. Spell out which decisions the PMO owns outright (which projects pass intake, when a project is paused at a gate), which it recommends on, and which sit with leadership. Vague authority here is why most charters fail to change anything. See project portfolio governance for how to structure those decision rights so they hold up.
5. Roles and team structure. Who is in the office and what each is accountable for. Reference the standard breakdown in PMO roles and responsibilities rather than re-deriving it.
6. Stakeholders and sponsor. Name the executive sponsor, the customers the PMO serves, and the key stakeholders it coordinates with.
7. Governance approach. A summary of the cadence: how requests come in, how often the portfolio is reviewed, and how projects are closed. Point to the detailed process rather than reproducing it, and name the reporting the cadence runs on so the charter commits the office to PMO reporting executives will read. If the office will run gate reviews, naming the stage gate review template it will apply keeps the charter's governance clause concrete rather than aspirational.
8. Approval. Signature and date from the executive sponsor.
Who approves a PMO charter?
A PMO charter is approved and signed by an executive sponsor, typically a C-suite leader such as the COO, CFO, or CEO, or a senior VP with budget authority over the portfolio. The seniority of the signer is what gives the charter its weight. A charter approved by a mid-level manager grants only mid-level authority, which is rarely enough for the PMO to overrule a director on which projects proceed.
This is why securing the right sponsor before you write the charter matters more than the document itself. The act of getting a CFO to sign a clause that says the PMO decides which projects pass intake is the moment the office gains real power. The same logic applies at project level, where an engaged project sponsor is what keeps a single initiative accountable. If no executive will sign that clause, you have learned something important: the organization is not yet ready to give the PMO authority, and you should scope the charter to what leadership will actually back.
What is the difference between a PMO charter and a project charter?
A PMO charter establishes the project management office as a standing function, defining its purpose, authority, and scope across the whole portfolio. A project charter authorizes a single project, defining that project's objectives, budget, sponsor, and scope. The PMO charter is created once and revisited periodically; a project charter is created anew for every project, often using a template the PMO itself provides.
The two work together. The PMO charter gives the office the authority to require that every project have a project charter before it starts, and to define what that project charter must contain. One sets up the function; the other governs the individual work that flows through it.
The authority ladder: five levels of PMO decision rights
Most charters fail because the authority section uses one vague verb for everything the office does. The fix is to state a level for each decision, from a five rung ladder, so that "the PMO oversees project approvals" becomes "the PMO decides which requests enter the portfolio; exceptions require the sponsoring executive's written agreement." Same sentence length, completely different document.
Here are the five rungs. Write the ladder into the charter itself so readers can see the vocabulary, then map each decision the office touches onto one of them.
| Level | What the PMO can do | What that looks like in practice |
|---|---|---|
| 1. Informed | Receives the decision after it is made | The office records it and reports it. No influence |
| 2. Consulted | Must be asked before the decision is made | Its view goes on the record, and can be overruled without explanation |
| 3. Recommends | Issues a formal recommendation the decision maker responds to | Overruling is allowed, but must be stated and minuted |
| 4. Decides with escalation | Makes the call, which stands unless escalated to a named person | The default is the PMO's decision. Reversal costs someone effort |
| 5. Decides | Makes the call outright within a defined boundary | Binding, with the boundary written down |
Swipe to see more →
The gap between rungs three and four is where a PMO becomes a real function. At level three the office produces advice that can be ignored silently, which over a year teaches everyone that ignoring it is free. At level four the same decision holds by default, and reversing it requires a named person to spend some of their own credibility. Nothing else in the charter changes behavior as much as moving two or three specific decisions from three to four.
Do not put everything on the top rung. A new PMO that claims level five on funding, resourcing and delivery method at once will be stripped of all three within a quarter. Pick the one or two decisions the organization is most visibly getting wrong, claim level four on those, sit at level two or three on the rest, and come back for more once the first ones have held.
How do you write the authority section so it holds?
Write each authority statement as a decision, a boundary, and an exception route. Vague verbs like support, oversee, facilitate and drive grant nothing, because none of them says what happens when someone disagrees. A clause holds when a reader can tell, from the sentence alone, who wins a dispute and what the loser has to do about it.
The difference is easiest to see side by side. The left column is what most charters actually say. The right column is the same intent, written so it can be enforced.
| Weak wording | Wording that holds |
|---|---|
| The PMO will oversee the project approval process | No project may be resourced before it has passed intake. The PMO decides intake outcomes; a sponsor may escalate to the portfolio board within ten working days |
| The PMO will support resource allocation | The PMO maintains the single allocation record. Assignments not recorded in it are not funded |
| The PMO will promote consistent reporting standards | Projects report monthly in the standard format. Projects that do not report are shown as red until they do |
| The PMO will facilitate governance reviews | The PMO sets the agenda and may hold an item over where the decision pack is incomplete |
| The PMO will work with sponsors to ensure benefits are tracked | Every approved project names a benefit owner in the business case. The PMO reports against those benefits for twelve months after closure |
Swipe to see more →
Notice what the right hand column has in common. Each one names a consequence that happens automatically, without the PMO having to win an argument. That is the design goal. Authority that depends on the office confronting a senior stakeholder in the moment is authority that exists only when the PMO lead is feeling brave, and it disappears the day that person leaves.
One test before you sign anything. Read each clause and ask what would visibly change if it were deleted. If the honest answer is nothing, the clause is describing an activity rather than granting a power, and it belongs in the scope of services section instead.
How does the charter differ for supportive, controlling and directive PMOs?
The type is not a label you choose, it is a consequence of where you sit on the authority ladder. A supportive PMO sits at levels one to three and its charter emphasizes services and standards. A controlling PMO sits at level four on compliance decisions. A directive PMO sits at level five and also owns the project managers themselves, which is a resourcing clause, not a governance one.
| Type | Typical ladder position | What the charter must additionally state |
|---|---|---|
| Supportive | Levels 1 to 3 | Which services are available on request, and that adoption is voluntary |
| Controlling | Level 4 on defined compliance points | Exactly which standards are mandatory, and the consequence of not meeting them |
| Directive | Level 5, plus line management of project managers | That project managers report to the PMO, and how they are assigned and appraised |
Swipe to see more →
The common failure is writing a directive charter for a supportive reality. If the project managers report to business units and the budget sits with functional leaders, no wording gives the office directive authority, and claiming it makes the whole document less credible. Charter the office you can actually staff and fund, and use the amendment route to grow.
The first refusal test: when a charter becomes real
A charter is theoretical until the first time it is used to refuse something a senior person wants. Everything before that moment is agreement in principle, which costs nobody anything. The refusal is the test, and how it goes determines whether the document governs the organization for the next three years or becomes a file nobody opens.
Because the first refusal decides so much, treat it as something to plan rather than something that happens to you. Choose an early, small, unambiguous case: a project that plainly skipped intake, a status report that plainly was not filed, a resource assignment that plainly was not recorded. Small and unambiguous matters more than important. You want a case where the facts are not in dispute and the consequence is mild, so the conversation is about whether the charter applies rather than about whether the PMO is being reasonable.
Two things make that first refusal survivable. The consequence should already be written down, so the office is applying a rule rather than making a judgment about a person. And the sponsor who signed the charter should be told before it happens, not after, because the one guaranteed way to lose is for an executive to hear about the PMO blocking something from the person who was blocked. Get through two or three of these and the charter stops needing to be enforced, because people start routing around the rule by following it, which is the entire objective.
What should not go in a PMO charter?
Keep out anything that changes more often than the charter does. Methodology, templates, role descriptions, tool choices and process detail all belong in documents the PMO can revise without going back to an executive for signature. A charter that contains them either goes stale within months or becomes impossible to update, and both outcomes end with it being ignored.
| Frequently misplaced content | Why it does not belong | Where it goes instead |
|---|---|---|
| Delivery methodology and stage definitions | Changes as the organization learns | The methodology or delivery framework document |
| Templates and report formats | Revised constantly | A template library the charter refers to by name |
| Individual job descriptions | Tied to people and grades, not to the mandate | Role descriptions held with the structure |
| Tool and software choices | Procurement decisions with their own lifecycle | An operating or systems appendix |
| Detailed process steps | Detail buries the two sections that matter | Process documentation, referenced from the charter |
| Aspirational value statements | Unfalsifiable, and they dilute the enforceable clauses | Leave them out entirely |
Swipe to see more →
The discipline here is to reference rather than reproduce. A charter that says the PMO defines and maintains the delivery methodology grants a durable power in one line. A charter that contains the methodology grants the same power and guarantees the document is wrong by next quarter.
How often should a PMO charter be reviewed?
Review it annually, and additionally whenever the sponsor changes, the operating model changes, or the office is asked to take on a materially new responsibility. A sponsor change is the most important trigger and the most commonly missed, because authority in practice flows from the person who signed, and a new executive has agreed to nothing.
Handle amendments as a short, explicit act rather than a rewrite. Add a version and date line, record what changed and who approved it, and keep the previous version. This matters more than it sounds, because the most common charter dispute is not about what the document says today but about when a particular power was granted or removed. A charter with a clean amendment history settles that in a minute. A charter that has been quietly edited in place settles nothing and invites the argument to continue.
The annual review has one question worth more than the rest: which clauses were used this year? Powers that were never exercised are either unnecessary or unenforceable, and both are worth knowing. Powers the office wished it had are the agenda for the amendment. That single question keeps the document connected to how the PMO actually operates, which is the only thing standing between a charter and the drawer it usually ends up in.
Common mistakes that weaken a PMO charter
The most common failure is a charter full of mission statements and empty of authority. It describes a noble purpose, lists services, and never says which decisions the office actually owns. The result reads well and changes nothing. If your draft does not contain a sentence a stakeholder could be annoyed by, it probably grants no real power.
The second mistake is scoping too broad too early. A new PMO that charters itself to standardize everything sets up an expectation it cannot meet and a fight it cannot win. Charter the office to fix the one or two decisions the organization keeps getting wrong, prove it works, then expand the mandate by amending the charter. A focused charter that the business backs beats a sweeping one that it quietly ignores. Deciding which one or two to charter for is easier against the full menu of PMO functions, and the charter itself is step two of the wider sequence in how to set up a PMO. For the broader context on standing up the function the charter authorizes, start with what a project management office actually does and our wider handbook on project portfolio management, which covers the disciplines the charter is granting the office authority over.