Process – Initiate Project or Phase | PMBOK 8 (2025)

This initiate project or phase covers everything you need to know. Article updated in March 2026 for the PMBOK® Guide — Eighth Edition.

Initiate Project or Phase: The Process That Determines Whether Your Project Starts Strong or Is Doomed from Day One (PMBOK 8)

Formerly: Develop Project Charter (PMBOK 6)

Picture this scenario: the executive board approved the project on Friday, and by Monday the team is already executing. Nobody knows exactly who the project manager is. The objectives were discussed in an informal meeting but never documented. The assumptions exist only in the sponsor’s head. Three months later, the project has uncontrolled scope, a blown budget, and a team that has no idea why they are doing what they are doing. This scenario is not the exception — it is the predictable result of skipping formal initiation.

In PMBOK 8, the Initiate Project or Phase process is Process 1 of the Governance Domain — and it exists for a simple reason: without formal authorization, without alignment of expectations, and without documented assumptions, the project has no foundation. It is like building a high-rise without a foundation: it may appear to be progressing, but collapse is only a matter of time.

In this comprehensive guide you will find:

• What it is — the Initiate Project or Phase process and where it fits in PMBOK 8
• Why use it — and what happens when you don’t
• What changed — a comparison between PMBOK 6 and PMBOK 8
• Full ITTO — Inputs, Tools & Techniques, and Outputs in a detailed table
• Step-by-step guide to applying the process from scratch
• When to apply it — scenarios and triggers that indicate the need for formal initiation
• Practical examples in IT, Construction, and Marketing
• Shortcuts, templates, and tips to accelerate initiation
• 5 common mistakes — and how to avoid them
• Tailoring for Predictive, Agile, and Hybrid contexts
• Interactions with other processes and domains
• Quick-application checklist with 7 items you can use today

1. What Is the Initiate Project or Phase Process

Initiate Project or Phase is the process that formally authorizes the start of a project or of a phase within an existing project. It defines assumptions, expectations, and constraints, and — critically — identifies and appoints the project manager with recognized authority to allocate resources and make decisions.

In PMBOK 8, this is Process 1 of the Governance Domain — the first of 9 processes that make up the project governance framework. This is no coincidence: governance begins with formal authorization. Without it, everything that follows — planning, execution, monitoring — operates without legitimacy.

The process produces two fundamental outputs:

• Project Charter — the document that formalizes the existence of the project, its objectives, constraints, high-level milestones, and the project manager’s authority
• Assumption Log — the document that captures all suppositions, conditions, and limitations accepted as true at the time of initiation, but that need to be validated throughout the project

A notable addition in PMBOK 8 for this process is the inclusion of the Project Canvas as a tool and technique. The Canvas allows the team to visualize, on a single page, the essential elements of the project — purpose, value, stakeholders, risks, assumptions, and deliverables — facilitating rapid alignment among all participants.

Difference between initiating a project and initiating a phase

The process applies to both scenarios, but with differences in scope:

2. What Changed: PMBOK 6 vs. PMBOK 8

The table below summarizes the key differences between the former Develop Project Charter process (PMBOK 6) and the current Initiate Project or Phase process (PMBOK 8):

In essence, PMBOK 8 broadened and modernized this process. The shift from “Develop Project Charter” to “Initiate Project or Phase” reflects a more strategic view of initiation — it is not just about producing a document, but about formally authorizing and aligning the project or phase with organizational governance.

3. Why Use the Initiate Project or Phase Process

Formal initiation is not bureaucracy — it is the foundation upon which the entire project will be built. When properly executed, it generates concrete, measurable benefits:

Direct benefits

• Formal legitimacy: The project officially exists within the organization. Resources can be allocated, contracts can be signed, and decisions have documented backing.
• Alignment of expectations: The sponsor, project manager, and key stakeholders start from the same documented baseline — objectives, constraints, assumptions, and success criteria.
• Clear definition of authority: The project manager is formally appointed, with a defined scope of authority. There is no ambiguity about who decides what.
• Traceability from day zero: Assumptions are documented, initial decisions are recorded, and the project is born with a history that can be audited.
• Foundation for planning: Without the Project Charter, planning has no reference point. It is like trying to plan a trip without knowing the destination.
• Phase gate control: By applying initiation at the phase level, the organization creates formal decision points — continue, adjust, or cancel — before committing additional resources.

