The Project Charter

Lifecycle Phase 1 — Starting the Project | Topic 2.1

Every failed project has an origin story, and it almost always begins the same way: unclear goals, misaligned expectations, and no authoritative document that everyone agreed to before the first dollar was spent. The Project Charter exists to kill that failure mode before it takes root.

This article breaks down what the Project Charter is, why it matters more than most project managers realise, and how to construct one that actually works — from objectives through to project organisation and approval.

---

Why the Charter Matters: The Business Case for Clarity

Projects do not fail during execution. They fail during initiation — they just don't know it yet.

The Project Charter is the single document that forces alignment between the project sponsor, the project manager, and the wider organisation before resources are committed. Without it, the project team is building on assumptions. With it, every stakeholder has a shared reference point for what success looks like.

Core Principle: The Project Charter is a document which defines what the project is, who the project stakeholders are, and how it will be approached. It is usually more detailed than the Project Proposal and may be used in lieu of it in some organisations.

In organisations that use both documents, the relationship is sequential: the Project Proposal secures initial buy-in and funding authority, while the Charter provides the operational blueprint that authorises the project manager to begin work.

---

Before the Charter: The Project Proposal

In many organisations — particularly in defence, heavy engineering, and government — the Project Charter does not appear from thin air. It is preceded by a Project Proposal, a shorter document that makes the business case for the project's existence.

Key Components of the Project Proposal

Audience

The Project Proposal is submitted to the Project Sponsor (the client or party responsible for funding) and any other parties required to authorise the allocation of resources.

Think of the Proposal as the "should we do this?" document. The Charter is the "here is exactly how we will do it" document.

Business Need — Identified

Project Proposal — Drafted

Proposal — Approved?

Project Charter — Developed

Project Rejected — or Revised

Charter — Approved?

Project Manager — Authorised

Proceed to — Planning Phase

Charter Revised — & Resubmitted

Relationship details

From	Relationship	To
Business Need — Identified	leads to	Project Proposal — Drafted
Project Proposal — Drafted	leads to	Proposal — Approved?
Proposal — Approved?	leads to	Yes
Yes	leads to	Project Charter — Developed
Proposal — Approved?	leads to	No
No	leads to	Project Rejected — or Revised
Project Charter — Developed	leads to	Charter — Approved?
Charter — Approved?	leads to	Yes
Yes	leads to	Project Manager — Authorised
Project Manager — Authorised	leads to	Proceed to — Planning Phase
Charter — Approved?	leads to	No
No	leads to	Charter Revised — & Resubmitted
Charter Revised — & Resubmitted	leads to	Charter — Approved?

---

What Goes Into a Project Charter

The Project Charter should include — at minimum — the following eight sections. Each one serves a distinct purpose in removing ambiguity and establishing shared expectations.

1. Project Objectives

Objectives express what the project must deliver in terms of business benefits and the process for measuring those benefits. They represent the requirements of the client, the organisation, and other important stakeholders.

Well-written objectives follow the SMART framework:

Key Insight: Objectives are not wish lists. Each objective should be testable — at project close, you can definitively say whether it was achieved or not.

2. Scope Statement

The Scope Statement defines the extent of what the project will produce. It provides a sufficiently detailed description so that all stakeholders have a shared understanding of the project's deliverables.

This is where the project manager draws the boundary. Everything inside the line is the project. Everything outside is not.

3. Exclusions

Exclusions are the opposite of scope — they formally state what the project will not deliver. This section exists because assumptions are dangerous. If a stakeholder believes landscaping is included but the project team does not, that misalignment will surface at the worst possible time.

Rule of Thumb: If there is any reasonable chance a stakeholder might assume something is included, and it is not — list it as an exclusion.

4. Assumptions

Assumptions are factors that, for planning purposes, will be considered true, real, or certain even though they have not been confirmed. Every assumption carries an implicit risk: if the assumption proves false, the plan built on it may collapse.

Common assumptions include the availability of seconded resources, regulatory timelines, and the cooperation of third parties.

5. Constraints

Constraints are the hard boundaries that limit the project manager's options. Unlike assumptions (which may or may not be true), constraints are expected to have a 100% probability of occurring and are considered beyond the project manager's capacity to modify or remove.

Typical constraints include budget ceilings, regulatory requirements, fixed deadlines, and resource availability windows.

6. Related Projects

Projects rarely exist in isolation. This section describes dependencies on other projects — whether currently in delivery or still in planning. If the project's success depends on another project delivering on time, that dependency must be documented here.

7. Project Organisation

