PMP Project Charter: Components, Examples & Templates

The first formal document I ever signed as a project manager was a charter, and I still remember the meeting room. It was on a wet October morning, my sponsor was running ten minutes late, and the charter I had drafted was four pages long with three pages of appendices. By the time the sponsor arrived, scanned the front page and signed at the bottom, I realised that 80% of what I had written would never be read by anyone other than me. That experience shaped how I have approached charters ever since.

A project charter is the formal authorisation for a project. In PMI terminology it is the output of Process 4.1, Develop Project Charter, and it is the single document that gives the project manager the authority to apply organisational resources to project activities. Without it, the project is informal, contested, and politically vulnerable. With it, the project has a foundation. In this article I will walk through what a charter contains, what it does not, why it matters far beyond the exam, two complete sample charters (one IT, one construction), and the formal sign-off rules that PMI expects you to know.

A project charter is a formal document issued by the project sponsor (or by a person or group with sufficient authority) that authorises the existence of a project and grants the project manager the authority to apply organisational resources to project activities. That definition, slightly paraphrased from the PMBOK Guide, is worth memorising because it contains every important word.

"Formal" means it is written. Verbal authorisation does not count. "Issued by the sponsor" means it does not come from the project manager. The PM may draft it, but the sponsor owns it. "Authorises the existence" means before the charter is signed the project formally does not exist. "Authority to apply resources" means the PM can now legitimately request budget, staff, and time.

"The charter is not just paperwork. It is the social contract between the sponsor and the project manager. Without it, every difficult conversation later is harder."

I have learned over the years to think of the charter as a piece of organisational architecture. It creates a boundary around the work. Inside the boundary the PM has authority. Outside the boundary they do not. Everyone, including the PM, benefits from that clarity.

Process 4.1, Develop Project Charter, is the first process in the PMBOK Guide Sixth Edition. It belongs to the Initiating Process Group and the Integration Management Knowledge Area. Its placement is deliberate: nothing else in the PMI framework happens before a charter exists.

The inputs to 4.1 are the business documents (business case and benefits management plan), agreements (especially for external projects), enterprise environmental factors, and organisational process assets. The output is the charter itself and the assumption log. The techniques used to produce it include expert judgement, data gathering (brainstorming, interviews, focus groups), interpersonal and team skills (conflict management, facilitation, meeting management), and meetings.

For the exam, you should know that the charter:

• Is created in Initiating, not Planning
• Is signed by the sponsor, not the PM
• Authorises the PM to apply resources
• Identifies the PM (by name, not just role) where possible
• Is high-level (no detailed plans)

A frequent exam trap is to describe a scenario where a PM is mid-execution and discovers a missing element. The correct answer often references the charter, because the charter is the source of truth for high-level direction.

PMI does not mandate a fixed format, but the PMBOK Guide identifies content that should appear in nearly every charter. The components I include in every charter I write are:

If your charter contains all of the above and nothing else, it will pass any sensible review. If you find yourself adding detailed schedules, full requirements documents, or Gantt charts, you have moved into the project management plan, not the charter.

These three elements form the heart of the charter and the area where I see most candidates struggle. They are related but distinct.

The purpose answers "why are we doing this project?" It should connect to organisational strategy. Example: "To improve customer self-service capability and reduce contact-centre call volume by enabling online account management."

The objectives answer "what specifically will we achieve?" They must be SMART (specific, measurable, achievable, relevant, time-bound). Example: "Reduce call-centre volume by 25% within six months of go-live, measured against the rolling 12-month average."

The success criteria answer "how will we know if we succeeded?" They are the acceptance conditions. Example: "Project will be considered successful if (a) call volume reduction targets are met, (b) customer satisfaction NPS does not decline, and (c) cost remains within 10% of approved budget."

A trick I use: if you cannot distinguish a sentence as a purpose, objective, or criterion, it is probably none of them and should be cut. Charters bloat when sentences blur these categories.

These three sections give the charter its physical shape. The PM will refine each later, but the charter establishes the order of magnitude.

High-level requirements are not detailed user stories. They are statements of what must exist for the project to be considered complete. Example: "The system must support secure login, account balance display, statement download, and payment scheduling."

High-level milestones are not a full schedule. They are the four to eight dates the sponsor cares about. Example:

• Charter signed: March
• Requirements baselined: April
• System integration testing complete: August
• User acceptance testing complete: October
• Go-live: November

The summary budget is an order-of-magnitude estimate, often with a stated accuracy range (e.g., minus 25% to plus 75%). It is not a detailed cost baseline. Example: "Estimated total cost: 1.8 million GBP, plus or minus 30% at charter stage. Cost baseline to be established in Planning."

The stakeholder list at charter stage is short. It identifies the sponsor, project manager, customer (if external), and the four or five most senior or influential people. A full stakeholder register comes later in the Identify Stakeholders process.

