By Rahul Dhakate · PMP Certified · May 2026 · learnxyz.in
The project charter is one of the first formal documents created in any project according to PMI’s framework — and it is one of the most misunderstood in practice.
In the real world of software development and IT delivery, project charters often exist but are not always created by the project manager. At Valethi Technologies, for example, the formal project charter for a major client engagement was presented by the VP of Accounts. As the project manager, I received it as a reference document — the authorisation and high-level scope were already established before I began detailed planning. This is actually more common in enterprise environments than most PMP study guides acknowledge.
But understanding what a project charter contains, what purpose it serves, and how it connects to the rest of the project — that knowledge is both practically useful and heavily tested on the PMP exam. This guide gives you both.
What is a Project Charter?
A project charter is a formal document that officially authorises a project to begin and gives the project manager the authority to apply organisational resources to project activities.
Three things make the project charter significant in PMI’s framework:
- It formally authorises the project — without a project charter, the project has no official existence in PMI’s model
- It establishes the project manager’s authority — the charter names the PM and defines the scope of their decision-making power
- It documents the high-level scope, objectives, and constraints — creating the foundation for all subsequent planning
PMI’s key rule: the project charter is created during the Initiating process group, before any planning begins. It is not a planning document — it is an authorisation document. This distinction appears frequently on the PMP exam.
Who Creates the Project Charter?
This is where real-world practice and PMI’s framework sometimes diverge — and where your own experience is directly relevant.
According to PMI, the project charter is created by the project sponsor or initiator — typically a senior executive, a VP, or a client who is funding the project. The project manager may assist in developing the charter, but the authority to sign it comes from outside the project team.
In practice, as I experienced at Valethi Technologies, the charter often arrives as a pre-existing document from a VP or account manager. The project manager’s role is to understand it deeply, identify gaps, and ensure the project is planned accordingly. Understanding what a good charter contains — and what questions to ask when it is incomplete — is a genuine project management skill.
What Does a Project Charter Contain?
PMI defines the project charter as containing the following key elements:
- Project purpose and justification — why the project is being done and what business need it addresses
- Measurable project objectives — specific, verifiable success criteria
- High-level requirements — what the project must deliver at a summary level
- High-level project description and boundaries — what is and is not included
- High-level risks — major uncertainties known at initiation
- Summary milestone schedule — key dates and major deliverables at a high level
- Pre-approved financial resources — the initial budget authorisation
- Project approval requirements — what constitutes project success and who approves it
- Assigned project manager and authority level — naming the PM and defining their decision-making power
- Name and authority of the project sponsor — who authorised the project
The charter does not contain detailed schedules, work breakdown structures, or risk registers. Those are planning documents that come after the charter has been approved. The charter is intentionally high-level — it creates the context for planning, not the plan itself.
Real Example Project Charter Template
Below is a complete project charter template you can use and adapt for real projects. This is structured to meet PMI’s requirements while reflecting how charters actually look in enterprise software environments.
| PROJECT TITLE | Multi-Tenant SaaS Platform — Phase 1 |
| Project Sponsor | VP of Accounts / Senior Business Stakeholder |
| Project Manager | Rahul Dhakate, PMP |
| Date Authorised | DD / MM / YYYY |
| Project Purpose | To design and deliver a multi-tenant SaaS platform that enables the client to onboard and manage multiple independent business tenants from a single hosted application. This project addresses the client’s strategic objective of consolidating their software offering and reducing per-customer deployment costs by 40%. |
| Measurable Objectives | 1. Deliver a working login and tenant management module within 5 weeks of project start. 2. Complete full database schema and core module development within 12 weeks. 3. Achieve successful UAT sign-off from the client within 14 weeks. 4. Deploy to production within 16 weeks of project start date. |
| High-Level Scope | IN SCOPE: Login and authentication module, tenant management, core database design, primary feature modules as defined in the requirements document, integration testing, UAT support. OUT OF SCOPE: Third-party integrations not specified in requirements, mobile application, multi-language support, post-launch feature enhancements. |
| High-Level Requirements | Platform must support minimum 100 concurrent tenants at launch. Authentication must comply with OAuth 2.0 standards. All data must be tenant-isolated with no cross-tenant data visibility. System must achieve 99.5% uptime SLA post-launch. |
| High-Level Risks | 1. API dependency on third-party vendor — risk of delayed delivery if vendor timelines slip. 2. Distributed team across geographies — risk of communication gaps and integration delays. 3. Evolving client requirements — risk of scope creep if change control is not enforced. 4. Database design complexity — risk of rework if core schema needs revision after module development begins. |
| Summary Milestone Schedule | Week 1–5: Login and tenant module delivery Week 6–12: Database and core module development Week 13–14: Integration and UAT Week 15–16: Production deployment and handover |
| Budget Authorisation | Pre-approved budget: [Amount in agreed currency]. Budget owner: [Project Sponsor Name]. Any expenditure beyond approved budget requires sponsor sign-off through formal change control. |
| Project Manager Authority | The Project Manager is authorised to assign team resources, approve project-level expenditures within budget, manage stakeholder communication, and initiate change control processes. Scope changes, budget increases, and schedule extensions beyond defined thresholds require sponsor approval. |
| Project Approval Requirements | Project is considered successfully completed upon: written UAT sign-off from the client, successful production deployment with zero critical defects, and formal handover of documentation to the client’s operations team. |
| Sponsor Signature | ________________________ Date: ____________ |
| PM Acknowledgement | ________________________ Date: ____________ |
How the Project Charter Is Tested on the PMP Exam
The PMP exam tests the project charter in several ways. Understanding these patterns helps you answer correctly even when questions seem ambiguous.
Pattern 1: Initiating vs Planning Boundary
Many questions test whether you know what belongs in the charter (initiating) versus what belongs in planning documents. If a question asks when the project manager’s authority is formally established — the answer is when the charter is signed, not when planning begins.
Pattern 2: No Charter Scenario
Some questions describe a project manager who is asked to begin work before a charter exists. The correct PMI answer: request that a charter be created before proceeding. Starting a project without a charter is not acceptable in PMI’s framework.
Pattern 3: Charter vs Scope Statement
The charter contains high-level scope. The detailed scope statement is created during planning. Questions that ask about documenting detailed requirements or detailed deliverables are referring to the scope statement, not the charter.
Pattern 4: Who Signs the Charter
The project sponsor signs the charter — not the project manager. The project manager is assigned in the charter. This distinction is tested regularly.
The project charter is the project manager’s licence to operate. No charter = no authority. This is the mental model that makes every exam question about the charter easier to answer correctly.
About the Author:
Rahul Dhakate is a PMP-certified project manager and product management leader based in Nagpur, India, with 20 years of experience managing software projects across BFSI, eCommerce, and enterprise software. He has worked with project charters across multiple engagements — receiving and interpreting sponsor-created charters at Valethi Technologies and managing projects within the authority boundaries they established. He writes at LearnXYZ.in to help working professionals understand both the theory and the real-world practice of project management.
Good Reads:
