Template by Methodology
PMBOK does not define a charter layout. It defines the inputs and tools of the Develop Project Charter process and the content elements the charter document must carry, then leaves the format to your PMO. This page gives you the inputs, the six core content elements, a filled example, and the four PMBOK 7 performance domains the charter activates.
The PMBOK Guide treats the charter as a single artefact authored during the Initiating process group (PMBOK 6) or, in the 7th edition, as the activation document for the Stakeholder Engagement, Planning, and Project Work performance domains. In PMBOK 6 the Develop Project Charter process formally lists its inputs (business documents, agreements, enterprise environmental factors, organisational process assets) and produces two outputs: the project charter itself and an assumption log. What PMI is precise about is the charter's content, not its layout: it enumerates the elements the document must carry. PMI is deliberately silent about page count, font, and section ordering. That silence is the source of every "is this PMBOK-compliant?" argument in PMO review meetings.
The six elements below consolidate that content list into the sections most PMOs actually use. The practical reading: if your draft covers all of them with content traceable to the process inputs, it is PMBOK-aligned. If it skips overall risk, it is not. If it lists 14 risks instead of the recommended top three to five, it is still aligned, just over-engineered. The most common failure mode in PMBOK reviews is not format. It is missing the budget envelope, because sponsors hesitate to commit before planning, and PMs let them.
PMBOK 6 itemises the first five below as inputs to the Develop Project Charter process (business documents split into the business case and benefits management plan). The sixth, expert judgement and facilitation, is a tool of the process rather than an input. PMBOK 7 folds the inputs into the broader Stakeholder Engagement and Planning domains but does not remove the requirement.
1. Business case
The financial and strategic justification approved before the charter is drafted. Without it you are documenting a project nobody has authorised to spend money on.
2. Benefits management plan
How and when the project's benefits will be measured. Charters link to this so the success criteria can be traced back to organisational outcomes.
3. Agreements
Contracts, MOUs, or letters of intent already in place with vendors, partners, or regulators. The charter references them but does not reproduce their detail.
4. Enterprise environmental factors
The internal constraints (PMO standards, approval thresholds, governance forums) and external factors (regulatory regime, market conditions) the charter must respect.
5. Organisational process assets
Lessons learned from comparable projects, charter templates the PMO mandates, escalation paths defined in policy.
6. Expert judgement and facilitation (tools, not inputs)
Input from sponsor, finance, legal, and a senior PM. In PMBOK 6 these sit in the tools-and-techniques column of the Develop Project Charter process (expert judgement, data gathering, interpersonal and team skills, meetings), not the inputs column. They are how the charter gets written, not a document fed into it.
PMBOK 6 lists the elements a project charter should carry; the six below consolidate that list into the sections most PMOs use. If the document you hand the sponsor is missing any of them, it reads as a project brief, a project description, or a status update rather than a charter.
| # | Output | What goes in this section |
|---|---|---|
| 01 | Project purpose | One paragraph stating why the project exists. Should reference the business case but not duplicate it. |
| 02 | Measurable objectives and success criteria | Three to five SMART outcomes with baselines, targets, and deadlines. |
| 03 | High-level requirements | What the project must do, not how it will do it. Detailed requirements come later in the scope statement. |
| 04 | Overall project description, boundaries, and key deliverables | In-scope and out-of-scope summary plus the top three to seven deliverables by category. |
| 05 | Overall project risk | Top three to five risks the project faces at charter time. PMBOK calls this 'overall risk', distinct from the detailed risk register written later. |
| 06 | Summary milestone schedule and pre-approved financial resources | Five to seven phase-gate milestones with target dates plus the budget envelope the sponsor has pre-approved (with contingency band). |
A real-shape worked example. Numbers are realistic for a mid-size US enterprise migrating off a lease-expiring facility, drawn from publicly reported migrations in the AWS and Equinix case study libraries.
Migrate 412 production workloads from Atlanta DC-A (lease expires 31 December 2027) to DC-C colo facility in Smyrna with zero data loss, application downtime under 4 hours per workload, and total programme cost under USD 18.4M.
Every in-scope workload must retain its current IP after migration, accept a maximum 4-hour downtime window during cutover, and produce a post-migration verification report signed by the workload owner before the workload is considered closed.
The migration must comply with the Atlanta data residency requirement (no workload may transit outside Georgia or Alabama at any point during the cutover window).
In scope: 412 production workloads in DC-A racks A1 through A48; storage migration (4.2 PB); network re-IP for the 10.42.0.0/16 block; DR test failover to DC-C secondary.
Out of scope: Do not refactor any application code. Do not migrate the 38 deprecated workloads tagged for sunset. Do not change the storage vendor (Pure Storage stays). Do not migrate dev or QA environments (handled by separate workstream).
Key deliverables: Workload migration runbooks (412), cutover verification reports (412), DR failover test report, DC-A decommissioning certificate, final cost reconciliation.
Budget: USD 18.4M total (USD 16.4M base + USD 2.0M contingency, 12.2% reserve)
Milestones:
PMBOK 7 reframed the 49-process model into 12 principles plus 8 performance domains. The charter activates four of those domains directly.
Stakeholders
Charter identifies sponsor, owner, and pre-approval signatories. PMBOK 7 treats this as the entry point to the Stakeholder Engagement performance domain.
Planning
Charter sets the boundaries that planning expands. Without the charter's scope, deliverables, and milestones, the planning phase has no anchor.
Project work
Charter authorises the PM to draw on enterprise resources. PMBOK frames this authority as the work that activates the project.
Delivery
Charter's success criteria become the delivery scorecard. Acceptance maps to charter, not to detailed scope.
PMBOK is the default in PMI-aligned PMOs. If your team uses a different framework, the charter has a different shape:
Scrum Charter
Product Goal and Sprint Goal replace the PMBOK objectives section. No formal sign-off process.
PRINCE2 Mandate / Brief / PID
PRINCE2 splits the PMBOK charter into three sequential documents (Mandate, Brief, PID). UK government default.
A3 (Lean)
Single A3 sheet (Toyota origin). Charter, plan, and follow-up on one printed page. Dominant in Japanese manufacturing.
Hybrid Waterfall-Agile
PMBOK structure for discovery and approval, Scrum structure for delivery. Used when half the org wants each.
Related on this site
Updated 2 May 2026