What happens when the process is skipped

The consequences of skipping or underestimating initiation are predictable and well-documented:

• Uncontrolled scope: Without documented objectives, any request appears legitimate. Scope creep starts on day 1.
• Authority conflicts: Without formal appointment of the project manager, multiple people attempt to make decisions, causing conflicts and paralysis.
• Invisible assumptions: Everyone assumes different things — deadlines, budgets, resource availability — but nobody documented them. When reality diverges, there is no reference for adjustment.
• Planning rework: The team plans based on unvalidated suppositions. When the sponsor finally reviews, they discover the entire plan is misaligned with the original expectation.
• Late cancellation: Projects that should never have been started consume resources for months before anyone realizes there was no viability from the beginning.

The PMBOK 8 principle “Focus on Value” reinforces this need: if the project does not demonstrate value from initiation, it should not consume resources. Formal initiation is the first value filter.

4. Inputs, Tools and Techniques, and Outputs (ITTO)

The table below presents the full ITTO of the Initiate Project or Phase process, as defined in PMBOK 8:

Detailed Inputs

Business documents: These include the Business Case (the financial and strategic justification for the project), the Benefits Management Plan (how benefits will be measured and realized), and the feasibility study. They are the basis for determining whether the project should exist.

Agreements: Client contracts, memoranda of understanding, letters of intent, or internal agreements between departments. When the project originates from a contractual demand, the agreement is the most critical input.

Enterprise Environmental Factors (EEFs): External and internal conditions that influence the project — organizational culture, existing governance structure, market conditions, regulations, and available infrastructure.

Organizational Process Assets (OPAs): Existing templates, lessons learned from previous projects, internal policies, knowledge repositories, and documentation standards.

Detailed Tools and Techniques

Expert judgment: Consultation with experts who possess technical, business, or management knowledge relevant to defining the project. This may include external consultants, senior managers, technical specialists, or professionals with experience in similar projects.

Data gathering: Techniques such as brainstorming (generating ideas for objectives and assumptions), interviews (with the sponsor and key stakeholders), and benchmarking (comparison with similar projects already completed).

Interpersonal and team skills: These include conflict management (aligning divergent expectations among stakeholders), facilitation (conducting productive initiation meetings), and meeting management (structuring the kickoff efficiently).

Meetings: Alignment meetings with the sponsor, kickoff meetings, sessions for defining assumptions and constraints, and gate reviews for phase approval.

Responsibility Assignment Matrix: A tool that defines who is Responsible, who Approves (Accountable), who is Consulted, and who is Informed (RACI) for the project’s key activities and decisions. In the context of initiation, it defines the initial governance structure.

Project Canvas: One of the notable additions in PMBOK 8. It is a visual tool that allows the team to map, on a single page, the essential elements of the project: purpose, justification, stakeholders, deliverables, assumptions, constraints, risks, and success criteria. It functions as a “structured mind map” that facilitates rapid alignment among all initiation participants.

Detailed Outputs

Project Charter: The document that formally authorizes the project or phase. It should contain, at minimum: purpose/justification, measurable objectives, high-level requirements, assumptions and constraints, initial risks, milestone schedule, summary budget, success criteria, the project manager’s name and authority, and the sponsor’s name and authority.

Assumption Log: A document that lists all assumptions made during initiation — conditions accepted as true but not yet confirmed. Each assumption should be accompanied by its source, potential impact if it does not hold true, and the person responsible for validating it. The log is a living document: it should be reviewed and updated throughout the entire project.

5. How to Apply the Process Step by Step

The following step-by-step guide can be adapted based on project complexity, but the logical sequence applies to any context:

Step 1 — Gather and analyze the business documents

Before any meeting, collect and review the Business Case, the feasibility study, the Benefits Management Plan, and any existing contractual agreements. Ask yourself:

• Is the project’s justification clear and quantifiable?
• Are the expected benefits defined with metrics?
• Is there documented technical and financial feasibility?
• Do contractual agreements impose constraints that affect scope or schedule?

