Ask a room of project managers what a project charter is, and every hand goes up.
Ask the same room what a PMO charter is, and it goes quiet.
The first document is one of the most familiar artifacts in the profession. The second is one most practitioners have never seen, and a fair number do not know exists at all. That asymmetry is the subject of this piece. It explains a pattern I meet more often than any other: an organization decides it needs a PMO, creates the box on the org chart, and hires a manager to run it. Then, some months later, it starts asking why the thing is not working.
The answer is almost always that the discipline everyone accepts at project level was never applied one level up.
The document goes by several names
Most people who have spent time near delivery know the project charter, even if their method calls it something else. The name shifts with the tradition, but the object is the same.
In PMI language it is the project charter. The PMBOK Guide describes it as the document that formally authorizes the existence of a project and gives the project manager the authority to apply organizational resources to it — issued by a sponsor at a level senior enough to fund the work. PRINCE2 splits the same job across two artifacts. A Project Brief justifies and authorizes the initiation stage. The Project Initiation Documentation then becomes the baseline the project answers to for the rest of its life. In IPMA-influenced and continental European practice the equivalent instrument is the project mandate or project assignment — Projektauftrag in German-speaking organizations — the formal act by which a sponsoring body commissions the work and names who will lead it.
Three traditions, one purpose. Each of them answers a single question before a task is scheduled or a budget is drawn down: who has authorized this, and what exactly have they authorized?
No charter, no project
Strip away the template and a charter does a small number of load-bearing things. It states why the project exists and what business result would justify it. It sets measurable objectives and the criteria by which anyone will judge it delivered. It draws the boundary of scope — what is in, and, more usefully, what is explicitly out. It fixes the milestone and budget envelope the work must live inside. And it names two people whose absence is fatal: the sponsor who owns the outcome, and the project manager to whom authority is being handed.
That last function is the whole point of the document. A charter is the moment an organization says, in writing, that a named person may commit specific resources to a specific outcome. Everything else on the page is detail arranged around that transfer of authority.
This is why its absence is not a minor administrative gap. A project without a charter still has activity, and often budget and people, but it has no mandate — no agreed sponsor, no delegated authority, no shared definition of what success would look like. It is not a lean project. It is an unauthorized one. The symptoms are predictable: scope drifts because nobody fixed its edge, decisions recycle because no one holds the authority to close them, and accountability blurs because the sponsor was never named or never showed up. I treat “show me the charter” as a diagnostic for exactly this reason. When it cannot be produced, that is not a paperwork problem. It is the finding.
The version almost nobody has met
Here the ground gets less familiar, and this is the part worth slowing down for.
The same instrument exists for a PMO — not for a single project, but for the standing function that is supposed to govern many of them. It is not widely known. That is not because practitioners encounter it and overlook it; it is because it lives in a body of knowledge most of them have never studied. It is codified in the standard behind PMI’s PMO-CP certification, which is the first credential to treat the PMO itself — rather than the projects beneath it — as the object that requires definition. The underlying method, the PMO Value Ring, builds a PMO from the services its stakeholders actually need rather than from a generic template.
What the PMO charter formalizes is the PMO’s mandate. It is the written, approved statement of why the function exists, who it serves, what it is authorized to do, and by whose authority it operates — the same transfer of authority a project charter performs, applied to a permanent function instead of a temporary one.
The premise is simple and slightly uncomfortable. If you would not launch a project without stating its purpose, its sponsor, its scope, and its success criteria, why would you stand up an entire organizational function — one that will consume salaries and political capital for years — with less rigor than you demand of a three-month initiative?
A PMO charter is the answer to that question. It forces the mandate to be settled before the hire, not after it.
What the charter actually contains
PMI’s PMO-CP materials set the charter out as ten elements. Listed plainly, they are the contents of a PMO’s mandate — and a working checklist for anyone standing one up. If you cannot fill a field in honestly, that blank is the diagnosis; treat it as information, not as a formatting task to finish later.
| Element | What it must settle |
|---|---|
| 1. Purpose and mission | Why the PMO exists and what it does, in one or two sentences. If it cannot be stated short, it has not been decided yet. |
| 2. Vision | What the PMO aims to become over the medium and long term, tied to the organization’s own goals rather than a generic “center of excellence” line that could belong to any company. |
| 3. Coverage scope | Enterprise, departmental or divisional, program- or project-specific, or a deliberate hybrid — and what sits outside the remit. A function with no boundary cannot say no. |
| 4. Objectives | A small number of macro-objectives, each attached to the key results that would show it was met. Three sharp ones outperform ten aspirational ones. |
| 5. Stakeholder relationships | Who will actually use the PMO’s services and what they need — and, named explicitly, the executive sponsor behind it. An unsponsored PMO is an overhead line waiting to be cut. |
| 6. Basic resource needs | A preliminary org chart and an honest budget estimate for standing it up. A PMO that no one is willing to fund is a good intention, not a function. |
| 7. Implementation roadmap | The phased plan for establishing or evolving the PMO, with deliverables per phase. Standing one up is itself a change program; treat it as one. |
| 8. Success criteria | The main KPIs by which the PMO will be judged, defined before launch rather than reverse-engineered later to justify the budget. |
| 9. Review-and-update process | How and how often the charter — the mandate — is revisited. Mandates decay and scope drifts; a charter never reopened is already out of date. |
| 10. Charter approval | The roles required to sign it off. Authority that is not formally granted is not authority; it is optimism with a job title. |
Ten fields. Filled in honestly, they are a mandate. Left blank, they are the reason a PMO spends its first year explaining itself.
Where it helps, and where it is overkill
Two honest caveats, because a checklist without them is just a template.
A charter records authority; it does not manufacture it. If the executive team will not grant a real mandate, the most complete charter in the world describes a gap rather than a function. That is still worth having. Far better to see the gap in week one than to discover it in month nine — after the manager has been hired and blamed for a design decision that was never theirs to make.
And the instrument should scale to the need. A three-month tactical clean-up does not require the full apparatus of a permanent enterprise office, with a five-year vision and a quarterly review cycle. Over-engineering the mandate is its own failure mode. The purpose is not to generate documentation. It is to make an organization state what a function is for before it hires someone to be it.
Write the charter before the hire
The box is the easy part. Two weeks, a job description, and a line on the org chart. The mandate is the hard part, and it is precisely the part a charter forces you to write down before there is a name on the door.
Do it first, and the manager you hire inherits a function with a purpose, a boundary, and a way to prove it is working. Do it last, and you have hired someone to reverse-engineer a reason for the department to exist — usually against colleagues who never agreed it should.
A PMO that has to explain itself after it is built was chartered too late.