The Discipline of Delivery · companion to Chapter 2
The Project Charter
Authority, SMART objectives and scope boundaries — plus the out-of-scope fence that most charters leave off.
Project charter mastery guide for software PMs
📜
What is a project charter?
The PM's founding document — authority, purpose, and mandate in one place
A project charter is the formal document that officially authorises a project to exist and gives the Project Manager the authority to use organisational resources. Without a signed charter, a PM has no mandate. It is the single most important document created during the Initiation phase — before any planning, building, or spending begins.
What it is NOT
Not a project plan. Not a requirements document. Not a SOW. The charter is a high-level document — typically 1–4 pages. It answers "what are we doing and why" not "how will we do it." Details come later in the PMP.
Who creates it
The PM drafts it. The project sponsor signs it. The sponsor's signature is what makes it official — it authorises the project and the PM's role. Without sponsor sign-off, it is just a wish list.
When it is created
At the very start of Initiation — before the team is assembled, before planning begins, before any budget is spent. It triggers the planning phase. If a project has started without a charter, creating one retroactively is still worth doing.
Can it change?
The charter can be updated if major scope, sponsor, or objectives change — but every update requires sponsor re-approval. It is not a living daily document like the risk register. It is the stable reference point for the whole project.
Charter vs other documents — the key distinctions
Charter vs Business Case
The business case justifies WHY the project should be approved (ROI, strategic fit, options analysis). The charter authorises the project after it has been approved. Business case comes first; charter follows.
Charter vs Project Management Plan
The charter is 1–4 pages, high-level, created in Initiation. The PMP is detailed, covers all knowledge areas, created during Planning. The charter is the "what and why"; the PMP is the "how."
Charter vs SOW (Statement of Work)
A SOW is a vendor-facing contract document. A charter is an internal governance document. A project can have both — the SOW governs what a vendor delivers; the charter governs the overall project.
Charter vs Scope Statement
The charter defines high-level scope. The scope statement (created during Planning) defines detailed scope with explicit in-scope and out-of-scope items, constraints, and assumptions. The charter seeds the scope statement.
📋
Every section decoded
Click each to see why it matters, good examples, and what to avoid
✏️
Live charter builder
Fill in the fields — preview your charter instantly
Project identity
Project name be specific
Project ID optional
Project sponsor
Project manager
Start date
Target end date
Purpose & objectives
Problem statement what problem are we solving?
Project objectives SMART — Specific, Measurable, Achievable, Relevant, Time-bound
Success criteria how will we know we succeeded?
Scope
In scope
Out of scope critical — prevents scope creep
Resources & constraints
Budget envelope
Team size
Key constraints
Key risks (top 3)
Key stakeholders
↻
Charter in Agile & SAFe contexts
How the charter adapts — lighter, faster, still essential
In pure Agile teams, a traditional multi-page charter feels heavyweight. But the intent never changes: you still need documented authority, objectives, scope boundaries, and stakeholder alignment. The format adapts — the purpose does not.
Agile / SAFe equivalents of charter elements
The "lean charter" — 1-page agile version
What a lean charter contains
A lean charter for an agile project fits on one page or one Confluence page. It covers: why we're doing this (problem statement), what we're building (high-level scope), how we'll know we're done (exit criteria), who's in charge (PM + PO + sponsor), boundaries (what we won't build), and key constraints (timeline, budget, non-negotiables). Everything else lives in the backlog.
PI Objectives vs charter objectives
In SAFe, PI Objectives define what an ART commits to deliver in one PI (~10 weeks). The charter sets longer-term project objectives. They coexist — charter objectives are stable; PI objectives are the incremental steps toward them.
Product Vision vs charter
The Product Vision (owned by the PO) describes the long-term product direction. The charter documents the specific project: budget, timeline, authority, constraints, and success criteria. The vision can outlive many project charters.
When to still use a full charter in agile
When the project involves a vendor (SOW accompanies it), when regulatory or audit compliance is required, when budget needs formal executive sign-off, or when the project crosses multiple teams or departments.
Team working agreement vs charter
A Team Working Agreement defines how the team collaborates (ways of working). The charter defines what the project is. Both are needed — they answer different questions and have different audiences.
⚠️
Top charter mistakes — and how to fix them
What bad charters look like and why they cause project failures
☑️
Charter quality checklist — before you submit for sign-off
0 / 7
correct
Running a project that is slipping? Book a 30-minute delivery review with Siva: we look at your plan, your numbers and the one thing to fix first.
Companion to Chapter 2 of The Discipline of Delivery by Siva Prasad. Read the chapter to understand why the discipline matters, then use this guide to practise the how.