Practical tip: If the Business Case does not exist or is too generic, request it from the sponsor before proceeding. Starting a project without a clear justification is planting the seed of failure.

Step 2 — Identify and consult key stakeholders

Map out the people who influence or are influenced by the project. In this initial phase, focus on high-impact stakeholders:

• Sponsor
• Client or client representative
• Directors of impacted departments
• Relevant technical specialists
• Compliance or regulatory representatives (when applicable)

Conduct individual interviews or an alignment meeting to capture the expectations, constraints, and assumptions of each key stakeholder.

Step 3 — Fill in the Project Canvas

Use the Project Canvas as a facilitation tool in a collaborative session. In a meeting of 60 to 90 minutes, complete the following blocks:

• Purpose: Why does this project exist?
• SMART Objective: What will be achieved, with what metric, by when?
• Benefits: What value will be generated for the organization and its stakeholders?
• Primary product/deliverable: What will be produced?
• Key stakeholders: Who is involved and in what role?
• Assumptions: What are we assuming to be true?
• Constraints: What are the non-negotiable limits (schedule, budget, regulations)?
• Initial risks: What could go wrong?
• High-level milestones: What are the critical dates or events?

The Canvas serves as a visual draft that will later be formalized in the Project Charter. Its advantage is the speed of alignment — everyone sees the same page, literally.

Step 4 — Establish the initial Responsibility Assignment Matrix

Define, at minimum, the following responsibilities:

This matrix will be expanded during planning, but its initial version is essential so that everyone knows who is who from day one.

Step 5 — Document assumptions in the Assumption Log

For each assumption identified in the Canvas and during meetings, record:

• Assumption description: What is being assumed
• Source: Who provided this assumption
• Impact if not confirmed: What happens if the assumption proves false
• Responsible for validation: Who will confirm whether it is true
• Expected validation date: When it will be verified
• Status: Open, confirmed, refuted

Example: “Assumption: The IT team will have 3 senior developers available full-time starting in May. Source: IT Director. Impact if false: 4- to 6-week delay in MVP delivery. Responsible: HR + IT Director. Validation: by April 15.”

Step 6 — Draft the Project Charter

Based on the completed Canvas, the interviews, and the analysis of business documents, draft the formal Project Charter. The recommended structure includes:

1. Project title and unique identifier
2. Project purpose and justification (extracted from the Business Case)
3. Measurable objectives (SMART)
4. High-level requirements
5. High-level description of the project and its main deliverables
6. Assumptions and constraints
7. High-level initial risks
8. Milestone schedule
9. Summary budget
10. Project success criteria
11. Designated project manager — name and level of authority
12. Sponsor — name and authority
13. Formal approval (signature or equivalent)

Practical tip: The Project Charter should not exceed 3 to 5 pages. If it is longer, you are probably detailing what should be in the Project Management Plan (the next process).

Step 7 — Obtain formal approval

Submit the Project Charter to the sponsor (or to the governance committee, depending on the organizational structure) for formal approval. The approval must be:

• Documented: Physical signature, digital signature, or record in a management system
• Communicated: All key stakeholders must be informed that the project has been formally authorized
• Archived: The approved Charter must be stored in the project repository as a baseline document

After approval, the project has the legitimacy to allocate resources, begin detailed planning, and execute the planned activities.

6. When to Apply the Process

The Initiate Project or Phase process should be executed in the following scenarios:

Mandatory scenarios

• Start of a new project: Always. No exceptions. Even small projects need a simplified version of formal initiation.
• Start of a new phase in multi-phase projects: Each phase should be formally authorized before beginning, allowing the organization to decide whether to continue, adjust, or cancel.
• After Business Case approval: When the feasibility study is concluded and the investment decision is made, initiation formalizes that decision.

Recommended scenarios

• Significant strategic change during the project: When the project’s direction changes radically (new sponsor, change of objective, organizational merger), it may be necessary to formally “re-initiate” the project with a new Project Charter.
• Resumption of a stalled project: If a project has been on hold for months and conditions have changed, it is prudent to re-execute initiation to revalidate assumptions, constraints, and justification.
• Project manager transition: When a new project manager takes over a project in progress, a mini-initiation helps realign expectations and document the transfer of authority.

Triggers that indicate initiation is needed