High-level risks are the top five to ten things the sponsor needs to know about. Example: "Risk of vendor delivery slippage due to ongoing supply-chain disruption" or "Risk of resource contention with parallel programme."

Assumptions are things the PM is taking as true without proof. They should be tracked because if any prove false, the project is at risk. Example: "We assume the existing identity provider can be reused without modification."

Constraints are limitations the PM cannot change. Example: "The project must go live before the end of the financial year for regulatory compliance reasons."

I keep all four sections short at charter stage. The detail comes later. The charter exists to flag, not to resolve.

This section is often missing from charters I review and it is the single most useful section to get right. It defines what the PM can do without further approval.

Specific elements I include:

• Spending authority: "The PM may approve expenditure up to 25,000 GBP per item without further sponsor approval, subject to remaining within the approved budget."
• Hiring authority: "The PM may approve contract resources up to a daily rate of 800 GBP and total contract value of 100,000 GBP without further approval."
• Schedule authority: "The PM may reschedule internal milestones provided the external go-live date is not affected."
• Scope authority: "The PM may approve minor scope clarifications. Material scope changes require sponsor approval via the change control process."
• Escalation rules: "Any item exceeding the above thresholds, or any risk that may jeopardise the go-live date, must be escalated to the sponsor within 48 hours of identification."

A charter without explicit PM authority creates ambiguity that haunts the project. I have seen PMs lose months to political battles that a single paragraph in the charter would have prevented.

PROJECT CHARTER

Project name: Customer Portal Migration to Cloud
Project sponsor: Chief Customer Officer
Project manager: [Named PM]
Charter date: 15 January 2026

1. Purpose

To migrate the existing on-premise customer portal to a cloud-native architecture, reducing infrastructure cost, improving scalability, and enabling new self-service features.

2. Measurable objectives

• Reduce infrastructure cost by 40% within 12 months of go-live
• Improve portal availability from 99.5% to 99.95%
• Enable three new self-service features (account closure, statement download, scheduled payments) within six months of go-live
• Complete migration with zero customer data loss

3. Success criteria

• All current portal functions available in new platform on go-live day
• Customer NPS does not decline by more than 5 points in the three months following go-live
• Project delivered within 10% of approved budget
• Migration completed by 30 November 2026

4. High-level requirements

• Re-platform onto cloud infrastructure (AWS or Azure)
• Maintain feature parity with existing portal
• Implement single sign-on with corporate identity provider
• Meet ISO 27001 and PCI DSS requirements
• Provide migration runbook and rollback procedure

5. High-level milestones

• Charter signed: January 2026
• Vendor selected and contracted: March 2026
• Architecture baseline approved: May 2026
• System integration testing complete: August 2026
• User acceptance testing complete: October 2026
• Go-live: November 2026
• Project closed: December 2026

6. Summary budget

Estimated total cost: 2.4 million GBP, plus or minus 30%. Cost baseline to be established in Planning.

7. Key stakeholders

Sponsor: Chief Customer Officer. PM: [Named]. Customer representatives: Head of Customer Operations, Head of Digital. Technical owners: CTO, Head of Infrastructure. Security: CISO. Compliance: Head of Data Protection.

8. High-level risks

Vendor delivery slippage; data migration complexity; regulatory change during execution; resource contention with parallel programmes; cloud cost overrun.

9. Assumptions and constraints

Assumptions: existing identity provider can be reused; cloud regions in current jurisdiction will remain available; no major regulatory changes during project. Constraints: go-live must precede December 2026 freeze period; budget capped at 2.7 million GBP.

10. PM authority

PM may approve spend up to 50,000 GBP per item within budget. PM may approve contractor engagements up to 750 GBP daily rate. Material scope or schedule changes require sponsor approval.

Sponsor signature: _____________________ Date: _________

PROJECT CHARTER

Project name: Head Office Refurbishment, Floors 3 to 6
Project sponsor: Chief Operating Officer
Project manager: [Named PM]
Charter date: 5 February 2026

1. Purpose

To refurbish floors 3 to 6 of the head office to support a new hybrid working model, increase usable workspace density by 20%, and meet revised sustainability standards.

2. Measurable objectives

• Increase desk capacity from 320 to 384 (20% uplift)
• Achieve BREEAM Very Good rating
• Reduce energy consumption per square metre by 30%
• Complete works without disrupting business on adjacent floors

3. Success criteria

• All four floors handed back fit for occupation by 30 September 2026
• BREEAM certification achieved within 60 days of handover
• Project delivered within 8% of approved budget
• Zero reportable health and safety incidents

4. High-level requirements

• Strip-out and re-fit of four floors (total 4,800 square metres)
• New HVAC, lighting, and electrical distribution
• Acoustic treatment for collaboration zones
• Cabling infrastructure to revised desk layout
• Compliance with current fire safety and accessibility regulations

5. High-level milestones

