Study smarter with Fiveable
Get study guides, practice questions, and cheatsheets for all your subjects. Join 500,000+ students with a 96% pass rate.
The project charter is your project's birth certificate and constitution rolled into one—it's the formal document that authorizes the project to exist and gives the project manager legitimate power to spend organizational resources. On the PMP exam and in real practice, you're being tested on understanding how each charter component serves a specific governance function: authorization, alignment, boundary-setting, or accountability. A weak charter leads to scope creep, stakeholder conflicts, and project failure, which is why exam questions frequently probe whether you can identify what belongs in a charter versus other project documents.
Think of charter components as falling into distinct categories: some establish the strategic foundation (why are we doing this?), others define boundaries and constraints (what can and can't we do?), and still others clarify governance and accountability (who decides what?). Don't just memorize a list of nine or ten components—know which category each belongs to and how they work together to set a project up for success. That conceptual understanding is what separates passing scores from failing ones.
These components answer the fundamental question: Why does this project exist, and how will we know if it succeeded? They connect the project to organizational strategy and establish the criteria against which everything else will be measured.
Compare: Purpose/Justification vs. Objectives—both explain "why," but purpose addresses organizational need while objectives specify measurable targets. If an exam question asks what prevents disputes at project closure, success criteria is your answer.
These components answer: What's in, what's out, and what will we produce? They prevent the most common project killer—scope creep—by establishing clear limits before execution begins.
Compare: Scope vs. Deliverables—scope defines the work boundaries, while deliverables are the actual outputs produced within those boundaries. Scope is about what we're doing; deliverables are what we're producing.
These components acknowledge reality: What limitations and uncertainties must we navigate? They demonstrate mature planning by identifying factors that could derail the project before they become crises.
Compare: Constraints vs. Risks—constraints are known limitations you must work within, while risks are uncertain events that may or may not occur. Both require management, but constraints are definite and risks are probabilistic.
These components address: How much will this cost, and when will it happen? They establish the financial and temporal parameters that govern project execution.
Compare: Budget vs. Timeline—both represent baselines in the charter, but budget controls resource consumption while timeline controls duration. On the exam, remember that charter-level versions are high-level summaries, not detailed plans.
These components answer: Who has power, and who has interest? They establish the human infrastructure of decision-making and accountability that makes project execution possible.
Compare: Stakeholders vs. PM Authority—stakeholder identification tells you who cares, while PM authority tells you who decides. The charter must explicitly grant PM authority; without it, the PM has responsibility without power—a recipe for failure.
| Concept | Best Examples |
|---|---|
| Strategic Alignment | Purpose/Justification, Objectives, Success Criteria |
| Boundary Definition | Scope, Deliverables, Acceptance Criteria |
| Constraint Management | Time/Budget/Resource Constraints, Assumptions |
| Uncertainty Management | High-Level Risks, Assumptions Requiring Validation |
| Financial Planning | Budget Summary, Cost Categories |
| Schedule Planning | Timeline, Milestones, Gantt Charts |
| Governance Structure | PM Authority, Stakeholder Roles, Decision Rights |
| Baseline Establishment | Scope, Budget, Schedule (collectively) |
Which two charter components work together to prevent scope creep, and how do they differ in function?
If a stakeholder disputes whether the project succeeded at closure, which charter component should resolve that dispute—and why is it more effective than the purpose statement?
Compare constraints and assumptions: both appear in the same charter section, but how do they differ in terms of certainty and how you manage them?
An FRQ asks you to explain why a project failed due to unclear authority. Which charter component was likely missing or poorly defined, and what specific elements should it have included?
A project has a detailed scope statement but stakeholders still argue about what the project should deliver. Which additional charter component would clarify expectations, and what specific elements would it contain?