• The team is working without knowing who has authority to make decisions
• Stakeholders have divergent expectations about the project’s objectives
• No formal document exists to justify the project’s existence
• Resources are being allocated without documented approval
• Critical assumptions have not been validated or recorded
• A phase has been completed and the organization needs to decide whether to proceed to the next one

7. Practical Examples by Sector

Example 1 — Information Technology: ERP Implementation

Context: A manufacturing company with 500 employees decides to implement an ERP to replace spreadsheets and legacy systems. The estimated investment is $2 million over 18 months.

How the process was applied:

1. Business documents: The CIO presented a Business Case with projected ROI in 3 years, including a 40% reduction in accounting close time and elimination of 12 manual processes.
2. Project Canvas: In a 90-minute session with the CIO, the CFO, the COO, and the future project manager, the Canvas was completed. The purpose was defined as “Unify operational and financial processes on an integrated platform.” Key assumptions identified: vendor availability to start in June, internal team of 5 key users freed at 50% capacity.
3. RACI Matrix: CIO as sponsor, IT manager as project manager, department leads as key users, vendor as technical lead for configuration.
4. Project Charter: A 4-page document with SMART objectives (“Implement Financial, Procurement, and Production modules by December 2027, with 95% adherence to the ERP standard process”), approved budget, initial risks (user resistance, data migration complexity), and project manager authority.
5. Assumption Log: 14 assumptions documented, including infrastructure availability, compatibility with legacy systems, and union acceptance of process changes.

Result: The project started with clear alignment across all departments. Three months later, when the vendor suggested changing the module sequence, the team consulted the Project Charter and assumptions to make the decision in a structured way — without the chaos of “everyone thinks something different.”

Example 2 — Construction: Residential Condominium

Context: A mid-sized construction company initiates the project for a 120-unit residential condominium in a medium-sized city. The total investment is $45 million with a 30-month timeline.

How the process was applied:

1. Business documents: Economic feasibility study with positive NPV, local market demand analysis, sales projections, and cash flow forecast. Agreement with the development partner defining profit-sharing terms.
2. Meeting with key stakeholders: Interviews with the construction director, the development partner representative, the lead engineer, and the architect. Focus on regulatory assumptions (building permits, environmental licenses) and site constraints.
3. Project Canvas: Completed in an in-person session focused on: purpose (“Develop a high-quality residential development for middle-class buyers”), deliverables (architectural design, infrastructure, 4 towers, common areas), constraints (height limits, green area preservation, building performance codes).
4. Project Charter: Included a milestone schedule (foundation, structural work, finishing, occupancy permit), budget by phase, initial risks (atypical rainfall, labor shortage, steel price fluctuations), and appointment of the chief engineer as project manager.
5. Assumption Log: 18 assumptions, including: “Building permit will be obtained by March 2027,” “Steel prices will not vary more than 15% over the next 12 months,” “Bank financing will be approved in Phase 1.”

Result: When the building permit was delayed by 45 days (refuted assumption), the team already had the impact documented and the contingency plan outlined in the Assumption Log. The decision to adjust the schedule was swift and conflict-free.

Example 3 — Marketing: Product Launch Campaign

Context: A fintech startup is launching a new credit product for SMEs and needs an integrated campaign (digital, events, PR) with a budget of $800,000 and a 4-month timeline.

How the process was applied:

1. Business documents: The CMO prepared a brief with business objectives (500 qualified leads in the first month, 50 conversions in the first quarter), target audience, positioning, and core message.
2. Project Canvas: A quick 60-minute session with the CMO, Head of Product, Head of Sales, and the contracted agency. The Canvas mapped: purpose (“Position Product X as the benchmark in SME credit”), stakeholders (investors, sales team, channel partners, press), assumptions (product regulatory approval will be obtained by launch date), risks (competitor launches a similar product first).
3. RACI Matrix: CMO as sponsor, marketing coordinator as project manager, agency as responsible for creative and media, Head of Sales as consulted on all communication pieces.
4. Project Charter: A 2-page document (smaller project = smaller document — tailoring in practice). Included: measurable KPIs, budget by channel, milestone schedule (creative brief, asset approval, launch event, first month review), and the marketing coordinator’s authority.
5. Assumption Log: 8 assumptions, including: “The agency will deliver the creative concept in 10 business days,” “The product will be approved by the regulatory authority by the launch date,” “The paid media budget will not be cut during the campaign.”

