Microsoft Project Online retires September 30, 2026, migrate to a modern platform before it's too late.Start migration
Back to BlogWriting a PMO Charter That Won't Be Ignored
PMO

Writing a PMO Charter That Won't Be Ignored

A PMO charter that executives reference every quarter names specific outcomes, defined authority, and a review schedule. Here's how to write one that lasts.

Onplana TeamJune 19, 202611 min read

Most PMO charters are written once, presented at an executive kickoff, and filed in a SharePoint folder that nobody opens again. When a PM director asks for them two years later to settle a governance dispute, the document either can't be found or describes an organization that no longer exists.

The problem is not that PMOs don't understand what they're for. It's that the charter they write describes a function in aspirational terms that don't survive the first time a skeptical VP tells a project team to ignore the PMO's scheduling standards because "we're moving fast." Without a specific problem statement, defined authority, and measurable outcomes, the PMO charter is a wish list. The wish list does not have teeth.

A PMO charter that works is not a template filled out carefully. It is a negotiated document that names what the PMO can and cannot do, backed by an executive signature that makes those boundaries real. That is a harder document to write, and a much more useful one.

TL;DR. A PMO charter that survives contact with a skeptical organization has three non-negotiable elements: a specific mandate (not "improve project visibility" but "reduce schedule overruns from 28% average to under 12% within 18 months"), authority that has been tested against who can push back on it and still hold, and measurable outcomes with a review cadence. Every PMO charter template you find online gives you scope, mandate summary, and org chart. The three elements that make a charter functional are the ones most templates skip entirely.

Why most PMO charters get filed and ignored

The default failure mode is that the charter is written by the team that just established the PMO, for the presentation that sells the PMO's existence to leadership. That audience, in that moment, has already agreed the PMO is a good idea. The charter is therefore optimized for a room that doesn't need convincing, not for the rooms the PMO will face two years later.

Three structural patterns create this problem.

Aspirational language that can't be challenged. Phrases like "improve project visibility," "increase delivery predictability," and "build PMO maturity" are safe because nobody disagrees with them. They are also useless because nobody can measure whether the PMO is achieving them or not. An improvement in project visibility from whose perspective, measured how, compared to what baseline? When the PMO can't answer that question, neither can its sponsor at the next budget cycle.

Authority that was assumed rather than negotiated. Many PMO charters describe what the PMO "will require" of project teams without specifying who authorized that requirement or what happens when a project team declines. The charter reads as though the PMO has enforcement authority; in practice, it has advisory authority and everyone knows it. When the first conflict arrives, the PMO loses the negotiation because the charter's claimed authority was never confirmed by anyone with actual power.

No review mechanism. Organizational context shifts faster than most PMO charters anticipate. The sponsor changes. The company reorgs. Three of the PMO's intended functions get absorbed by another team. A charter that was accurate at launch becomes actively misleading by year two. Without a scheduled review, the document becomes a liability rather than a reference.

What a PMO charter is (and is not)

Before writing the charter, it helps to be clear about what it is not.

A PMO charter is not a project charter. A project charter authorizes a specific project with defined scope, a named sponsor, and a closing date. A PMO charter authorizes a standing function that operates indefinitely. The confusion is common and consequential: teams that write PMO charters using project charter templates end up with a document that treats the PMO as a temporary initiative with a go-live date, which sets the wrong expectations with the organization.

A PMO charter is not a service catalog. Many PMOs document their charter as a list of services: "the PMO provides project scheduling support, stakeholder reporting, and risk management templates." This describes what the PMO does but not what it is there to achieve or what authority it holds. A services list is the operations section of a charter; it is not a substitute for the charter itself.

A PMO charter is not a governance policy. PMOs often mistake the policies they enforce for the charter that grants them the standing to enforce those policies. The governance policy says "all projects above $500K require a signed project charter before kickoff." The PMO charter says "the PMO has authority to hold project funding pending compliance with governance policies." The second document makes the first enforceable.

The PMO charter is the founding document of the function: what it exists to solve, what it can do about it, and how success will be defined and reviewed.

The three elements every PMO charter must include

Most PMO charter templates have six to eight sections. Three of them actually matter when the charter gets tested in practice.

