Project Charter in PM²: the mandate that makes a project governable
Twenty-fifth article in the “Learning PM² Through a Project” series
A Business Case may demonstrate that an investment is sensible. It does not, by itself, state who has authority to decide, which initial scope is authorised, which constraints apply, or who must deliver the solution.
The PM² Project Charter fills this gap: it turns an approved initiative into a formally mandated project, with a shared direction and explicit governance.
What is the Project Charter?
The Project Charter is the high-level document that describes and authorises the project. It does not replace the Project Handbook or Project Work Plan; those will follow in planning with greater detail.
| Document | Purpose |
|---|---|
| Business Case | Justify or reject investment and recommend an option. |
| Project Charter | Formalise project mandate, objectives, governance, initial scope and constraints. |
| Project Handbook | Collect how the project will be managed: plans, roles, processes and artefacts. |
| Project Work Plan | Turn the mandate into deliverables, activities, estimates, schedule and dependencies. |
The Charter should not become a repository for every detail. It must be complete enough for sponsor, team and stakeholders to start from the same project definition.
Questions it should answer
An effective Project Charter clarifies at least:
| Area | Question |
|---|---|
| Purpose | Why does the project exist, and which problem or opportunity does it address? |
| Objectives and benefits | Which result and value does it intend to produce? |
| Initial scope | What is included, which deliverables are expected and what is excluded? |
| Stakeholders | Who requests, funds, uses, influences or is affected? |
| Governance | Which roles, bodies and decision rights apply? |
| Constraints and assumptions | Which time, cost, technology, regulatory and dependency limits condition the project? |
| Initial risks | Which uncertainties may threaten feasibility or value? |
| Indicative milestones and budget | Which initial expectations will be refined in Planning? |
| Success criteria | How will a successful project be recognised? |
If these answers are vague, a project begins with different interpretations. Detail can evolve; ambiguity about the mandate is costlier to correct.
The Charter establishes authority, not only content
The most important part of the Charter is often governance. It defines who can decide, approve, direct, manage daily and contribute.
| Role | Contribution in the Charter |
|---|---|
| PO | Ensures alignment with business objectives and value. |
| SP | Represents solution capacity, feasibility and quality. |
| BM | Leads business implementation and adoption of change. |
| PM | Manages the project and coordinates planning, execution and control. |
| PSC / AGB | Provide direction and take decisions set out in the mandate. |
The Charter need not repeat the whole RAM/RASCI, but it should make the governance model clear and refer to detail where needed. Without clarity, the PM may have to negotiate authority for every problem.
Initial scope: sufficiently clear, not artificially final
In Initiating, scope is still high level. The Charter should contain:
| Include | Avoid |
|---|---|
| Main deliverables, boundaries, users or affected areas, preliminary success criteria. | False precision about every activity, every date and every detailed requirement. |
Example: “enable booking, cancellation and waiting list in pilot gyms” is useful. “Every user always receives a notification in exactly 2.7 seconds” belongs to detailed requirements and quality definition, not the initial Charter.
From signature to RfP
In PM², the Project Charter is a key artefact for the RfP — Ready for Planning gate. Gate approval confirms that there is enough mandate to invest in planning.
flowchart LR
A[PIR] --> B[Business Case]
B --> C[Project Charter]
C --> D[RfP]
D --> E[Planning]
This does not mean that the Charter is immutable. If material changes emerge in objectives, scope, governance or constraints, it should be updated through change control and appropriate decisions.
The Annotatio case: Smart Bookings Charter
For Smart Bookings, a Charter summary could be:
| Section | Example |
|---|---|
| Objective | Reduce no-shows and manual work by making booking management reliable in pilot gyms. |
| Main outputs | Booking, cancellation, waiting list and essential occupancy dashboard. |
| Initial exclusions | Integration with physical turnstiles, payments and loyalty programme. |
| Expected benefits | Fewer empty places and phone requests; more reliable occupancy data. |
| Stakeholders | Managers, floor collaborators, registered clients, Annotatio team, notification provider. |
| Governance | PO decides business priorities; SP confirms feasibility; BM leads adoption; PM coordinates the project. |
| Constraints | Go-live before the new season; reuse existing authentication and infrastructure. |
| Initial risks | Collaborator adoption, push-notification reliability, manager availability for testing. |
| Success | Accepted feature, adoption in pilot gyms and measurable reduction in no-shows after go-live. |
This does not replace detailed planning, but prevents the team from building something different from what business and sponsor consider authorised.
Charter and PM authority
The Project Charter should make the PM’s mandate explicit: not to give them power to decide everything, but to establish that they can coordinate work, manage within tolerances, convene necessary activities, flag deviations and escalate.
| The PM can typically | The PM should not do alone |
|---|---|
| Coordinate team and planning; manage daily issues; propose options; monitor and report. | Unilaterally change objectives, budget, material scope or decisions reserved for governance. |
Clear delegation reduces both micromanagement and decision vacuums.
Do not confuse these
| Statement | Correction |
|---|---|
| “The Project Charter is a shorter Business Case.” | The Business Case justifies investment; the Charter formalises project mandate and governance. |
| “The Charter must contain the complete plan.” | It defines high-level direction and limits; Planning adds operational detail. |
| “After approval it cannot change.” | It can evolve, but material changes require Change Management and governance. |
| “The Charter authorises the PM to decide everything.” | It clarifies delegations and limits; it does not remove governance authority. |
Three questions to anchor it
- What is the difference between Business Case justification and Charter mandate?
- Who has authority to decide if a material constraint requires a scope change?
- Which missing element would leave the team with different interpretations of the project?
Flashcards
Q: What is the Project Charter for?
A: To formalise and authorise the project, defining mandate, objectives, initial scope, governance, constraints and success criteria.
Q: Does the Charter replace the Project Work Plan?
A: No. The Charter provides direction and authorisation; the Work Plan details work, estimates, schedule and dependencies.
Q: Why is the Charter important for the PM?
A: It makes the PM’s role, delegations, governance and management limits explicit.
Exam-style question
A project has an approved Business Case, but the team starts planning without a Charter. PO and SP have different views on what is included in the first release, and it is unclear who approves trade-offs.
What is the main problem?
Answer: a shared project mandate is missing. The Project Charter should formalise objectives, initial scope, governance, roles and constraints, providing a common basis for the RfP gate and planning.
Source
The Project Charter and its role in the Initiating Phase are described in the European Commission’s PM² Methodology Guide 3.1.
Next: Project Handbook, the operational container that connects project roles, plans, processes and artefacts.