Result: When the Head of Sales requested the addition of a webinar for partners (scope change), the project manager consulted the Project Charter and the approved budget. The request was formally evaluated, approved by the CMO, and added to the scope with a documented schedule adjustment — not as “an extra task that just appeared.”

8. Shortcuts, Templates, and Tips

Recommended templates

• Project Charter Template: Use a model with predefined sections (purpose, objectives, assumptions, constraints, risks, milestone schedule, budget, approval). Complete in no more than 3-5 pages.
• Project Canvas Template: A single page with visual blocks for purpose, stakeholders, deliverables, assumptions, constraints, and risks. Ideal for collaborative sessions with sticky notes or in tools like Miro, Mural, or Canva.
• Assumption Log Template: A spreadsheet with columns: ID, description, source, impact, responsible party, validation date, status. Can be created in Excel, Google Sheets, or in your project management system.
• RACI Matrix Template: A table with activities in the rows and roles in the columns. Fill in with R (Responsible), A (Accountable), C (Consulted), and I (Informed).

Digital tools

• Miro / Mural: For collaborative Project Canvas sessions (in-person or remote)
• MS Project / ProjectLibre: For documenting the milestone schedule in the Project Charter
• Confluence / Notion: For drafting and sharing the Project Charter with version control
• ClickUp / Monday.com / Jira: For recording assumptions as trackable items with an owner and due date
• Google Workspace / Microsoft 365: For the Assumption Log in a collaborative spreadsheet

Advanced tips

• Make initiation proportional to the project: A $50 million project with 200 people needs a robust Project Charter. A process improvement with 3 people and 2 months’ duration needs a simplified version. Tailoring starts here.
• Use the Canvas before the Project Charter: The Canvas is the visual draft; the Project Charter is the formalization. Completing the Canvas first makes writing the Charter faster and better aligned.
• Do not confuse the Project Charter with the Project Plan: The Charter authorizes. The Plan details. If your Charter has a detailed schedule, a WBS, and resource allocation, it has become a Plan. Keep the focus at a high level.
• Record assumptions as potential risks: Every unvalidated assumption is a disguised risk. When filling in the Assumption Log, ask: “What if this is not true?” The answer may generate a risk that requires treatment.
• Set a review date for assumptions: Assumptions are not eternal. Define when each assumption will be reviewed and by whom. Forgotten assumptions become costly surprises.

9. Common Mistakes and How to Avoid Them

These are the 5 most frequent mistakes in applying the Initiate Project or Phase process — and how to avoid them:

Mistake 1 — Starting the project without a formal Project Charter

Why it happens: The pressure for speed and a culture of informality cause the team to start working before any formalization. “The sponsor already approved it verbally” is the most dangerous phrase in project management.

How to avoid it: Establish as an organizational rule that no resources will be allocated and no activities will begin without an approved Project Charter. For urgent projects, use a simplified version (1 page) that can be expanded later — but never zero pages. The absence of a Project Charter is the equivalent of driving without a license: it may work for a while, but when a problem arises, there is no legal standing.

Mistake 2 — A generic Project Charter without measurable objectives

Why it happens: The Business Case is vague, and the team reproduces that vagueness in the Charter. Objectives like “improve efficiency” or “modernize processes” are useless because they cannot be measured or validated.

How to avoid it: Apply SMART criteria to every objective in the Project Charter. Instead of “improve operational efficiency,” write “reduce average order processing time from 48 hours to 12 hours by December 2027.” If it is not possible to quantify, the objective is not mature enough for the Charter — go back to the Business Case and refine it.

Mistake 3 — Not identifying the project manager in the Project Charter

Why it happens: The organization defines the project first and “will figure out who will manage it later.” The late appointment of the project manager causes ownership problems: no one feels responsible for the project’s success until the PM is formally named.

How to avoid it: Include the appointment of the project manager as a mandatory item in the Project Charter. Ideally, the PM should participate in drafting the Charter — they need to understand the context, assumptions, and expectations before taking on the role. If the PM is appointed later, conduct a formal handover session with the sponsor.

