This project charter covers everything you need to know. Article updated in March 2026 for the PMBOK® Guide — Eighth Edition.
Have you ever been involved in a project that started without a formal authorization document — and three months later, no one knew for certain who the sponsor was, what the approved budget was, or how far the project manager’s authority extended? Perhaps the project moved forward based on an email, a verbal agreement, or a PowerPoint presentation that “everyone saw.” When conflicts arose — and they always do — there was no official record to consult. This scenario is more common than it should be, and the root cause is always the same: the absence of a well-crafted Project Charter.
The Project Charter is the most important output of the “Initiate Project or Phase” process in the Governance Domain of PMBOK 8. It is not merely a bureaucratic form: it is the document that officially brings the project to life, grants authority to the project manager, and establishes the boundaries within which all decisions will be made. Without it, the project exists informally — and everything informal is fragile.
By the end of this guide, you will know exactly what the Project Charter is, how to create one with quality, which elements are mandatory in PMBOK 8, how to tailor it for different contexts, and how to avoid the mistakes that undermine most charters circulating in organizations.
In this article you will find:
- What the Project Charter is and why it is classified as an output — not a tool
- Where it is produced and which processes consume it as an input
- Practical filled-in examples from two different industries
- Quality criteria to validate whether your charter is complete
- How the Charter relates to the Project Canvas — the PMBOK 8 novelty
- Tailoring for predictive, agile, and hybrid environments
- The 5 most common errors and how to avoid them
- Quick application checklist with 7 items
- PMBOK 6 vs. 8 comparison — what changed
1. What Is the Project Charter
The Project Charter is the document issued by the sponsor that formally authorizes the existence of a project and grants the project manager the authority needed to apply organizational resources to project activities.
In the PMBOK 8 framework, the Project Charter is classified as an output — the tangible result of the “Initiate Project or Phase” process, which belongs to the Governance Domain. This distinction matters: the charter is not a tool or technique that you apply; it is the concrete product that results from applying tools and techniques during initiation.
The charter functions as the “social contract” between the sponsor, the project manager, and the organization. It answers the fundamental questions:
- Why does this project exist? (purpose and justification)
- What is expected to be achieved? (measurable objectives)
- Who is involved? (sponsor, project manager, key stakeholders)
- How much will it cost — in estimated terms? (pre-approved financial resources)
- When are the main milestones? (summary milestone schedule)
- What are the initial risks? (high-level risks)
- What is the project manager’s authority? (decision-making level)
Mandatory elements of the Project Charter in PMBOK 8:
| Element | Description |
|---|---|
| Purpose and justification | Why the project is needed. Alignment with organizational strategy. |
| Measurable objectives (SMART) | Specific, Measurable, Achievable, Relevant, and Time-bound. |
| High-level requirements | Initial needs and expectations of stakeholders. |
| High-level risks | Threats and opportunities identified before detailed planning. |
| Summary milestone schedule | Key milestones with estimated dates. |
| Pre-approved financial resources | Estimated budget or budget range authorized by the sponsor. |
| Key stakeholders | List of primary stakeholders and their roles. |
| Project manager name and authority | Formal identification and level of authority over resources, decisions, and budget. |
| Sponsor name and authority | Who authorizes the project and holds escalated decision-making power. |
| Assumptions and constraints | Factors considered true without proof (assumptions) and known limitations (constraints). |
| Sustainability considerations | Social, environmental, and long-term impacts that the project must consider. (New in PMBOK 8) |
Important note: The Project Charter is a summary-level document. It does not replace the Project Management Plan, which comes later with full detail. The charter authorizes; the plan details.
2. Why the Project Charter Is Important
The Project Charter fulfills functions that no other project document can. It is the only artifact that:
- Formally authorizes the project. Without the charter, the project does not officially exist. Any work performed before formalization is “at your own risk” — without official resource allocation and without organizational backing.
- Grants authority to the project manager. The charter is the document that states, in clear terms, what the PM can and cannot decide. Without it, the PM has no formal mandate — and every decision requires ad hoc approval.
- Establishes the sponsor’s commitment. The sponsor signs the charter, committing to the resources, budget, and executive support required. This commitment is the foundation for project governance.
- Creates a stable reference point. Throughout the project, conflicts, doubts, and priority disputes will arise. The charter is the reference document for resolving ambiguities: “What did the sponsor authorize? What was the original scope? What were the assumptions?”
- Feeds all subsequent processes. The charter is an input to virtually every planning process in PMBOK 8. Without it, planning starts without a foundation.
What happens when the Project Charter is poorly done — or not done at all:
- The project manager has no clear mandate, creating excessive dependence on the sponsor for operational decisions
- Stakeholders hold divergent expectations because there was no formal alignment at the outset
- The budget and schedule are continuously questioned because they were never formally approved
- The project is vulnerable to cancellation or reorganization because no formal record exists of its authorization
- Scope changes are impossible to control because there is no baseline for comparison
In agile projects, the charter is equally relevant. Even when the team works with Product Backlogs and sprints, the initiation moment requires someone — with authority — to say: “This project exists, this is the purpose, this is the available budget.” The format may be different (a canvas, a lean document), but the function is the same.
3. Where It Is Produced: the “Initiate Project or Phase” Process
The Project Charter is the primary output of the “Initiate Project or Phase” process, which belongs to the Governance Domain in PMBOK 8.
3.1 — The source process
The “Initiate Project or Phase” process is the formal starting point of any project or project phase. It transforms a business need, an opportunity, or a strategic demand into a formally authorized project.
Inputs, Tools and Techniques, Outputs (ITTO):
| Inputs | Tools and Techniques | Outputs |
|---|---|---|
| Business documents (Business Case, Benefits Management Plan) | Expert judgment | Project Charter |
| Agreements (contracts, memoranda) | Data gathering (brainstorming, interviews) | Assumption log |
| Enterprise environmental factors | Interpersonal and team skills (facilitation, conflict management) | |
| Organizational process assets | Project Canvas |
3.2 — How inputs are transformed into the charter
The typical development flow is:
- The Business Case provides the economic and strategic justification — why the project deserves investment.
- Agreements (contracts, SOWs, memoranda) provide the formal requirements and commitments with clients or partners.
- Enterprise environmental factors (organizational culture, regulations, market conditions) define constraints and assumptions.
- Organizational process assets (templates, lessons learned, internal policies) provide the model and standards for the charter.
- Expert judgment and the Project Canvas help synthesize all this information into a cohesive and approvable document.
3.3 — The role of the Project Canvas as a complementary tool
An important novelty in PMBOK 8 is the prominence given to the Project Canvas as a tool of the “Initiate Project or Phase” process. The Canvas and the Charter complement each other:
| Aspect | Project Charter | Project Canvas |
|---|---|---|
| Format | Formal, text-based, multi-page document | Visual, single-page, collaborative boards |
| Purpose | Formally authorize the project and record official decisions | Facilitate collaborative discussion and visual alignment |
| Audience | Sponsor, PMO, organizational governance | Project team, operational stakeholders |
| When used | Formal sign-off before planning begins | Alignment workshop during initiation |
| Level of detail | Summary but complete — all mandatory elements | Condensed and visual — focused on connections between elements |
In practice: use the Project Canvas as a collaborative construction tool during the initiation workshop. Then formalize the decisions in the Project Charter. The Canvas is the visual draft; the Charter is the official record.
4. Practical Example: Filled-In Project Charter
Below are two completed Project Charter examples — from different industries — to demonstrate how the document adapts to context.
4.1 — Example: Technology Sector — ERP System Implementation
| Section | Content |
|---|---|
| Project name | SAP S/4HANA ERP Implementation — Finance and Procurement Modules |
| Purpose and justification | Replace the legacy system (TOTVS Protheus) that cannot handle the transaction volume after the merger with Beta S.A. The new ERP will enable real-time financial consolidation and a 40% reduction in the monthly closing cycle. |
| Measurable objectives (SMART) | 1) Reduce the accounting closing cycle from 15 to 9 business days by Dec/2027. 2) Automate 80% of recurring purchase orders by Mar/2027. 3) Achieve 95% system adoption among key users within 90 days post go-live. |
| High-level requirements | Bank integration via API; historical data migration (5 years); GDPR/LGPD compliance; multi-company and multi-warehouse support. |
| High-level risks | 1) Resistance to change from the finance team (high). 2) Delays in legacy data migration (medium). 3) Unavailability of certified SAP consultants during the period (medium). |
| Milestone schedule | Blueprint: Mar/2027 | Realization: Jun/2027 | Integrated Testing: Sep/2027 | Go-live: Nov/2027 | Stabilization: Dec/2027 |
| Pre-approved budget | $840,000 (Licenses: $300,000 | Consulting: $360,000 | Infrastructure: $100,000 | Contingency: $80,000) |
| Key stakeholders | CFO (sponsor), IT Director (co-sponsor), Procurement Manager, Accounting Coordinator, Change Management Team |
| Project manager | Ana Souza, PMP — full authority over schedule and internal team allocation; limited authority over budget (approvals above $10,000 require CFO sign-off) |
| Sponsor | Carlos Mendes, CFO — authority to approve scope changes, budget modifications, and executive resource escalation |
| Assumptions | 1) The IT team will be 100% available during the realization phase. 2) Legacy data has minimum quality for migration. 3) The SAP license will be contracted by Feb/2027. |
| Constraints | 1) Go-live mandatory before fiscal year-end 2027. 2) Internal team limited to 8 professionals. 3) Cloud-only infrastructure (corporate policy). |
| Sustainability considerations | Cloud migration reduces on-premise server energy consumption by 60%. The procurement module will include supplier traceability with ESG criteria. Training will be 100% digital, eliminating travel. |
4.2 — Example: Construction Sector — Hospital Wing Expansion
| Section | Content |
|---|---|
| Project name | Emergency Wing Expansion — North Regional Hospital |
| Purpose and justification | The current emergency wing serves 120 patients/day, but the projected demand for 2028 is 200 patients/day. The expansion is necessary to prevent overcrowding, comply with health authority regulations, and reduce average wait time from 4 hours to 1 hour 30 minutes. |
| Measurable objectives (SMART) | 1) Increase service capacity from 120 to 220 patients/day by Jun/2028. 2) Reduce average wait time from 4 hours to 1 hour 30 minutes. 3) Obtain occupancy permit and health authority approval with no outstanding issues. |
| High-level requirements | 1,200 m2 expansion with 15 new observation beds; 4 procedure rooms; medical gas system; integrated monitoring center; universal accessibility compliance. |
| High-level risks | 1) Interference with existing wing operations during construction (high). 2) Delays in regulatory approvals (medium). 3) Construction material price fluctuation (medium). |
| Milestone schedule | Detailed design: Mar/2027 | Foundation: Jun/2027 | Structure: Oct/2027 | MEP installations: Jan/2028 | Finishing: Apr/2028 | Occupancy permit: May/2028 | Inauguration: Jun/2028 |
| Pre-approved budget | $2,500,000 (Construction: $1,700,000 | Equipment: $500,000 | Design and permits: $160,000 | Contingency: $140,000) |
| Key stakeholders | Municipal Health Secretary (sponsor), Clinical Director, Lead Civil Engineer, Health Authority, Fire Department, Local community |
| Project manager | Roberto Lima, Civil Engineer — full authority over construction schedule and subcontractor hiring; limited authority over medical equipment specifications (requires Clinical Director approval) |
| Sponsor | Dr. Marcia Alves, Municipal Health Secretary — authority to approve budget changes and contract amendments |
| Assumptions | 1) The adjacent lot will be acquired by Jan/2027. 2) The detailed design will be completed on schedule. 3) There will be no construction industry strikes during the period. |
| Constraints | 1) Construction must not disrupt the existing emergency wing operations. 2) Noisy work hours: 7 AM–5 PM (internal regulation). 3) Public budget — no cost overrun above 25% permitted (procurement law). |
| Sustainability considerations | Design includes rainwater harvesting system, solar panels for water heating, environmentally certified construction materials, and construction waste management in compliance with environmental regulations. |
4.3 — Quality criteria: how to verify the charter is complete
Before submitting the Project Charter for sponsor approval, verify:
| Criterion | Verification Question | Expected Result |
|---|---|---|
| Completeness | Are all 11 mandatory elements filled in? | Yes — no blank fields or “to be determined” |
| Objectivity | Are the objectives SMART (Specific, Measurable, Achievable, Relevant, Time-bound)? | Each objective has a metric and a deadline |
| Clear authority | Is the PM’s authority level explicit — including limits? | Yes — autonomous decisions and escalations documented |
| Strategic alignment | Does the justification connect the project to a strategic objective or business need? | Traceability to the Business Case |
| Assumptions vs. constraints | Are assumptions and constraints separated and clearly identified? | No assumption disguised as a constraint and vice versa |
| Sustainability | Have sustainability considerations been evaluated — even if minimal? | At least one ESG consideration documented |
| Formal approval | Has the sponsor reviewed and formally approved the document? | Date and signature on record |
5. When to Validate or Revise the Project Charter
The Project Charter is not a “file-and-forget” document that you create once and never consult again. It has a life cycle:
- Creation: during the “Initiate Project or Phase” process
- Approval: formal sponsor sign-off before detailed planning begins
- Ongoing consultation: mandatory reference during planning and whenever there is doubt about authority, scope, or assumptions
- Revision: when significant changes alter the project’s justification, objectives, or budget
- Reissuance: at the start of each new phase (in multi-phase projects), the charter may be updated or a new phase charter may be issued
Recommended review gates:
- After planning is complete: Verify whether the charter’s assumptions remain valid in light of the detailed plan.
- At each phase gate: Confirm that the objectives and justification remain relevant before authorizing the next phase.
- After significant scope changes: If an approved change fundamentally alters the project (more than 20% of budget or scope), the charter should be revised.
- At project closure: Compare results achieved against the charter’s original objectives as part of the success evaluation.
6. Who Consumes the Project Charter: How It Feeds Other Processes
The Project Charter is one of the most widely consumed outputs in PMBOK 8. It serves as an input to processes across all 7 performance domains. This happens because the charter contains the foundational information that each domain needs to begin its own planning.
6.1 — Processes that consume the Project Charter as input
| Domain | Processes That Use the Charter | What They Extract |
|---|---|---|
| Scope | Plan Scope Management, Collect Requirements, Define Scope | High-level requirements, objectives, assumptions |
| Schedule | Plan Schedule Management, Define Activities | Summary milestones, deadline constraints |
| Finance | Plan Cost Management, Estimate Costs | Pre-approved budget, financial constraints |
| Risk | Plan Risk Management, Identify Risks | High-level risks, assumptions (risk sources) |
| Resources | Plan Resource Management | PM’s authority over resources, availability assumptions |
| Stakeholders | Identify Stakeholders | Key stakeholders list, sponsor |
| Governance | Develop the Project Management Plan | All elements — the charter is the plan’s foundation |
6.2 — How the charter generates value beyond planning
The Project Charter is not only useful as an “input” to formal processes. It generates practical value in day-to-day situations:
- Resolving priority conflicts: When two stakeholders disagree about what is a priority, the charter provides the reference: “The objective authorized by the sponsor is X. Decisions must align with that objective.”
- Onboarding new team members: When a new member joins the team, the charter is the first document they should read to understand the project.
- Executive communication: When the PM needs to report to senior management, the charter provides the executive-level language — objectives, budget, justification — that executives expect to hear.
- Protection against scope creep: When someone requests a change, the question is: “Is this change aligned with the charter’s objectives?” If not, it requires formal approval.
- Success evaluation at closure: At the end of the project, success is measured against the charter’s objectives — not against informal expectations.
7. Tailoring: How to Adapt the Project Charter to Context
PMBOK 8 reinforces that tailoring is not optional — it is a project manager’s responsibility. The Project Charter must be adapted according to the project context. A 15-page charter for a 2-sprint project is just as problematic as a half-page charter for a $50 million construction project.
7.1 — Predictive (waterfall)
| Aspect | Recommendation |
|---|---|
| Format | Formal, complete, signed document. Typically 3–8 pages. |
| Level of detail | High. All mandatory elements filled in with the maximum available information. |
| Approval | Formal — sponsor signature, often with additional PMO or governance committee approval. |
| Revision | At phase gates. Changes require formal change control. |
| Sustainability | Dedicated section with documented ESG criteria. |
When to use this format: Construction projects, ERP implementations, regulated projects (healthcare, finance, government), projects with budgets exceeding $1 million.
7.2 — Agile
| Aspect | Recommendation |
|---|---|
| Format | Lean document (1–2 pages) or visual Project Canvas. Can be digital (Confluence, Notion, Miro). |
| Level of detail | Summary. Focus on product vision, value objectives, and investment limits. |
| Approval | Can be less ceremonial — Product Owner and sponsor approval. |
| Revision | At each PI Planning (SAFe) or quarterly. The charter evolves with the product. |
| Sustainability | Integrated into the Definition of Done or story acceptance criteria. |
When to use this format: Digital products, startups, development squads, projects with high requirements uncertainty.
7.3 — Hybrid
| Aspect | Recommendation |
|---|---|
| Format | Formal charter at the project level + Canvas for each phase or agile stream. |
| Level of detail | Moderate in the global charter. Progressive elaboration by phase. |
| Approval | Global charter approved by the sponsor. Phase Canvas approved by the PM and Product Owner. |
| Revision | Global charter at gates; Canvas at agile planning cycles. |
| Sustainability | Defined in the global charter and detailed per phase as applicable. |
When to use this format: Projects that combine predictive phases (infrastructure, procurement) with agile phases (software development, product design).
8. Interactions with Other Outputs and Domains
The Project Charter does not exist in isolation. It connects to a network of documents and outputs that together form the project’s documentary foundation.
8.1 — Documents the charter complements or precedes
| Document | Relationship with the Charter |
|---|---|
| Business Case | The Business Case justifies the investment; the charter authorizes execution. The charter references the Business Case but does not replace it. |
| Project Management Plan | The charter is an input to the plan. The plan details what the charter summarized. Conflicts between the two should be resolved with the sponsor. |
| Project Scope Statement | The Scope Statement elaborates on the high-level requirements that the charter only listed. Both share scope information but differ in depth and timing. |
| Stakeholder Register | The charter lists key stakeholders; the Register details them with power, interest, and engagement strategy analysis. |
| Risk Register | The charter identifies high-level risks; the Risk Register analyzes them qualitatively and quantitatively. |
| Assumption Log | Produced alongside the charter in the “Initiate Project or Phase” process. Documents assumptions and constraints in detail. |
8.2 — Interactions across domains
- Governance to Scope: The charter defines the objectives that the scope must detail and deliver.
- Governance to Schedule: The summary milestones in the charter become the foundation of the project timeline.
- Governance to Finance: The pre-approved budget in the charter is the starting point for detailed cost estimation.
- Governance to Risk: The high-level risks in the charter feed the risk identification process.
- Governance to Resources: The PM’s authority defined in the charter determines how resources will be managed.
- Governance to Stakeholders: The key stakeholders in the charter are the starting point for full stakeholder analysis.
9. Practical Tips for Creating a High-Quality Project Charter
- Start with “why,” not “what.” Before listing deliverables and milestones, clearly document the project’s justification. If you cannot explain in two sentences why the project deserves to exist, the charter is not ready.
- Use the Project Canvas before writing. Gather key stakeholders in a 2–3 hour workshop. Use the Project Canvas to visually map the project. Then formalize in the charter. This approach reduces rework and increases buy-in.
- Write truly SMART objectives. “Improve operational efficiency” is not a SMART objective. “Reduce average order processing time from 48 hours to 24 hours by December 2027” is. If the objective lacks a number and a date, it is not SMART.
- Make the PM’s authority level explicit. It is not enough to write “the project manager is John Smith.” Write: “John Smith has authority to approve schedule changes of up to 2 weeks and expenditures of up to $10,000 without sponsor approval. Decisions exceeding these thresholds require formal approval.”
- Document assumptions as hypotheses to be validated. PMBOK 8 reinforces that assumptions are factors “considered true without proof for planning purposes.” Treat each assumption as a hypothesis: record it, monitor it, and have a plan in case it proves false.
- Do not confuse constraints with assumptions. “The budget is $500,000” is a constraint — it is real. “The vendor will deliver by March” is an assumption — it is a hypothesis. Mixing the two creates confusion in planning.
- Include sustainability considerations from the start. PMBOK 8 includes sustainability as one of its 6 principles. Even in projects where environmental impact seems minimal, document at least one consideration: energy consumption, waste management, social impact, accessibility.
- Keep the charter accessible — not in a drawer. Publish the charter in a location where the entire team and key stakeholders can access it. SharePoint, Confluence, Google Drive — anywhere, as long as it is accessible. A charter that nobody reads does not fulfill its function.
10. Common Errors and How to Avoid Them
Error 1 — Confusing the Project Charter with the Project Management Plan
Why it happens: The PM tries to include in the charter all the detail that belongs in the plan — a detailed WBS, a schedule with activities, a budget broken down by work package. The result is a lengthy, time-consuming document that delays project authorization.
How to avoid it: The charter is summary-level. It should fit in 3–8 pages (predictive) or 1–2 pages (agile). If the document exceeds 10 pages, you are planning — not initiating. Move the detail to the plan and keep the charter at the executive level.
Error 2 — Creating the charter without involving the sponsor
Why it happens: The PM drafts the charter alone, based on informal conversations, and presents it to the sponsor “for signature.” The sponsor signs without reading, and the charter does not reflect the organization’s true expectations and priorities.
How to avoid it: The charter should be developed jointly with the sponsor — or, at a minimum, validated section by section. The sponsor is the one authorizing the project; they need to agree with every element of the charter, not just the signature line.
Why it happens: The “PM authority” field is filled in generically (“authority to manage the project”) or is simply omitted. The result: the PM does not know what they can decide independently, and the sponsor is called upon for operational decisions.
How to avoid it: Define concrete limits: maximum expenditure without approval, tolerable delay days before escalation, types of changes the PM can approve alone versus those requiring a committee. The clearer the limits, the fewer the conflicts.
Error 4 — Ignoring assumptions and constraints
Why it happens: The team fills in the charter focusing on objectives and scope, and leaves assumptions and constraints as “to be determined” or blank. The consequence: unidentified risks, planning based on implicit suppositions, and surprises during execution.
How to avoid it: For each objective and milestone in the charter, ask: “What needs to be true for this to work?” (assumptions) and “What limits our ability to do this?” (constraints). Document at least 3 assumptions and 3 constraints.
Error 5 — Treating the charter as a “one and done” document
Why it happens: The charter is created, signed, and filed away. No one consults it again. When priority conflicts or scope disputes arise, the team tries to resolve them based on emails, meeting minutes, and memory — not the official document.
How to avoid it: Include the charter in the phase gate review agenda. Reference it explicitly in status meetings. When a scope dispute arises, ask: “What does the charter say?” The charter is a living document — not just a kickoff ritual.
11. Quick Application Checklist
Use these 7 items as a quick verification before submitting the Project Charter for approval:
- Is the project justification clear and connected to an organizational strategic objective — not merely to an operational demand?
- Are the objectives SMART — each with a metric, deadline, and accountable party — or are there generic objectives like “improve efficiency”?
- Is the project manager’s authority level documented with concrete limits (financial, schedule, scope)?
- Have assumptions and constraints been identified, correctly separated, and validated with the sponsor?
- Have high-level risks been identified — including at least one risk related to charter assumptions?
- Have sustainability considerations been evaluated — even if the impact is minimal?
- Has the sponsor reviewed, validated, and formally approved the document — not merely “glanced at it”?
12. Comparison: Project Charter in PMBOK 6 vs. PMBOK 8
The original version of this article was based on PMBOK 6. The table below shows the main differences in the Project Charter approach between the two editions:
| Aspect | PMBOK 6 (2017) | PMBOK 8 (2025) |
|---|---|---|
| Classification | Output of the “Develop Project Charter” process in the Integration Knowledge Area | Output of the “Initiate Project or Phase” process in the Governance Domain |
| Organization | 10 Knowledge Areas, 49 processes, 5 Process Groups | 7 Performance Domains, 40 processes with ITTOs, 6 principles |
| Source process | “Develop Project Charter” (Initiating Process Group) | “Initiate Project or Phase” (Governance Domain) |
| Process tools | Expert judgment, data gathering, interpersonal skills | Same + Project Canvas as a formal tool |
| Mandatory elements | Objectives, requirements, risks, milestones, budget, PM, sponsor, assumptions, constraints | Same + sustainability considerations |
| Sustainability | Not mentioned as part of the charter | Integrated as a mandatory element, aligned with the principle “Integrate sustainability across all project areas” |
| Relationship with Canvas | Project Canvas was not referenced | Canvas is a formal tool of the initiation process, complementary to the charter |
| Guiding principles | No explicit principles in PMBOK 6 | 6 principles guide development: holistic view, value focus, quality, diligent leadership, sustainability, empowerment |
| Tailoring | Mentioned as a general recommendation | Mandatory — the charter must be adapted to context (predictive, agile, hybrid) |
| Focus | Authorization document with focus on process compliance | Authorization document with focus on value delivery and adaptive governance |
What this means in practice: If you were already creating good project charters under PMBOK 6, the foundation remains solid. The PMBOK 8 changes do not invalidate what you know — they add: sustainability as a mandatory element, the Project Canvas as a complementary tool, and a more value-oriented and less process-compliance-oriented perspective. Additionally, the charter is now positioned within a domain (Governance) instead of a knowledge area (Integration), which reinforces its role as a governance instrument — not merely an integration tool.
Conclusion
The Project Charter remains, in PMBOK 8, the most important document of the initiation phase. Without it, the project is informal, authority is ambiguous, and expectations are divergent. When done well, the project is born on a solid foundation.
Three essential takeaways for practice:
- The charter is the project’s birth certificate. It formally authorizes the project’s existence, grants authority to the project manager, and establishes the boundaries for scope, cost, and schedule. Without a charter, there is no project — only intentions.
- The charter is an output, not a tool. It is the concrete product of the “Initiate Project or Phase” process (Governance Domain). Tools such as expert judgment and the Project Canvas are used to create it. The charter is the result.
- The charter requires tailoring and ongoing updates. In PMBOK 8, the charter must be adapted to context (predictive, agile, hybrid), include sustainability considerations, and be reviewed at phase gates — not filed away after signature.
Concrete next step: Open the Project Charter for your current project (or the last project you managed). Check whether it contains the 11 mandatory elements listed in Section 1 of this article. If any field is blank, generic, or outdated, you have identified your first improvement action. Start with the PM’s authority and sustainability considerations — the two most frequently neglected elements.
Free resources to apply now
- Template: Project Canvas (PMBOK 8) — use as a collaborative tool before drafting the charter
- Project Scope Statement — the next step after the charter: detailing the authorized scope
See all PMBOK 8 articles in the Complete Index
🇧🇷 Leia este artigo em português
Leia em Portugues: Versao em Portugues deste artigo
Call to Action:
References
PMBOK Guide 8: The New Era of Value-Based Project Management. Available at: https://projectmanagement.com.br/pmbok-guide-8/
Disclaimer
This article is an independent educational interpretation of the PMBOK® Guide – Eighth Edition, developed for informational purposes by ProjectManagement.com.br. It does not reproduce or redistribute proprietary PMI content. All trademarks, including PMI, PMBOK, and Project Management Institute, are the property of the Project Management Institute, Inc. For access to the complete and official content, purchase the guide from Amazon or download it for free at https://www.pmi.org/standards/pmbok if you are a PMI member.
