The Project Charter: What It Is and How to Write One
Every project needs a moment when someone with authority says: "Yes, this project is happening. This is what we're doing and why, here's who's in charge, and here are the resources committed to making it happen." The project charter is that moment, captured in writing. It's one of the most important documents in project management — and one of the most frequently misunderstood.
What a Project Charter Actually Is
A project charter formally authorises the existence of a project and grants the project manager the authority to apply organisational resources — people, budget, equipment, and time — to project activities. Without a charter (or equivalent authorising document), a project manager is in the uncomfortable position of asking colleagues to do work without the organisational standing to require it. The charter changes that dynamic. It's the PM's licence to operate.
The charter is written during the Initiating process group, before the project plan is developed. It sets the stage; it does not tell the full story. Think of it as the authorising document from the sponsor, not a detailed management plan from the team.
What Goes In a Project Charter
A well-constructed project charter typically contains the following elements:
Project purpose and justification. Why does this project exist? What business problem does it solve, or what opportunity does it capture? This section links the project to organisational strategy and explains why the investment is worthwhile. A project without a clear purpose is a project waiting to be cancelled.
High-level scope. What is included in this project, in broad terms? What is explicitly excluded? This is not a detailed scope statement — that comes later, in the project plan — but it's important to establish the boundaries early so stakeholders share a common understanding of what the project will and will not deliver.
Objectives and success criteria. What does success look like? Objectives should be SMART: specific, measurable, achievable, relevant, and time-bound. Success criteria answer the question: how will we know when we're done, and how will we know we've delivered value?
Key stakeholders. Who has a significant interest in or influence over the project? The charter typically identifies the project sponsor, the project manager, key internal stakeholders, and any critical external parties (regulators, major vendors, partner organisations). A full stakeholder register comes later; the charter just captures the most important names.
High-level risks. What are the biggest uncertainties facing the project? This is not a detailed risk register — that comes during planning — but noting the top two or three risks early ensures they're visible to the sponsor and the team from day one.
Assumptions and constraints. Assumptions are things we're treating as true without proof — "the software vendor will deliver the integration module by September." Constraints are boundaries we must work within — "the project must be completed before the fiscal year-end." Documenting these early prevents misunderstandings later.
High-level milestone schedule. Not a Gantt chart — just the major milestones: project kick-off, key deliverable dates, phase gates, and the target completion date. This gives the sponsor and stakeholders a sense of the timeline without committing to a detailed schedule that hasn't been built yet.
Approved budget. The overall funding authorised for the project, at a high level. This may be a range or contingency-inclusive estimate at the charter stage, particularly for complex projects where detailed estimation hasn't yet occurred.
Project manager assignment and authority. The charter explicitly names the project manager and defines the scope of their authority — what decisions they can make independently, what requires sponsor or steering committee approval. This is critically important: ambiguity about PM authority is a leading cause of escalation delays and project frustration.
What Does NOT Go in a Project Charter
This is where many new project managers go wrong. The charter is an initiating document, not a planning document. The following belong in the project management plan, not the charter:
Detailed work breakdown structure (WBS)
Detailed project schedule with task-level dependencies
Detailed risk register with probability and impact ratings
Resource assignments and detailed staffing plans
Detailed budget with cost breakdowns by work package
Quality management plan, communications plan, procurement plan
Conflating the charter with the project plan produces a bloated document that takes too long to write, gets approved too late, and overwhelms the stakeholders who need to sign it.
Common Mistakes
Beyond scope creep in the document itself, the most common charter mistakes are: skipping it entirely on "small" projects (which usually turn out to be bigger than expected); writing it after planning has already begun (defeating the purpose); failing to get genuine sponsor sign-off (a charter without a signature is just a memo); and treating it as a static document when major scope changes occur (the charter should be updated or superseded when the project changes fundamentally).
The Charter as a Governance Tool
Well-run organisations use the project charter as more than a formality. It's the first gate in project governance — a structured check that confirms the project is aligned with strategy, adequately resourced, and assigned to a capable PM before money is spent. Programme and portfolio management offices (PMOs) often maintain charter templates and approval workflows to ensure consistency across the project portfolio.
Getting the initiation phase right sets the foundation for project success. help organisations build the governance structures, tools, and discipline that turn good projects into great outcomes.