Mistake 4 — Treating assumptions as confirmed facts

Why it happens: The team records assumptions at the start and never reviews them again. “The team will be available in May” is recorded as an assumption, but nobody checks in April. When May arrives and the team is unavailable, the project suffers a delay that could have been anticipated.

How to avoid it: For each assumption, define a person responsible for validating it and a validation date. Include assumption reviews in the agenda of status meetings. Treat assumptions as hypotheses that need to be tested — not as definitive truths. The Assumption Log is a living document, not a dead file.

Mistake 5 — Filling in the Project Canvas alone, without stakeholders

Why it happens: The project manager fills in the Canvas “to save time” and then presents it for approval. The problem is that the Canvas loses its greatest value — collective alignment. When stakeholders do not participate in filling it out, they do not feel ownership over the assumptions and decisions recorded.

How to avoid it: The Project Canvas is a facilitation tool, not a form to be filled out individually. Conduct an in-person or virtual session with key stakeholders. Even if it takes 90 minutes, this session saves weeks of future misalignment. If it is impossible to gather everyone together, conduct smaller sessions with different groups and consolidate the results.

10. Tailoring: Predictive, Agile, and Hybrid

PMBOK 8 emphasizes that every process should be adapted to the project context. Formal initiation is no exception — but what changes is not the need to do it, but rather how to do it.

Predictive Environment (Waterfall)

In the predictive context, initiation is the most formal and structured process:

• Project Charter: Full document (3-5 pages), formally approved by the sponsor or governance committee. Includes milestone schedule, summary budget, and detailed success criteria.
• Assumption Log: Formal document with all assumptions cataloged, prioritized by impact, and with a validation plan.
• Approval: Formal gate review before advancing to planning. Without approval, the project does not proceed.
• Project Canvas: Used as an alignment tool at the kickoff meeting, complementing (not replacing) the formal Project Charter.
• Phase initiation: Each phase has its own initiation, with a gate review at the end of the previous phase and formal authorization for the next one.

When to use this approach: Projects with well-defined scope, stable requirements, high documentation needs (regulation, compliance, contracts), and a long lifecycle.

Agile Environment

In the agile context, initiation is lighter and more iterative, but it still exists:

• Project Charter: Lean version (1-2 pages) focused on product vision, business objectives, key stakeholders, and investment limits. In Scrum, it may be complemented by the Product Vision and Product Goal.
• Assumption Log: Recorded in the backlog as investigation items (spikes) or in the definition of ready. Assumptions are validated iteratively each sprint.
• Project Canvas: A central tool. In agile environments, the Canvas can replace part of the formal Project Charter, especially in internal projects with lower documentation requirements.
• Approval: Less formal, but still necessary. The Product Owner and sponsor validate the vision and boundaries before starting Sprint 0 or the Discovery phase.
• Continuous initiation: In long-running agile projects, “re-initiation” can occur at each release or at each significant change of direction (pivot).

When to use this approach: Projects with emerging requirements, high uncertainty, a need for rapid feedback, and short delivery cycles.

Hybrid Environment

The hybrid context combines elements of both models:

• Project Charter: Formal document (2-3 pages) that defines the project’s general framework but allows details to be refined iteratively. It establishes the “guard rails” — boundaries that cannot be crossed.
• Assumption Log: Formal for high-level assumptions (budget, schedule, regulations), iterative for technical and scope assumptions (validated sprint by sprint).
• Project Canvas: Used at the kickoff session to align stakeholders, with periodic updates at the end of each phase or release.
• Dual approval: Formal gate review for phase transitions (predictive) + iterative validation by the Product Owner for scope changes within the phase (agile).
• Wave-based initiation: Early phases (analysis, design) may have predictive initiation; development phases may have agile initiation with discovery and sprint planning.

When to use this approach: Projects that combine partially defined scope with areas of high uncertainty, organizations transitioning to agility, or projects with multiple teams using different approaches.

Tailoring comparison summary

11. Interactions with Other Processes and Domains

The Initiate Project or Phase process is the starting point of the entire PMBOK 8 process chain. Virtually all other processes depend, directly or indirectly, on the outputs of initiation.

Processes that feed into initiation (input dependencies)