The diagram below shows how these three elements connect. Skip any one of them and the structure collapses under pressure.

Three mandatory elements of a PMO charter Three elements every PMO charter must include MANDATE The specific problem the PMO exists to solve With a number, not a vibe AUTHORITY What the PMO can enforce versus only advise on Exec-signed, not assumed OUTCOMES Measurable targets with a review cadence Reviewed annually at minimum Skip any element and the charter cannot hold when contested

Mandate: The specific problem the PMO exists to solve, written as a problem statement, not a mission statement. "Improve project outcomes across the organization" is a mission statement. "Reduce average schedule variance from 28% to under 12% within 18 months by standardizing scheduling methods and milestone tracking across all projects above $250K" is a mandate.

Authority: What the PMO can enforce versus what it can only recommend. This is the section most charters skip, because defining authority requires the executive to actually commit to something. Will the PMO have a sign-off gate on large projects before funding is released? Can the PMO require a PM to restart a schedule that fails the health check? Or is the PMO advisory only? Name it. Vagueness here costs the PMO every governance dispute it will ever be in.

Outcomes: Specific, measurable targets with defined review dates. Not aspirational language. Outcomes are what the PMO's sponsor will use to judge the function in twelve months. If the PMO can't name them clearly, the sponsor will invent their own criteria later, which are rarely the criteria the PMO was optimizing for.

Writing the outcomes section

The outcomes section is where most PMO charters soften. A charter that was specific in the mandate section becomes vague when it has to commit to being measured. This is understandable: committing to specific numbers is risky. It is also necessary. A PMO that can't name what it will be measured on can't justify its budget at the end of year one.

The test for an outcomes section is simple: could an outsider reading this document determine whether the PMO has succeeded or failed at the end of its first year? If the answer is no, the outcomes section is not finished.

Useful outcome patterns for PMO charters:

  • Delivery predictability: "90% of active projects report milestone status within 5% of planned dates, measured quarterly." Baseline the current number at charter signing. If it is 60%, the target should be achievable but not trivial.
  • Portfolio visibility: "100% of projects above $500K have a named PM, an active schedule with at least monthly updates, and a current status report in the PMO system, measured monthly." A visibility outcome gives the PMO a concrete audit function.
  • Governance compliance: "80% of projects above $1M go through the defined gate review process before phase transition, measured at each gate." This is auditable. It does not require the PMO to judge project quality; it only requires it to track whether the process ran.
  • Stakeholder satisfaction: "PMO satisfaction score from project sponsors averages above 3.8 out of 5, measured via annual survey." This is a lagging indicator and harder to act on, but it signals that the PMO is serving rather than just governing.

Pick two to three outcomes for the first charter. More than four means the PMO will be managing metrics instead of managing projects. Each outcome should have a baseline measurement at the time of signing, a target, and a date by which the review will happen.

The review cadence of the outcomes is as important as the outcomes themselves. Quarterly check-ins against the metrics let the PMO and sponsor course-correct before the annual review. Without them, year-one reviews are surprise parties.

Defining PMO authority without starting a turf war

The authority section is the conversation most PMO leaders avoid. Defining what the PMO can enforce means putting on paper what it cannot enforce, which surfaces the places where the PMO's mandate exceeds its actual power.

Start by categorizing the PMO's intended functions by authority level. Three categories cover most cases:

Mandate (enforce): Things the PMO can block or require without the project team's agreement. Examples: "No project above $500K receives budget release without a signed project charter reviewed by the PMO" or "All schedule updates must be submitted in the approved format to be reflected in portfolio reporting." These require executive sign-off on the charter because they constrain other teams.

Standard (expect): Things the PMO expects all projects to do, with escalation path when they don't. The difference from mandate: the PMO cannot block funding on its own authority, but can escalate to the sponsor. Examples: "All projects will maintain a risk register updated monthly. Non-compliance is escalated to the project sponsor for resolution within 30 days."

Advisory (recommend): Things the PMO recommends but cannot require. Tools, methodologies, communication templates. Teams are free to deviate. The PMO tracks deviation and reports patterns but does not intervene.

Most PMOs operate as if they have more mandate authority than they actually do. Naming the actual authority level in the charter is uncomfortable because it makes the limits visible. It is also what prevents the PMO from spending half its time in governance disputes it cannot win.

