Template by Methodology

PMBOK Project Charter Template: PMI's 6-Element Initiating Process Format

PMBOK does not define a charter layout. It defines six required inputs and six required outputs, and leaves the format to your PMO. This page gives you both lists, a filled example, and the four PMBOK 7 performance domains the charter activates.

What PMI Actually Says About Charters

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. Across both editions PMI is precise about two things: a charter has six required inputs and produces six required outputs. PMI is deliberately silent about layout, page count, font, and section ordering. That silence is the source of every "is this PMBOK-compliant?" argument in PMO review meetings.

The practical reading: if your draft covers all six outputs with content traceable to the six 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.

The Six Required Inputs

PMBOK 6 itemises these as inputs to the Develop Project Charter process. PMBOK 7 folds them 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

Input from sponsor, finance, legal, and a senior PM. PMBOK treats facilitation techniques (workshops, brainstorming) as a formal input to charter development.

Source: PMBOK Guide, 6th and 7th editions (PMI).

The Six Required Outputs

If the document you hand the sponsor is missing any of these six, it is not a PMBOK charter. It is a project brief, a project description, or a status update.

#OutputWhat goes in this section
01Project purposeOne paragraph stating why the project exists. Should reference the business case but not duplicate it.
02Measurable objectives and success criteriaThree to five SMART outcomes with baselines, targets, and deadlines.
03High-level requirementsWhat the project must do, not how it will do it. Detailed requirements come later in the scope statement.
04Overall project description, boundaries, and key deliverablesIn-scope and out-of-scope summary plus the top three to seven deliverables by category.
05Overall project riskTop three to five risks the project faces at charter time. PMBOK calls this 'overall risk', distinct from the detailed risk register written later.
06Summary milestone schedule and pre-approved financial resourcesFive to seven phase-gate milestones with target dates plus the budget envelope the sponsor has pre-approved (with contingency band).

Filled Example: Atlanta Data Centre Migration

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.

1. Project Purpose

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.

2. Measurable Objectives and Success Criteria

  • 100% of in-scope workloads migrated and post-migration verified by 30 November 2027 (baseline: 0 migrated, 31 December 2025).
  • Average application downtime per workload under 4 hours, P95 under 6 hours (baseline: target only, no current migration data).
  • Zero unrecoverable data-loss incidents during cutover (baseline: target only).
  • Programme cost at or below USD 18.4M including 12% contingency (baseline: USD 16.4M base estimate).

3. High-Level Requirements

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).

4. Project Description, Boundaries, and Key Deliverables

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.

5. Overall Project Risk

  • Lease holdover penalty if migration slips past 31 December 2027 (USD 480K per quarter).
  • Cross-AZ latency to dependent SaaS providers exceeds 18 ms SLA, requires pre-migration network engineering.
  • Pure Storage data replication backlog during peak business hours (Q4 retail traffic).

6. Summary Milestone Schedule and Pre-Approved Financial Resources

Budget: USD 18.4M total (USD 16.4M base + USD 2.0M contingency, 12.2% reserve)

Milestones:

  • M1. Network engineering complete (target: 31 March 2026)
  • M2. First 50 workloads migrated (target: 30 June 2026)
  • M3. Storage migration 50% complete (target: 30 September 2026)
  • M4. 50% of workloads migrated (target: 31 December 2026)
  • M5. All workloads migrated (target: 30 November 2027)
  • M6. DC-A lease handover (target: 31 December 2027)

The Four PMBOK 7 Domains the Charter Activates

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 vs Other Methodology Charters

PMBOK is the default in PMI-aligned PMOs. If your team uses a different framework, the charter has a different shape:

Frequently Asked Questions

Is the PMBOK charter different from a PMI charter?
No. PMI publishes the PMBOK guide and treats the charter as the singular output of the Develop Project Charter process. When a job description asks for 'PMI-style' or 'PMBOK-style' charters, they mean the same document: the six outputs above, written before planning begins.
Has the charter changed between PMBOK 6 and PMBOK 7?
The document is unchanged. What changed is the framing. PMBOK 6 treated Develop Project Charter as one of 49 processes in the Initiating process group. PMBOK 7 collapsed the process language into 12 principles and 8 performance domains, and treats the charter as the formal artefact that activates Stakeholder Engagement, Planning, and Project Work domains together. If your PMO standard cites the PMBOK 6 process, the charter you write is functionally identical to what PMBOK 7 would expect.
What is the difference between a PMBOK project charter and a business case?
The business case is approved before the charter. It answers 'should we do this?'. The charter answers 'we are doing this, here are the boundaries'. The PMBOK process explicitly lists the business case as an input to charter development, which means the charter cannot exist until the business case is approved. If your sponsor is asking for both at once, push back and write the business case first.
Who approves a PMBOK project charter?
The project sponsor signs the charter. PMI defines the sponsor as the person providing resources and support for the project, accountable for enabling success. The PM does not approve the charter, drafts it. The steering committee may co-sign for programme-level work but ultimate authority sits with the named sponsor.
Does PMBOK require a specific charter template?
No. PMBOK lists the six required outputs (purpose, objectives, requirements, scope, risk, milestones / budget) but does not prescribe a format. A one-page lean charter that covers all six outputs is PMBOK-compliant. A 12-page enterprise charter that adds RACI, communication plan, and assumptions log is also PMBOK-compliant. PMI's published examples lean toward 3 to 5 pages but explicitly state organisations should adapt the format to their governance.
How long should a PMBOK charter take to write?
Four to twelve hours of focused work for the PM, plus two to four hours of sponsor and stakeholder review. PMI Pulse of the Profession data (2024 report) shows projects with charters drafted in under two weeks have 31% higher on-time delivery rates than those drafted in over four weeks. Speed signals sponsor engagement; long charter cycles signal sponsor ambivalence.
Should every project use the PMBOK charter format?
Not necessarily. PMBOK is the default for predictive (waterfall) projects in PMOs that follow PMI standards. Scrum teams use a leaner Product Goal and Sprint Goals format, PRINCE2 teams use a Project Mandate plus Project Brief plus Project Initiation Documentation triad, and Lean teams often use an A3. PMBOK is dominant in North American and Middle Eastern enterprises, less so in UK government (where PRINCE2 dominates) and Japan (where A3 dominates).

Related on this site

Updated 2 May 2026