Initiation is the first formal process of the project, so its inputs come primarily from outside the project:

• Pre-project organizational processes: Portfolio selection, feasibility analysis, Business Case approval
• Previous phase closure: If this is a phase initiation, the outputs of the “Close Project or Phase” process from the previous phase feed into this initiation

Processes that depend on initiation (output dependencies)

Interactions with PMBOK 8 Domains

Governance: Initiation is the foundational process of the governance domain. It defines the authority structure, the responsibility matrix, and the decision-making framework that will support all other governance processes — from plan integration to formal closure.

Scope: The Project Charter provides the high-level requirements and objectives that will serve as the basis for detailed scope planning. Without a well-executed initiation, scope starts with an unstable foundation.

Schedule: The high-level milestones and schedule constraints defined during initiation drive all temporal planning for the project. Changes to schedule assumptions directly impact the timeline.

Finance: The summary budget and financial constraints from the Project Charter define the financial envelope within which the project must operate. Initiation also formalizes the source of financial resources.

Risk: The initial risks identified during initiation feed the risk identification process. More importantly, the Assumption Log is a primary source of risks, since every unconfirmed assumption is a potential risk.

Resources: The appointment of the project manager and the initial RACI Matrix define the project’s human resource structure. The PM’s authority to allocate resources is established during initiation.

Stakeholders: The stakeholders identified during initiation are the starting point for stakeholder management. The Project Charter documents who the high-impact stakeholders are and their relationship with the project.

12. Quick-Application Checklist

Use these 7 items as a quick reference before considering initiation complete:

1. Has the Business Case (or equivalent justification) been analyzed, and is there a documented reason for the project to exist?
2. Has the Project Charter been drafted with measurable objectives (SMART), assumptions, constraints, and initial risks — and formally approved by the sponsor?
3. Has the project manager been appointed with clear, documented authority to allocate resources and make decisions within the defined boundaries?
4. Have assumptions been recorded in the Assumption Log with a responsible party for validation and an expected verification date?
5. Have key stakeholders been identified and consulted during initiation — and have their expectations been documented?
6. Has the initial Responsibility Assignment Matrix (RACI) been defined, with clear roles for the sponsor, project manager, client, and governance committee?
7. Has the Project Canvas been collaboratively filled in with key stakeholders, ensuring visual alignment on purpose, value, deliverables, assumptions, and risks?

Practical rule: If fewer than 5 of these items have been addressed, the initiation is not complete. Investing time now to complete them prevents weeks of rework, misalignment, and conflict during execution.

Conclusion

The Initiate Project or Phase process is, by design, the first process in PMBOK 8 — and that position reflects its importance: without a well-executed initiation, the rest of the project operates on a fragile foundation.

Three essential takeaways for practice:

• Formal initiation is not bureaucracy — it is protection. The Project Charter protects the project manager, aligns expectations, and documents the conditions under which the project was approved. Without it, decisions are arbitrary, responsibilities are ambiguous, and assumptions are invisible.
• The Project Canvas is the major PMBOK 8 addition to this process. It enables visual, rapid alignment among all stakeholders in a single session. Use it as a collaborative draft before writing the formal Project Charter — the quality of the Charter and the level of alignment will be significantly higher.
• Documented assumptions are manageable risks; ignored assumptions are costly surprises. The Assumption Log is not a formality — it is a radar that anticipates problems. Treat each assumption as a hypothesis that needs to be tested, not as an established fact.

Concrete next step: Open your current project. Does the Project Charter exist and is it approved? If so, check: are the objectives SMART? Is the project manager named with clear authority? Are assumptions documented with a responsible party and a validation date? If the answer is “no” to any of these questions, you have identified your first improvement action. Do it now — before the lack of formal initiation turns into a real problem.

Ready to apply the Initiate Project or Phase process to your projects? Start with the Quick-Application Checklist (Section 12) and assess how many of the 7 items your current project meets. If more than 2 are missing, you have an initiation gap that needs to be resolved before advancing to planning.

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

Project Management Institute (PMI). A Guide to the Project Management Body of Knowledge (PMBOK® Guide) – Eighth Edition. Newtown Square, Pennsylvania, USA: Project Management Institute, 2025.

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.