Pair the authority section with the escalation path: if a project team refuses a mandate-level requirement, what happens? It goes to the PMO director, who escalates to the executive sponsor. The sponsor resolves it. Without this path named in the charter, the PMO's first contested enforcement becomes a precedent-setting negotiation rather than a routine application of defined policy.

For PMOs that are new or rebuilding after a credibility loss, starting with advisory authority and earning trust before moving to mandate authority is often the more durable path. The PMO maturity tiers that work best at each phase of PMO development tend to align authority level to organizational readiness rather than the PMO director's preference.

The review cadence most charters omit

Almost every PMO charter describes what the PMO will do. Almost none of them describe when the charter itself will be revisited.

This gap costs PMOs significantly when organizational context shifts. The charter was written when the company had 400 employees; the company now has 900 and has restructured twice. The charter says the PMO reports to the CFO; the CFO's role was absorbed by a new executive structure. The charter names three functions the PMO will own; two of those functions were moved to the CTO's organization eighteen months ago. The document is now actively misleading.

A PMO charter without a review cadence gets outdated and nobody owns updating it because the original owner may have left. When the charter is finally pulled out to resolve a dispute, it describes an organization that no longer exists.

Fix this by specifying three things in the charter's final section:

  1. Annual review: The charter is reviewed every twelve months. The PMO director presents an assessment of how the current charter does and does not reflect current reality. The sponsor either reaffirms or updates.
  2. Trigger reviews: Named events that require an immediate review regardless of the annual cycle. Typically: a change in the PMO's executive sponsor, a major organizational restructure affecting the PMO's scope, or a material change in the PMO's mandate (e.g., taking on or losing ownership of a function).
  3. Owner: One named person is responsible for scheduling and running the annual review. Default is the PMO director, with the sponsor's involvement for approval. Without a named owner, reviews slide indefinitely.

The review section is the easiest section to write and the one most teams skip because it feels like housekeeping. It is not housekeeping. It is the mechanism that keeps the charter functional as a living reference rather than a historical artifact.

When the charter gets tested

Every PMO charter gets tested eventually. A VP tells their team to skip the gate review because the project is moving too fast. A department head submits a project that doesn't meet the charter's compliance requirements and asks the PMO to process it anyway. A sponsor, facing budget pressure, asks the PMO to de-prioritize enforcement in a specific program.

What happens in that moment depends entirely on the charter's authority section and the strength of the sponsor relationship. A PMO with a charter that says "all projects above $500K require gate review, with funding held pending compliance" and an executive sponsor who signed that document has standing to hold the line. A PMO with a charter that says "the PMO encourages gate review processes for large projects" does not have standing to hold anything. Both charters look similar on paper.

The practical test for a charter's authority section is this: if the PMO reads the relevant section aloud in the room where the dispute is happening, does the executive in that room know they're bound by it? If the answer is yes, the charter is functioning. If the answer is "I don't know what that means for me specifically," the authority section is not yet specific enough.

Use the PMO Maturity Assessment to score the governance dimension before writing the charter. PMOs operating below a certain maturity threshold consistently overwrite the authority section relative to where the organization can actually support them. The assessment identifies the gap and helps calibrate the charter to authority the PMO can actually exercise.

For the charter's outcomes section, pair it with the goals and milestones discipline the PMO will use to track project performance. The PMO's own outcomes should follow the same rigor it expects of the projects it governs. A PMO that enforces clear milestone tracking but can't name its own success milestones signals that governance is for projects, not for the function itself.

When the first serious dispute arrives, a well-written PMO charter saves hours of political negotiation and preserves the PMO's credibility. The charter is not a bureaucratic formality. It is the document that determines whether the PMO operates as a function with standing or as a team that asks nicely.

Run the free PMO Maturity Assessment Score your PMO's governance structure, authority model, and operating maturity against five tiers. Identify the gaps between your charter's claimed authority and where your organization actually is. No signup required. → Open the assessment

PMO CharterPMOProject Management OfficeProject GovernancePMO MandatePMO SetupProject Management

Ready to make the switch?

Start your free Onplana account and import your existing projects in minutes.