This is the governance section. It documents the operational management relationships between the project office and the parent organisation. At minimum, it should include:

• The name of the Project Sponsor
• The name of the Project Manager and date of assignment
• The support and interface coordination allocated to the project manager
• The authorities of the project manager, including references to company policy
• The reporting channels, structured to eliminate unnecessary layers above the project manager
• Any special instructions or delegations of authority
• Handover conditions — the circumstances under which the project management organisation will phase out or transfer authority

Project Sponsor — (Funding Authority)

Project Manager — (Operational Authority)

Core Project Team

Specialist Resources — (As Required)

Functional Manager 1

Functional Manager 2

Functional Manager 3

Steering Committee / — Board of Directors

Relationship details

From	Relationship	To
Project Sponsor — (Funding Authority)	leads to	Project Manager — (Operational Authority)
Project Manager — (Operational Authority)	leads to	Core Project Team
Project Manager — (Operational Authority)	leads to	Specialist Resources — (As Required)
Core Project Team	leads to	Functional Manager 1
Core Project Team	leads to	Functional Manager 2
Core Project Team	leads to	Functional Manager 3
Project Sponsor — (Funding Authority)	leads to	Steering Committee / — Board of Directors

8. Project Management Plan Summary

This section documents preliminary planning considerations across four dimensions:

---

The Relationship Between Charter Components

The eight sections of a Project Charter are not independent — they form an interconnected system. Understanding these relationships is critical for writing a charter that holds together under scrutiny.

Objectives

Scope Statement

Exclusions

Assumptions

Risks

Constraints

PM Plan Summary

Project Organisation

Related Projects

Relationship details

From	Relationship	To
Objectives	leads to	Scope Statement
Scope Statement	leads to	Exclusions
Objectives	leads to	Assumptions
Assumptions	leads to	Risks
Scope Statement	leads to	Constraints
Constraints	leads to	PM Plan Summary
Risks	leads to	PM Plan Summary
Scope Statement	leads to	Project Organisation
Project Organisation	leads to	PM Plan Summary
PM Plan Summary	leads to	Related Projects

Objectives drive the Scope. The Scope boundary generates Exclusions. Assumptions introduce Risks. Constraints shape the Plan. And the Project Organisation determines who has the authority to navigate all of it.

---

Getting the Charter Approved

A beautifully written charter that sits unsigned on a desk is worthless. For the project to proceed, the following authorisations must be obtained:

1. Organisational commitment to the project as a whole
2. Formal authorisation from the Project Sponsor for the project to commence
3. Formal authorisation from the chain of command (Program Director, Managing Director, or equivalent)
4. Written confirmation from appropriate bodies that all relevant statutory approvals have been granted, with any conditions noted for future reference

Critical Point: The 'Starting the Project' phase is only complete when all approvals have been obtained, a project budget and cost centre have been assigned, and the Charter and approval documents have been filed for future reference.

---

Common Pitfalls

Writing vague objectives. If an objective cannot be measured, it cannot be managed. "Improve stakeholder satisfaction" is not an objective — it is a hope. "Achieve a stakeholder satisfaction rating of 4.0 or above on a 5-point scale in the post-project survey" is an objective.

Confusing scope and objectives. Objectives describe why the project exists. Scope describes what the project will produce. The objective might be "reduce maintenance costs by 30%." The scope is "decommission Building A and relocate operations to Building B."

Ignoring exclusions. The sections you leave empty are the ones that generate disputes. If there is nothing to exclude, say so explicitly. Silence is interpreted as inclusion.

Treating assumptions as facts. Assumptions are risks in disguise. Every assumption should be paired with a risk mitigation strategy in the Plan Summary. If the assumption that "specialist veterinary resources will be available within 4 weeks" proves false, what is the contingency?

Underspecifying the Project Organisation. A charter that names the project manager but does not define their authority, reporting channels, or handover conditions is a charter that will generate conflict.

---

Key Takeaways

• The Project Proposal makes the business case; the Project Charter provides the operational blueprint
• A complete Charter includes eight interdependent sections: Objectives, Scope, Exclusions, Assumptions, Constraints, Related Projects, Project Organisation, and PM Plan Summary
• Objectives must be SMART — vague goals produce vague results
• Exclusions are as important as scope — silence on what is not included creates stakeholder conflict
• Every assumption is an embedded risk that must be acknowledged and planned for
• The Charter is not complete until it is formally approved by the sponsor and the chain of command
• The 'Starting the Project' phase concludes when approvals are obtained, a budget is assigned, and documents are filed