• Charter signed: February 2026
• Design approved: March 2026
• Main contractor appointed: April 2026
• Floor 3 handover: June 2026
• Floor 4 handover: July 2026
• Floor 5 handover: August 2026
• Floor 6 handover: September 2026

6. Summary budget

Estimated total cost: 4.1 million GBP, plus or minus 25%. Cost baseline to be established in Planning.

7. Key stakeholders

Sponsor: COO. PM: [Named]. Facilities Director. Head of Health and Safety. Head of HR (workplace strategy). Building owner (landlord). Principal contractor. Designer (architect). Local planning authority.

8. High-level risks

Discovery of asbestos during strip-out; supply-chain delays for specialist materials; planning permission delays; disruption to adjacent occupied floors; weather-related delays to external works.

9. Assumptions and constraints

Assumptions: landlord approval can be obtained within four weeks; existing building services have sufficient capacity. Constraints: noisy works restricted to outside office hours; floors 1, 2, 7, and 8 remain occupied throughout; budget capped at 4.5 million GBP.

10. PM authority

PM may approve spend up to 75,000 GBP per item within budget. PM may approve variations up to 50,000 GBP. Material variations require sponsor and finance director approval.

Sponsor signature: _____________________ Date: _________

The charter is not a one-time document filed away after signature. I keep it visible throughout the project and refer to it frequently. Specifically:

• I quote the purpose and objectives at the start of every steering committee meeting
• I check change requests against the success criteria before approving them
• I revisit assumptions at each major milestone and flag any that are no longer valid
• I refer to the PM authority section whenever a scope or spending question arises
• I use the charter as the baseline against which "scope creep" can be objectively assessed

 "If you cannot remember what was in your own charter by the time you are halfway through execution, your charter is too long, your project is off the rails, or both."

The charter also matters at closure. The closure report typically restates the original objectives and success criteria and reports against each. A clear charter makes closure straightforward. A muddy charter makes closure contentious.

PMI is specific about charter approval. The sponsor signs the charter. Not the project manager. Not a committee. The sponsor.

In practice, charters are often counter-signed by other parties (the PM, the customer, the finance director, the CTO) but the controlling signature is the sponsor's. If the sponsor changes mid-project, a fresh charter or a formal endorsement of the existing charter by the incoming sponsor is good practice.

Re-approval is required when material changes occur. Material change is judged against the original objectives. Examples:

• Budget increase of more than 10%
• Schedule slip of more than 15%
• Scope change affecting any success criterion
• Sponsor change

Minor changes do not require re-charter, but should be documented as charter addenda or via the change control process described in the project management plan.

In Agile and hybrid contexts, charters are often lighter (sometimes called a "project brief" or "vision document") but the formal authorisation principle remains. Someone with authority must explicitly authorise the work.

I want to be honest about my own mistakes because they tend to repeat across PMs.

1. Writing the charter alone. Early in my career I drafted charters in isolation and presented them for signature. The signatures came reluctantly. Now I co-write the charter with the sponsor over two or three short sessions.
2. Including too much detail. My second-ever charter was 14 pages long. Nobody read it. Now I aim for two to three pages of body plus one page of appendix.
3. Vague objectives. "Improve customer experience" is not an objective. "Reduce average response time from 8 hours to 2 hours" is.
4. Missing PM authority. I once spent six weeks negotiating spending approval because the charter was silent on the topic. Never again.
5. No revisit cadence. I now schedule a charter review at the end of Planning and at each major milestone.

If you can avoid these five mistakes, your charters will be in the top quartile of those I have seen in audits.

Agile projects still need a charter, but the form and emphasis differ. In a Scrum-based programme I worked on a few years ago we used a one-page "Product Vision and Charter" that included:

• Product vision (one paragraph)
• Target customer (one paragraph)
• Key value drivers (three bullet points)
• Initial release roadmap (high-level, one table)
• Funding envelope (initial quarter only; further quarters re-evaluated)
• Product owner authority and decision rights
• Stakeholder map

We did not include detailed requirements (those lived in the backlog), nor a fixed scope (the backlog evolved). What mattered was the formal authorisation and the clarity around decision rights. The product owner's authority to prioritise the backlog was explicit in the charter.

For hybrid projects, I tend to include a fixed-scope element (the "must have") and an evolving element (the backlog). The charter authorises both, with different governance for each.

Practical templates I have used and recommend:

• A two-page Word template with the components listed in Section 3
• A one-page on-a-page summary for very small projects (under 100,000 GBP)
• A Confluence or Notion page version for digital-first organisations
• A more detailed charter (5 to 7 pages) for regulated industries

Best practices I follow:

• Co-draft with the sponsor, do not present finished work
• Keep the charter to fewer than five pages including appendices
• Use plain language, not PMI jargon, unless the audience is PMI literate
• Get signatures within two weeks of starting drafting; do not let charters drift
• Store the signed charter in the project repository with version control
• Reference the charter explicitly in every steering committee deck