Project Charter Guide What to Include & How to Get It Approved

01 — Overview

What is a Project Charter?

A project charter is the document that formally authorises a project to begin and gives the project manager the authority to apply organisational resources to project activities. In PMBOK, it is an output of the Develop Project Charter process — the first process in the Initiating process group. Without a signed charter, the project has no formal mandate and the PM has no organisational authority to proceed.

The charter does two things simultaneously: it documents what the project is and why it exists clearly enough to be a reference document throughout the project, and it secures the formal signature that converts a proposal into an authorised project. These two functions explain why getting the tone right matters — a charter that reads like a business case fails as an operational reference; one that reads like a project plan fails as an authorisation document.

✅ What the Charter Does

Formally authorises the project to begin

Grants the PM authority to use resources

Documents project purpose and objectives

Defines high-level scope boundaries (in and out)

Identifies key stakeholders and their roles

Sets high-level timeline and budget authority

Records key assumptions, constraints and risks

Provides a reference for scope change decisions

✗ What the Charter Does NOT Do

Define the detailed project schedule (that's the schedule)

List every deliverable in detail (that's the WBS)

Analyse all risks in depth (that's the risk register)

Specify resource assignments by task (that's the resource plan)

Define quality criteria for each deliverable (that's the QMP)

Substitute for the project management plan

Replace the business case (which justifies the investment)

💡

Charter vs Business Case: The business case justifies why the organisation should invest in this project — it analyses options, financial returns and strategic fit. The charter authorises the project that has already been approved and defines how it will be governed. In PMBOK, the business case is an input to Develop Project Charter — the charter references it but does not duplicate it. If your charter is being mistaken for a business case, it has too much financial justification and not enough governance content.

02 — Charter Sections

The 10 Charter Sections — What Each Must Contain

A complete project charter covers ten areas. The sections are sequential — each builds on the previous one. A sponsor reading the charter should be able to understand the project's purpose, boundaries and governance structure in a single read, without needing to consult any other document.

Project Title and Identifier

A clear, unambiguous project name and a unique project ID (from the PMO or portfolio management system). The title should describe the outcome, not the activity — "Customer Data Platform" not "Data Migration Project Phase 2 v3 Final."

Include version number and date — charters go through drafts and the signed version must be identifiable.

Project Purpose and Business Justification

Two to four sentences explaining why this project exists. What problem does it solve? What opportunity does it capture? Which strategic objective does it support? This section is the "why" — if a new stakeholder reads nothing else, this should tell them why the organisation is spending money on this.

Reference the approved business case by title and date — do not reproduce it.

Measurable Project Objectives

Three to five specific, measurable outcomes the project must achieve. Each objective should have a metric and a target value — not "improve customer satisfaction" but "increase NPS score from 34 to 45 within 6 months of go-live." See Section 03 below for how to write objectives that hold up to scrutiny.

Objectives must be testable at project end — if you cannot measure whether you achieved it, it is not an objective.

High-Level Scope Statement

What is included in this project and — critically — what is explicitly excluded. The scope statement in the charter is the first line of defence against scope creep. See Section 04 for how to define scope boundaries that hold up when challenged.

Scope exclusions are as important as inclusions. Anything not explicitly excluded will eventually be claimed as "obviously included."

High-Level Deliverables

A concise list of the major outputs the project will produce — typically the Level 2 items from the eventual WBS. Not every task or document, but the significant deliverables that stakeholders will recognise as signs of progress. Five to twelve items is typical.

This is not the WBS — each item should be a noun (a product or outcome) not a verb (an activity).

High-Level Timeline and Milestones

Start and end dates, plus three to six major milestone dates — phase completions, key decision gates, regulatory submission dates, go-live. Not a Gantt chart. A high-level timeline with milestone descriptions and target dates is enough for a charter.

Milestones are events, not durations. "UAT completed" on a specific date — not "UAT — 3 weeks."

High-Level Budget

The total approved budget with a summary breakdown by major cost category (labour, external, technology, contingency). This section establishes the PM's spending authority. Include the contingency reserve amount and note who controls management reserve separately.

The budget in the charter is the authority to spend — it should match the approved business case figure. Do not over-specify cost breakdowns here; that belongs in the project budget template.

Key Stakeholders and Roles

A table of named individuals with their project role (Sponsor, Business Owner, Project Manager, Steering Committee members, key subject matter experts). This is not the full stakeholder register — just the governance roles that need to be visible in the authorisation document.

Name people, not just roles. "TBC" in the Project Manager field at the charter stage signals the project is not ready for authorisation.

Assumptions, Constraints and High-Level Risks

Key assumptions the project is built on (and the risk if they are wrong), organisational and environmental constraints (regulatory requirements, technology constraints, budget limits), and the top three to five risks at initiation level. This section protects the PM — it documents that the risks were visible at the point of authorisation.

Assumptions and constraints are separate: an assumption is something believed to be true; a constraint is a real limitation. Conflating them weakens both.

PM Authority and Sponsor Signature

A clear statement of the PM's delegated authority — spending limits, recruitment authority, change approval thresholds — and the formal signature block for the sponsor. The sponsor's signature is what converts the document from a proposal into an authorised project.

Include the signature date prominently — the date of signing is the official project start date for governance purposes.

03 — Writing Objectives

Writing Measurable Objectives That Hold Up

Project charter objectives are the most commonly written badly of any charter section. Weak objectives are either unmeasurable ("improve customer experience"), too vague to be useful as a success criterion ("deliver the system on time and within budget"), or describe outputs rather than outcomes ("deliver a new CRM system").

A strong objective is SMART: Specific (clear about what will change), Measurable (with a metric and target value), Achievable (realistic given constraints), Relevant (linked to a business outcome), and Time-bound (with a target date for achievement).

❌ Weak Objectives

"Improve the customer experience across digital channels."

No metric, no target, no timeframe. Impossible to measure whether this was achieved at project end.

✅ Strong Objectives

"Increase digital channel NPS from 34 to 45 within 6 months of the platform go-live date (target: November 2026)."

Specific metric (NPS), current baseline (34), target value (45), timeframe (6 months post go-live), absolute date (November 2026).

❌ Output Objective

"Deliver a new CRM system to replace the legacy platform."

Describes the deliverable, not the business outcome. The CRM could be delivered on time and still be considered a failure if it does not improve business performance.

✅ Outcome Objective

"Reduce average sales cycle from 47 days to 32 days within 3 months of CRM go-live, enabling the sales team to handle 20% more accounts with the same headcount."

Business outcome (sales cycle reduction), specific metrics (47→32 days), consequent benefit (20% capacity), timeframe (3 months post go-live).

📌

Include the baseline, not just the target. "Increase NPS to 45" is a weaker objective than "Increase NPS from 34 to 45" because the baseline establishes the starting point — making both the gap and the achievement unambiguous. If you do not know the current baseline, measure it before writing the objective. A target without a baseline is a wish, not an objective.

04 — Scope Definition

Defining Scope Boundaries — In, Out and Deferred

The scope section of the project charter is the first and most important line of defence against scope creep. Scope defined vaguely at initiation will be interpreted broadly during execution — every ambiguous boundary will be resolved in favour of "that's obviously included."

A strong scope statement uses three lists: In Scope (what the project will deliver), Out of Scope (what the project will specifically not deliver), and Deferred (items that are acknowledged but intentionally excluded from this phase for a future phase). The Out of Scope and Deferred lists are as important as the In Scope list — and far more frequently omitted.

❌ Vague Scope Statement

"The project will implement a new customer relationship management system to improve sales and marketing processes across the business."

No boundaries. Does "across the business" include the international offices? Does "marketing processes" include the email platform? Does "improve" include redesigning the sales incentive structure? Each of these will become a disputed scope item.

✅ Bounded Scope Statement

"In Scope: CRM implementation for UK sales team (47 users), migration of 3 years of historical customer data, integration with the ERP system (accounts module only) and training programme. Out of Scope: international offices, marketing automation platform, customer portal, mobile app. Deferred to Phase 2: self-service reporting module."

Every ambiguous area from the weak version is now explicitly resolved. No disputed interpretations. Any request outside these boundaries is a change request.

⚠️

The charter scope statement is the baseline for change control. Any request that is not clearly within scope as defined in the charter should be processed as a change request — even if it seems small. The habit of accommodating small undocumented scope additions early in the project is what creates the "how did we end up 40% over budget?" conversations at the end of it. Use the Change Request Form template for every change, regardless of size.

05 — Industry Examples

Project Charter Examples Across Six Industries

The structure of a project charter is consistent across industries, but the language and emphasis vary significantly. Here are worked examples of the objective and scope sections from six common project types — showing how the same charter framework applies to very different contexts.

🏥 Healthcare / NHS

Electronic Patient Records Migration

Objective: Migrate 100% of active patient records from Legacy EPR to System C by 31 March 2027 with zero data loss verified by reconciliation audit.
Out of Scope: Historical records pre-2015, clinical systems integration (Phase 2), GP practice systems.

Charter emphasis: data integrity, regulatory compliance (CQC), patient safety impact.

🏗️ Construction & Infrastructure

Office Refurbishment — HQ Building

Objective: Deliver refurbished 4th and 5th floors accommodating 220 staff within £2.4M budget by 30 June 2026, achieving BREEAM Excellent certification.
Out of Scope: Floors 1–3, external façade, car park, IT infrastructure (separate project).

Charter emphasis: building regulations, contractor governance, business continuity during works.

💻 Technology / SaaS

Payment Gateway Integration

Objective: Integrate Stripe payment gateway into platform, reducing checkout abandonment rate from 34% to below 20% within 90 days of release.
Out of Scope: Refund workflow redesign, international currency handling, mobile app (separate sprint).

Charter emphasis: PCI-DSS compliance, API versioning, rollback plan.

🏦 Financial Services

DORA Compliance Programme

Objective: Achieve full DORA compliance by 17 January 2026 regulatory deadline across all in-scope ICT systems (47 applications), avoiding regulatory sanction.
Out of Scope: Third-party vendor remediation (separate workstream), legacy systems scheduled for decommission.

Charter emphasis: regulatory deadline, board accountability, audit trail.

🏛️ Public Sector / Government

Benefits Processing System Replacement

Objective: Reduce average benefits processing time from 28 days to 10 days for 95% of claims by go-live (target Q3 2026), achieving GDS Service Standard assessment pass.
Out of Scope: Fraud detection system, appeals process, integration with DWP legacy systems.

Charter emphasis: GDS assessment, public accountability, ministerial sign-off.

🎓 Education

Learning Management System Implementation

Objective: Deploy Canvas LMS for 8,500 students and 320 academic staff by September 2026 start of term, with 85% of module content migrated from Moodle and all staff trained.
Out of Scope: Library systems integration, student records system, corporate training (separate procurement).

Charter emphasis: academic calendar constraints, GDPR (student data), staff adoption.

06 — Getting Approved

How to Get Your Charter Approved First Time

Most charter rejections or lengthy revision cycles are caused by one of three things: the sponsor does not feel the project is ready to be authorised, the document is not written for the right audience, or there are unresolved governance questions that the sponsor is not comfortable signing off on. All three are avoidable.

Brief the sponsor verbally before the document lands

A sponsor who encounters the charter for the first time when you ask them to sign it will have questions — and those questions will delay approval. Brief them verbally first: "I am about to send you the project charter for your review. The headline is [objective], the budget is [amount] and the main risk I want to flag is [risk]. I would like to target sign-off by [date]." The document then confirms what they already expect, rather than introducing new information that needs processing before signing.

Write the executive summary first and last

Many sponsors will read the executive summary and the signature block and little else. Write the executive summary as though it were a standalone document — it should answer: what is this project, why are we doing it, what does it cost, when does it deliver and what is the main risk? Then write the full charter in detail, and revise the executive summary at the end to ensure it accurately reflects what is in the rest of the document.

Resolve the governance questions before submitting

The questions that most often block charter sign-off are: Is the PM confirmed? Is the budget formally approved? Are the key business stakeholders aligned? Has the business case been signed off? If any of these answers are "not yet", the charter is not ready. A charter submitted for sign-off before these foundations are in place will create exactly the questions it should be answering.

Circulate for comment before the formal approval request

Send a draft marked "For Review and Comment" to key stakeholders — sponsor, business owner, PMO — at least five working days before the sign-off deadline. Address their comments in a revised draft. The formal approval submission should be a version that has already been reviewed, not the first time key people have seen it. Sponsors who raise comments during a review cycle and see them incorporated will sign the final version with far less resistance.

Set a specific sign-off deadline and follow up

Document the sign-off deadline in the covering email: "I need the signed charter by [date] in order to begin resource engagement on [start date]." Link the deadline to a concrete consequence. Follow up by phone two days before the deadline if you have not received it. A charter left for "whenever is convenient" for the sponsor will wait indefinitely. The PM's job is to create the conditions in which the sponsor can sign — that includes managing the timeline and following up without apology.

07 — Common Mistakes

Six Charter Mistakes That Cause Problems Later

❌

Making it too long — including project plan content

A charter that includes detailed schedules, task lists, resource assignments and risk matrices has become a project management plan. Sponsors are less likely to read it thoroughly, making it less useful as an authorisation document. It also sets up confusion about which document is the governing reference.

Fix: Keep the charter to 3–5 pages. If content belongs in the project management plan (schedules, detailed budgets, risk registers), put it there — reference it in the charter, do not reproduce it.

❌

Vague scope — no explicit exclusions

A scope statement that only lists what is included invites disputes about everything not listed. Stakeholders will consistently argue that unlisted items are "obviously included" — and they will do so after significant work has already been done, when the cost of saying no is high.

Fix: Always include an explicit "Out of Scope" section and a "Deferred to Future Phase" section. Every common assumption about what might be included should be explicitly resolved — in or out.

❌

Unmeasurable objectives

"Improve user experience" and "deliver a more efficient process" are not objectives — they are aspirations. At project closure, there is no way to determine whether they were achieved, making the project success assessment entirely subjective and open to dispute.

Fix: Every objective needs a metric, a current baseline value, a target value and a target date. If you cannot fill in all four, the objective is not finished.

❌

Not naming the PM and sponsor explicitly

A charter with "TBC" in the PM or Sponsor field is an unfinished document. Without named individuals, the governance structure has no one accountable to it. More practically, a charter without a named sponsor cannot be signed.

Fix: Both PM and Sponsor must be named before the charter is submitted for sign-off. If the PM has not been formally confirmed, the charter should not be going to the sponsor — resolve the PM appointment first.

❌

Writing the charter in isolation — without sponsor input

A PM who drafts the charter without any input from the sponsor and then sends it for sign-off often receives a list of corrections that could have been avoided with a 30-minute conversation. The sponsor may have different expectations about scope, budget or success criteria that need to be surfaced before the document is drafted.

Fix: Have a scoping conversation with the sponsor before drafting — not a review after. Understand their definition of success, their key concerns and any constraints they are working within. Draft to their priorities, not your assumptions.

❌

Never updating the charter when scope changes significantly

A charter signed in January that has been superseded by three significant scope changes by June is no longer an accurate authorisation document. The PM is then operating against an agreed baseline that no longer reflects reality.

Fix: When an approved change request significantly alters the scope, objectives, budget or timeline documented in the charter, issue a revised charter version and get it signed. Version-control the charter as you would any governance document.

08 — FAQ

Project Charter — FAQ

A project charter formally authorises a project to begin and gives the project manager authority to apply organisational resources. In PMBOK it is an output of the Develop Project Charter process in the Initiating process group. It documents the project's objectives, scope boundaries, key stakeholders, high-level milestones, budget authority and the PM's delegated authority. Without a signed charter the project has no formal mandate and the PM has no organisational authority to proceed. Download the free project charter template to get started.

A complete project charter includes: project title and unique identifier; purpose and business justification; measurable objectives with metrics and target dates; high-level scope statement with explicit inclusions and exclusions; key deliverables; high-level timeline with major milestones; high-level budget with spending authority; key stakeholders and governance roles; assumptions, constraints and top risks; and the PM's delegated authority with sponsor signature. It should be 3–5 pages — comprehensive enough to authorise clearly, concise enough to be read and signed.

The charter is typically drafted by the project manager but authorised and signed by the project sponsor — the person with authority to commit organisational resources. The PM cannot sign their own authorisation. In PMBOK, the charter technically exists before the PM is formally assigned (it is created in the Initiating process group by the sponsor or a programme manager) — but in practice the PM usually drafts it for sponsor review. What matters is that the sponsor signs it and that the signed version is the one the project operates against.

Typically 3–5 pages for a standard project. Long enough to provide meaningful authorisation and context; short enough to be read thoroughly before signing. The most common mistake is making it too long by including content that belongs in subsidiary plans — detailed schedules, resource plans, risk registers. If your charter exceeds 6 pages, check whether it contains planning detail that should be moved to the project management plan. The charter authorises the project; the project management plan defines how it will be delivered.

The business case justifies why the organisation should invest in the project — it analyses options, financial returns, risk and strategic fit and recommends whether to proceed. The charter authorises the project that has already been approved and defines how it will be governed. In PMBOK the business case is an input to Develop Project Charter. The charter references the business case but does not duplicate it. A charter that reads like a business case has too much financial justification and not enough governance content. Use the free Business Case template for the investment justification, then the charter for the formal authorisation.

Project Charter GuideWhat to Include & How to Get It Approved