The project charter shows up in PMP questions more often than its page count suggests. It is rarely the subject of the question. It is the thing the question assumes you have read. A scenario says the sponsor wants a scope change, or a functional manager refuses to release a resource, or the team is arguing about who approves a deliverable — and the correct answer depends on what the charter already settled.
Candidates who treat the charter as a formality lose those points. Candidates who treat it as the document that defines the project manager's authority tend to get them.
What the charter actually does
The charter authorizes the project. That is its function, and the wording matters on the exam: it authorizes the project, and it authorizes the project manager to apply organizational resources to project activities. It does not authorize the project manager to approve the project, change its purpose, or expand its boundaries.
That distinction explains a recurring answer pattern. The project manager can compile, draft, and facilitate the charter, but the sponsor or initiating group is the authority that issues it. As one PMP-focused treatment of the topic puts it plainly, the project manager cannot be the authority who approves the project. When a question offers an option where the project manager approves their own charter or signs off on a change to the project's stated purpose, that option is wrong regardless of how reasonable it sounds.
What belongs inside it
PMP exam material built on the PMBOK Guide describes charter contents along these lines:
| Element | What it settles |
|---|---|
| Purpose and justification | Why the project exists |
| Measurable objectives and success criteria | What "done well" means, in numbers |
| High-level requirements | Initial business and compliance needs |
| High-level project description and boundaries | What is in, and what is explicitly out |
| Assumptions and constraints | What is being taken as true, and what is fixed |
| High-level risks | Initial exposure, elaborated later in the risk register |
| Summary milestone schedule | The significant dates |
| Summary budget | An initial range, not an estimate |
| Key stakeholder list | Who can influence or be affected |
| Approval requirements | Who accepts deliverables, and on what criteria |
| Project manager and authority level | Staffing, technical decisions, conflict resolution, budget variance thresholds |
| Sponsor and signatories | Who committed |
The actual contents are driven by the needs of the organization and the project, so the exam will not ask you to recite the list. It will ask you to notice that something in the list has been violated, skipped, or contradicted.
The row that earns the most exam points is project manager and authority level. A charter that states the project manager may resolve conflicts and manage budget variance up to a threshold has pre-answered a whole family of scenario questions. When a question describes a decision and asks what the project manager should do, check first whether the charter already granted the authority. If it did, acting within it beats escalating. If it did not, escalating beats acting.
Assumptions and constraints are the quiet answer key
Every project starts with statements nobody has verified. The vendor will deliver in six weeks. The regulatory review will be routine. Two senior engineers will be available in Q2. Those are assumptions, and each one is a risk wearing different clothing.
Practice differs on where they live. Some organizations record high-level assumptions and constraints directly in the charter. Others open a separate assumption and constraint log during initiation that starts with those high-level entries and accumulates detailed ones as the project proceeds. Either arrangement is acceptable; the exam cares that the entries exist, have owners, and get revisited.
A constraint is different from an assumption, and mixing them up costs points. An assumption might turn out false. A constraint is a limit you must design around — a fixed due date, a capped budget, a mandated technology, a regulatory boundary. You validate assumptions. You plan within constraints, and you escalate when a constraint and an objective become incompatible.
Two patterns worth recognizing:
- A scenario reveals that something everyone believed is not true. The expected first move is to check the assumption log, update the entry, and assess the impact — not to replan immediately and not to inform the sponsor before you know the size of the problem.
- A scenario presents a request that collides with a documented constraint. The expected move is not to refuse and not to absorb it quietly. It is to surface the collision to whoever owns the constraint, with the impact quantified.
Kickoff is not the same as the charter
Candidates sometimes merge the two. The charter is an artifact that authorizes; the kickoff is a meeting that aligns. The charter comes first, because a kickoff without an approved charter aligns people around a project nobody has committed to funding.
Timing varies by approach. In predictive work, kickoff typically follows charter approval and precedes detailed planning. In iterative and adaptive work, a kickoff happens early and often — a short alignment event at the start of each release or major iteration — because the plan is expected to change. If a question gives you an adaptive setting and an answer option insists on a single kickoff before any work begins, treat it with suspicion.
Why this matters more on the current exam
PMI updated the PMP exam in July 2026. The three domains remain People, Process, and Business Environment, but the weightings moved substantially: People from 42% to 33%, Process from 50% to 41%, and Business Environment from 8% to 26%. PMI describes the revised exam as placing more emphasis on outcomes, value delivery, and business impact, and as weaving AI, sustainability, and stakeholder engagement into project-based scenarios.
That reweighting changes how charter questions feel. Business Environment at 26% means more scenarios where the right answer traces back to the business case, the benefits the project was authorized to deliver, and the compliance boundaries the charter recorded. The charter is where the project's link to organizational strategy is written down. When a question asks whether work should continue, the charter's stated objectives and success criteria are frequently the evidence the answer rests on.
How to study it in an hour
Not by memorizing the contents table. Instead:
- Write a one-page charter for a project you have actually worked on. Fill in every row above. The rows you cannot fill are the ones the exam will test you on.
- For your authority-level row, write three decisions you could make alone and three you would have to escalate. That exercise builds the instinct the exam is measuring.
- List five assumptions from that project and mark which turned out false. Then write what the first response should have been.
- Separate your assumptions from your constraints and check that you have not labeled a limit as a belief.
The charter is short, stable, and rarely revisited by candidates after week one of study. That is exactly why it is worth a second pass.