Initiate Project or Phase in PMBOK 8 — Complete Guide

Article updated in March 2026 for the PMBOK® Guide — Eighth Edition.

Initiate Project or Phase in PMBOK 8 — Complete Guide

Formerly known as: Develop Project Charter (PMBOK 6)

Two project managers received approval for their projects on the same Friday. The first one started writing code and deploying designs by Monday morning — no formal document, no stakeholder alignment session, just a verbal go-ahead and a shared Slack channel. The second one spent three focused days running a project canvas session, documenting nine critical assumptions, and getting the project charter signed. Six weeks later, the first project was in crisis: the client insisted a chatbot had been promised; the PM had no document to dispute the claim, and the scope spiraled. The second project encountered the same client pressure — and handled it in a ten-minute meeting, pointing to a signed charter that explicitly excluded a chatbot from scope.

Formal initiation is not paperwork — it is the single act that determines whether your project has a foundation or a fault line. In PMBOK 8, Initiate Project or Phase is Process 1 of the Governance Domain, and it exists precisely because the most expensive project failures are rarely technical. They are governance failures — missing authorization, undocumented assumptions, misaligned expectations — that begin on day zero.

This complete guide covers everything a project manager or PMP candidate needs to understand, apply, and tailor this process:

• What it is — definition, position in PMBOK 8, and what changed from PMBOK 6
• Why use it — direct benefits and the cost of skipping it
• Full ITTO — every input, tool, technique, and output explained
• Step-by-step application guide — from business case to signed charter
• When to apply it — triggers and mandatory vs. recommended scenarios
• Two real-world examples — Project Phoenix (website launch) and Project ProjectAdm (SaaS PM platform)
• Templates and tools — with free downloads
• Five common errors — and how to avoid each one
• Tailoring — predictive, agile, and hybrid approaches
• Process interactions — what feeds into initiation and what depends on it
• Quick-application checklist — 10 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 existence of a project — or the start of a new phase within an ongoing project — and formally appoints the project manager with recognized authority to begin allocating resources and making decisions. It translates an organizational opportunity, a strategic need, or a contractual obligation into a documented mandate with defined boundaries, measurable objectives, and identified key stakeholders.

In PMBOK 8, this is Process 1 of the Governance Domain (Governance Domain, Process 1 of 9). Its position is not coincidental: everything that follows — planning, execution, monitoring, and control — depends on this foundation. Without formal authorization and documented assumptions, every subsequent decision is built on ambiguity.

The process produces two outputs:

• Project Charter — the document that formally authorizes the project or phase, establishes the project manager’s authority, and defines objectives, high-level scope, key milestones, summary budget, and initial constraints.
• Assumption Log — a living document that captures every condition accepted as true at the time of initiation but not yet verified. Each assumption includes its source, potential impact if proven false, the person responsible for validating it, and the target validation date.

Initiating a project vs. initiating a phase

The same process applies to both scenarios, but with meaningful differences in scope and depth:

What changed from PMBOK 6 to PMBOK 8

Understanding the evolution helps PMP candidates answer exam questions correctly and helps practitioners apply the right mental model:

In essence, PMBOK 8 broadened the process from a document-centric view to a governance-centric view. The name change signals the shift: initiation is not just about producing a charter — it is about formally anchoring the project in organizational governance, with formal authority established and assumptions visible from day zero.

2. Why Use the Initiate Project or Phase Process

Formal initiation is the most underestimated protection a project manager has. When well-executed, it delivers benefits that extend far beyond the kickoff meeting:

Direct benefits

• Formal legitimacy: The project officially exists within the organization. Resources can be allocated, contracts can be signed, and decisions have documented backing. Without a charter, every resource request is an informal favor.
• Alignment of expectations from day zero: The sponsor, project manager, and key stakeholders start from the same documented baseline — objectives, constraints, assumptions, and success criteria. Misalignment discovered in week 1 costs hours to resolve. Misalignment discovered in week 12 costs weeks.
• Unambiguous authority: The project manager is formally appointed, with a defined and documented scope of authority. There is no longer any ambiguity about who makes what decision — and who can escalate to whom.
• Traceability from day zero: Assumptions are documented, initial decisions are recorded, and the project is born with an auditable history. When someone later asks “who decided that?” the answer is in the charter.
• Foundation for planning: The project charter is the essential input for every planning process that follows. It provides the baseline objectives, the budget envelope, the milestone framework, and the constraint boundaries that guide all subsequent decisions.
• Phase gate control: By applying initiation at the phase level, the organization creates formal decision points — proceed, adjust, or cancel — before committing additional resources to the next phase. This is particularly critical in large, multi-year projects.

The cost of skipping initiation

The consequences of skipping or underestimating initiation follow a predictable pattern that research and case studies have documented repeatedly:

• Uncontrolled scope from day one: Without documented objectives and a signed charter defining scope boundaries, every new request appears legitimate. Scope creep does not begin in month three — it begins on day one.
• Authority conflicts: Without formal appointment of the project manager, multiple people attempt to make decisions. The result is either paralysis (no one decides) or conflict (multiple conflicting decisions).
• Invisible assumptions: Every team member carries a set of unspoken assumptions about deadlines, budgets, resource availability, and technical constraints. When reality diverges from those assumptions, there is no reference point for conflict resolution.
• Planning rework: The team plans based on unvalidated suppositions. When the sponsor finally reviews the plan, they discover it is misaligned with their original intent — and the entire planning cycle must restart.
• Late-stage cancellation waste: Projects that should never have been started consume resources for months before someone realizes there was no viability from the beginning. The Business Case existed; no one read it carefully enough to raise the flag at initiation.

The PMBOK 8 principle “Focus on Value” reinforces this point directly: if the project cannot demonstrate a clear value proposition at initiation, it should not consume organizational resources. Formal initiation is the first — and most cost-efficient — value filter in the project lifecycle.

3. Inputs, Tools & Techniques, and Outputs (ITTO)

The following table presents the complete ITTO of the Initiate Project or Phase process as defined in PMBOK 8:

Inputs explained

Business documents (business case and benefits management plan): The business case documents the financial and strategic justification for the project — it answers the question “why should this project exist?” The benefits management plan defines how the expected benefits will be measured, tracked, and realized. Together, they establish the value proposition that the project must deliver. If neither document exists, the project manager’s first task is to request their creation — or to challenge whether the project has been adequately justified at all.

Agreements: Contracts, memoranda of understanding, letters of intent, service level agreements, or internal inter-departmental agreements. When the project originates from an external client contract, the agreement is often the single most important input — it defines legally binding scope, schedule, and quality commitments that must be reflected in the project charter. Failing to align the charter with the contractual terms is one of the most costly initiation errors in client-facing projects.

Enterprise Environmental Factors (EEFs): Conditions external and internal to the organization that can influence the project’s context and constraints. EEFs include organizational culture, existing governance structures, regulatory environment, market conditions, technology infrastructure, and resource availability. Understanding EEFs prevents the team from documenting assumptions that contradict the operational reality in which the project will be executed.

Organizational Process Assets (OPAs): Everything the organization already has that can accelerate initiation: charter templates, assumption log formats, lessons learned from previous similar projects, historical cost data, approved vendor lists, and documentation standards. OPAs are particularly valuable for reducing the time required to produce a high-quality charter — there is no need to reinvent the wheel for every project.

Tools & Techniques explained

Expert judgment: The deliberate consultation of people who possess specific knowledge relevant to the project’s context — technical domain, industry, regulatory landscape, organizational politics, or project management discipline. Expert judgment may come from internal subject-matter experts (a lead architect reviewing feasibility assumptions, a legal counsel reviewing contractual constraints), external consultants, or the project manager’s own accumulated experience. In PMBOK 8, expert judgment is not passive review — it is structured input that challenges assumptions and validates the charter’s feasibility before it is signed.

Data gathering — brainstorming, focus groups, and interviews: Three distinct techniques for collecting the information needed to build a credible charter and a comprehensive assumption log. Brainstorming generates a large volume of ideas quickly — it is ideal for surfacing assumptions, risks, and objectives that no single person would have identified alone. Focus groups bring together a representative sample of stakeholders to explore expectations, constraints, and success criteria in a facilitated discussion. Interviews are structured one-on-one conversations that allow the project manager to probe deeply into a specific stakeholder’s perspective, uncovering context that would never surface in a group setting. For initiation, interviews with the sponsor and the top two or three key stakeholders are non-negotiable.

Interpersonal and team skills — conflict management, facilitation, and meeting management: Initiation involves bringing together stakeholders who often have competing priorities, different risk tolerances, and divergent expectations about what the project should deliver. Conflict management skills allow the project manager to surface and resolve misalignments before they become documented contradictions in the charter. Facilitation skills ensure that the charter development session generates alignment, not just a list of opinions. Meeting management skills keep the initiation process efficient — a poorly managed kickoff session can consume four hours and produce less alignment than a well-managed 90-minute canvas session.

Meetings: The primary mechanism for conducting initiation. These include the sponsor alignment meeting (confirming objectives and constraints before drafting the charter), the stakeholder alignment session (using a project canvas or structured discussion to surface assumptions and expectations), the charter review meeting (reviewing the draft with key stakeholders before obtaining formal approval), and — in multi-phase projects — gate review meetings where the organization formally decides whether to authorize the next phase.

Outputs explained

Project Charter: The foundational governance document of the project. At minimum, a well-structured PMBOK 8 project charter includes: project title and unique identifier; purpose and justification (drawn directly from the business case); measurable SMART objectives; high-level requirements; high-level project description and primary deliverables; assumptions and constraints; initial high-level risks; milestone schedule; summary budget; project success criteria; the project manager’s name and formally defined scope of authority; the sponsor’s name and authority; and formal approval (signature, digital record, or governance system entry). The charter should not exceed three to five pages for most projects — if it is longer, it has crossed the boundary into the project management plan.

↓ Free template and filled-in examples available in section 7.

Assumption Log: A structured register of every condition that the project team accepts as true at the time of initiation but has not yet verified. The assumption log is not a static artifact — it is a living document that must be reviewed and updated throughout the entire project lifecycle. Each entry should record: a unique ID; the assumption description; who provided the assumption (source); what will happen if the assumption proves false (impact); the person responsible for validating it; the target validation date; and the current status (open, confirmed, or refuted). Every refuted assumption should immediately trigger a risk or issue assessment — because a false assumption that was documented is a managed risk, while a false assumption that was not documented is a crisis.

↓ Free template and filled-in examples available in section 7.

4. How to Apply the Process Step by Step

The following sequence is applicable to any project, regardless of sector or approach. Complexity scales the depth of each step — not the sequence itself.

Step 1 — Gather and critically analyze the business documents

Before any meeting, collect and read the business case, the benefits management plan, any feasibility studies, and all relevant contractual agreements. Do not assume these documents are correct or complete — challenge them. Ask:

• Is the project’s justification quantifiable, or is it vague strategic language?
• Are the expected benefits defined with measurable metrics and a realization timeline?
• Does the budget estimate have a credible basis, or is it a round number someone committed to informally?
• Do contractual terms impose constraints on scope, schedule, or quality that the business case does not acknowledge?

Practical rule: If the business case does not exist or is too generic to derive measurable objectives from, request it from the sponsor before proceeding. Starting a project without a documented justification is writing a blank check.

Step 2 — Identify and consult key stakeholders

Map the people who influence or are influenced by the project at a high level. For initiation purposes, prioritize stakeholders with high power or high interest: the sponsor, the client or business representative, directors of impacted departments, relevant technical specialists, and compliance or regulatory representatives when applicable. Conduct focused individual interviews to capture each stakeholder’s expectations, constraints, assumptions, and definition of project success. The goal is not consensus at this stage — it is visibility. You need to know what each key stakeholder believes before you can document alignment (or surface misalignment early).

Step 3 — Run a project canvas or alignment session

Use the project canvas or a structured alignment workshop as a facilitation tool to build a shared visual picture of the project before committing it to a formal charter. In a 60- to 90-minute session with key stakeholders, work through:

• Purpose: Why does this project exist? What problem does it solve?
• SMART Objective: What measurable outcome will be achieved, and by when?
• Benefits: What value will the organization realize? How and when will it be measured?
• Primary deliverables: What will the project produce?
• Key stakeholders: Who is involved, and in what capacity?
• Assumptions: What are we currently accepting as true without confirmation?
• Constraints: What are the non-negotiable limits — budget, schedule, regulatory, technical?
• Initial risks: What could prevent us from achieving the objective?
• High-level milestones: What are the critical dates or decision points?

The canvas serves as the collaborative draft from which the formal project charter will be written. Its primary value is speed of alignment — everyone in the room is literally looking at the same page.

Step 4 — Document all assumptions in the Assumption Log

For every assumption surfaced during interviews and the canvas session, create an entry in the assumption log. For each entry, record: the assumption description; the source (who provided it); the impact if proven false; the person responsible for validation; and the target validation date. Apply a priority rating — assumptions with high impact if false should be validated earliest, and should be flagged as potential risks in the risk register.

Step 5 — Draft the Project Charter

Based on the business documents, stakeholder interviews, and the completed canvas, draft the formal project charter. Every objective must pass the SMART test: Specific, Measurable, Achievable, Relevant, and Time-bound. Generic objectives like “improve performance” or “modernize the platform” have no place in a PMBOK 8 charter — they provide no baseline for measuring success or controlling scope.

Step 6 — Obtain formal approval

Submit the draft charter to the sponsor (or governance committee, depending on organizational structure) for formal review and approval. The approval must be documented (physical or digital signature, or a formal record in a governance system), communicated to all key stakeholders, and archived as the baseline document for the entire project. After approval, the project has the formal authority to allocate resources, begin detailed planning, and execute activities.

5. When to Apply the Process

Mandatory scenarios

• Start of any new project: Always, without exception. Even small, short-duration projects need at minimum a simplified charter. The complexity of the charter scales with the project — the absence of a charter never scales with anything.
• Start of a new phase in a multi-phase project: Each phase should be formally authorized before beginning. The gate review at the end of the previous phase is the natural trigger for a phase-level initiation.
• After business case or investment approval: When the organization’s governance has approved the project at the portfolio or program level, formal initiation is the mechanism that translates that approval into an actionable, documented mandate.

Recommended scenarios

• After significant strategic change: When the project’s strategic context changes fundamentally — new sponsor, change of corporate direction, organizational merger, major regulatory shift — a formal re-initiation reviews and updates the charter to reflect the new reality.
• Resumption of a paused or stalled project: If a project has been on hold for an extended period, conditions have changed. A re-initiation validates that assumptions are still valid, the business case still holds, and the charter still reflects organizational intent before resources are re-committed.
• Project manager transition: When a new project manager takes over a project in progress, a structured mini-initiation — reviewing the charter with the sponsor and updating it as needed — ensures that the incoming PM has a clear, documented mandate and does not inherit undocumented assumptions or informal scope commitments.

Warning signs that initiation is incomplete or missing

• The team is executing without a clear understanding of who has authority to approve decisions
• Key stakeholders describe the project’s objectives differently when asked individually
• There is no formal document that specifies the project’s budget envelope and authorization
• Critical assumptions have not been written down anywhere
• A new phase has begun without any formal review or approval of the previous phase’s output
• Resources are being allocated and costs are being incurred without documented authorization

6. Practical Examples

Example 1 — Website Launch: Project Phoenix

Context: DataBridge Consulting, a B2B digital agency with 20 employees, was retained by a mid-market consulting firm that was losing qualified leads due to a slow, outdated website with no CRM integration and no marketing automation. The result was an estimated 35% lead leakage at the top of the funnel. The proposed project — internally named Project Phoenix — called for a full website redesign, CRM integration, and marketing automation setup, with a budget of $72,000, a 4-month timeline, and a target of +40% lead conversion within six months of launch. The delivery team: PM, two developers, one designer, and one inbound analyst. Approach: agile with 2-week sprints.

How the Initiate Project or Phase process was applied:

The PM began by reviewing the business case prepared by the agency’s commercial director: the client had tracked three consecutive quarters of declining contact form submissions despite stable paid traffic, with a clear attribution to page load times above 4 seconds and the absence of any lead nurturing infrastructure. The ROI projection assumed a 40% improvement in form conversion, translating to approximately 12 additional qualified leads per month at the client’s current traffic volume.

Two days after contract signature, the PM facilitated a 90-minute project canvas session with the agency owner (sponsor), the client’s marketing director (product owner), one developer, and the inbound analyst. The session surfaced the project’s core purpose: “Rebuild the client’s digital acquisition infrastructure so that every qualified visitor has a structured path to a sales conversation.” Three competing interpretations of scope were immediately visible — the client’s marketing director assumed a full blog migration was included; the sponsor did not. The canvas session resolved the misalignment before it was ever committed to code.

The project charter was written the following day. Objectives were documented in SMART format: “Launch the redesigned website with integrated CRM (HubSpot) and marketing automation (ActiveCampaign) by [date + 4 months], with page load time under 2 seconds on mobile, achieving a 40% improvement in form conversion rate within 180 days of launch as measured by the client’s analytics baseline.” The charter explicitly stated that the blog migration was out of scope, that the chatbot functionality was not included, and that the measurement baseline would be established from the client’s current Google Analytics data.

The assumption log documented nine assumptions at initiation:

1. Client will provide all brand assets (logo, photography, brand guide) within 5 business days of kickoff
2. Client will have HubSpot Professional tier active and accessible to the agency by Sprint 1
3. ActiveCampaign account will be in place and configured with the client’s existing contact list before Sprint 3
4. Client’s marketing director will be available for sprint reviews at the end of each 2-week cycle
5. Current hosting infrastructure supports the target performance benchmarks (sub-2-second load time)
6. No regulatory constraints apply to the collection and processing of lead data (confirmed by client legal team)
7. Content for the new website (copy) will be provided by the client’s team, not written by the agency
8. The existing domain will be preserved; no domain migration is required
9. Integration between HubSpot and ActiveCampaign will use native connectors, without custom API development

The charter was reviewed by the agency owner and signed digitally by the client’s marketing director on day 3 of the project — before a single wireframe was drawn.

The chatbot scope change in week 6: At the sprint 3 review, the client’s CEO joined the meeting and stated that a “chatbot for lead qualification” had been part of the original agreement. The PM opened the signed project charter and the approved assumption log on screen. The chatbot was not mentioned anywhere in the charter’s scope section — and Assumption 2 explicitly documented that only HubSpot and ActiveCampaign integrations were in scope. The CEO acknowledged the misalignment and agreed to a formal change request. The change was evaluated: +$8,000 and +2 weeks to the project timeline. The sponsor approved the change, a charter amendment was signed, and the chatbot was added to the backlog for Sprint 5. The entire resolution took one business day. Without the signed charter, it would have taken weeks of negotiation, email chains, and potential contract dispute.

Result: Project Phoenix delivered on schedule, within budget (plus the formally approved $8,000 amendment), and the client achieved a 43% improvement in form conversion rate at the 180-day measurement point — exceeding the 40% target documented in the charter.

Example 2 — SaaS PM Platform: Project ProjectAdm (Software Development)

Context: Eduardo Montes (CEO/PM) and co-founder Henry Douglas initiated Project ProjectAdm to build a SaaS project management platform aligned to PMBOK 8 methodology, targeting professional project managers and organizations globally. Budget: $280,000 USD. Duration: 13.5 months (January 15, 2025 – February 28, 2026). Team: PM/CEO (Eduardo Montes), co-founder/co-sponsor (Henry Douglas), two senior developers, two mid-level developers, one backend developer, one UX/UI designer, one QA engineer, and Claude AI integrated as a development tool in the workflow. Approach: hybrid — predictive planning for compliance milestones (GDPR + CCPA certification) and multi-region infrastructure deployment, combined with 2-week agile sprints for product feature development. The team used ProjectAdm to manage the ProjectAdm project from day one — a dogfooding approach that embedded authentic product feedback into every sprint.

How the Initiate Project or Phase process was applied:

Before any formal initiation activities, the PM synthesized the business case documents: a market analysis confirming the global PM software market at $7.3 billion growing at 13.4% CAGR, a competitive landscape analysis identifying the absence of any dominant PMBOK 8-aligned SaaS platform for certified PMs and PMO leaders, and a product vision document defining the core value proposition. The business case was clear and quantifiable — which meant the initiation workshop could focus entirely on translating that opportunity into governance structure, not on justifying the project.

The PM facilitated a two-day initiation workshop with the co-founder, the lead developer, the UX designer, and the QA engineer. The workshop used a structured project canvas format. On day one, the group aligned on purpose, target audience (professional PMs, PMP candidates, PMO leaders), SMART product objectives, and non-negotiable compliance requirements (GDPR for the European market, CCPA for California users). On day two, the group worked through the hybrid approach: predictive milestones for compliance certification and infrastructure decisions, and 2-week sprint cadence for product development.

In hour three of the workshop, the lead developer raised a critical architectural question that no one had explicitly addressed: the team had been assuming that a single AWS region deployment would satisfy both GDPR (requiring EU data residency) and CCPA requirements simultaneously. The lead developer challenged this: GDPR mandates that EU personal data be processed and stored within the EU or in countries with adequate protection — a US-only AWS deployment would not be compliant from launch day. This was a critical undocumented assumption. The decision was made in the workshop: a multi-region AWS architecture (US-East + EU-West) from day one, rather than a post-launch data migration. This decision added approximately $2,400/month in infrastructure costs and 3 weeks of initial setup work — costs known and budgeted at initiation rather than discovered as a compliance crisis post-launch.

The assumption log documented 12 assumptions at initiation, including:

1. Multi-region AWS deployment (US-East + EU-West) is required from launch day to satisfy GDPR data residency requirements for EU users
2. Stripe and PayPal are the only payment gateways required for the initial launch; no regional payment processors are needed
3. The initial target market will be English-speaking professional PMs; UI localization (translation) is out of scope for version 1.0
4. GDPR compliance legal review will cost approximately $4,500 and take 3 weeks, based on comparable SaaS benchmarks
5. Claude AI integration for PM-assistance features will operate within Anthropic’s standard API without requiring dedicated infrastructure or custom model training
6. The development team can achieve 2-week sprint velocity without a dedicated DevOps engineer; CI/CD pipeline setup is the lead developer’s responsibility in Sprint 1
7. PHPUnit test coverage at 80%+ is required for all core modules before deployment to production
8. The dogfooding approach — using ProjectAdm to manage the ProjectAdm project from Sprint 1 — will generate authentic use cases that improve the product faster than user research alone
9. Stripe’s standard subscription billing API supports the pricing model (monthly + annual plans, per-seat billing, free trial periods) without custom development
10. The target launch date of February 28, 2026 provides sufficient runway to achieve 500 paying subscribers at a 3% trial-to-paid conversion rate
11. CCPA compliance for California users can be achieved through privacy controls aligned with GDPR requirements, without a fully separate compliance framework
12. The project budget of $280,000 covers the full 13.5-month development cycle; no phased funding approvals are required mid-project

The formal project charter documented SMART objectives: launch with 500 paying subscribers by February 28, 2026; achieve NPS > 50 within 90 days of launch; obtain GDPR and CCPA compliance certification before public launch; achieve PHPUnit test coverage ≥ 80% for all core modules before production deployment. The charter included the $280,000 budget envelope allocated by development phase, the hybrid milestone schedule (architecture finalized by March 2025; GDPR/CCPA certification by October 2025; production infrastructure ready by January 2026; public launch by February 28, 2026), and the 2-week sprint cadence for product development. A dogfooding clause was formally included: “The ProjectAdm platform will be used to manage the ProjectAdm project from Sprint 1 onwards.” The charter was approved by both co-founders.

Result: The multi-region architecture decision made in the initiation workshop prevented a post-launch GDPR compliance crisis that would have required a full data migration — estimated at $15,000–$20,000 in engineering cost and a mandatory disclosure to EU users. All 12 assumptions were validated on schedule. Assumption 6 (DevOps without a dedicated engineer) was partially refuted by Sprint 3: CI/CD pipeline complexity required 2 additional days per sprint from the lead developer. Because the assumption was documented with a named responsible party and a specific impact metric, the PM identified the deviation immediately, revised the assumption, and renegotiated the lead developer’s allocation from Sprint 4 onwards. No project impact resulted from the revision. The GDPR + CCPA compliance certification was achieved on schedule in month 10 — because the compliance requirements had been factored into the architecture at initiation, not retrofitted after the fact.

7. Free and Recommended Templates

Download the free templates for this process and study the filled-in examples from two real projects — Project Phoenix ($72K website launch) and Project ProjectAdm ($280K SaaS PM platform):

Recommended digital tools

• Miro / Mural / FigJam: For collaborative project canvas sessions, especially with distributed teams. Allow real-time co-creation and can be archived as project artifacts.
• Confluence / Notion: For drafting and version-controlling the project charter with stakeholder commenting and approval workflows.
• ClickUp / Monday.com / Jira: For managing the assumption log as a structured list with assigned owners, due dates, and status tracking integrated into the project management workflow.
• Google Workspace / Microsoft 365: For the assumption log as a collaborative spreadsheet with shared access, comment tracking, and change history.
• DocuSign / Adobe Sign: For obtaining formal digital approval of the project charter with an auditable signature record.

8. Five Common Errors — and How to Avoid Each One

Error 1 — Starting the project before a signed project charter exists

Why it happens: Executive pressure for speed, a culture of informality, or the belief that “the sponsor already approved it verbally” create a false sense that documentation can follow execution. The phrase “we’ll formalize it later” is one of the most reliable predictors of project failure.

How to avoid it: Establish as a non-negotiable rule that no resources will be allocated and no activities will begin without an approved project charter. For urgent projects, a one-page simplified charter produced in a 60-minute session is far better than no charter. A verbal approval is not a charter — it is an expectation waiting to become a conflict.

Error 2 — Charter objectives that cannot be measured

Why it happens: The business case is vague, and the team reproduces that vagueness in the charter. Objectives like “improve efficiency,” “modernize the platform,” or “enhance customer experience” provide no baseline for measuring success, controlling scope, or resolving disputes about whether the project delivered its promise.

How to avoid it: Apply SMART criteria to every objective in the charter without exception. If an objective cannot be made specific and measurable, the business case is not mature enough to authorize a project. Return to the sponsor with the draft objective and a direct question: “How will we know, with a number, that we have achieved this?”

Error 3 — The project manager is not named in the charter with explicit authority

Why it happens: The organization defines the project first and assigns the PM “later, once we know who is available.” The result is that the project begins with no formal accountability — no one owns the outcomes, resource requests have no authorized decision-maker, and scope discussions have no arbiter.

How to avoid it: The PM appointment, including a clearly documented scope of authority (what decisions the PM can make independently vs. what requires escalation), must be a mandatory field in the project charter. Ideally, the PM participates in drafting the charter — this ensures the PM understands the context, assumptions, and expectations before taking ownership of the project.

Error 4 — Assumptions are documented once and never reviewed again

Why it happens: The team fills in the assumption log at initiation and treats it as a completed deliverable rather than a living instrument. Assumptions that were accurate in month one may be completely invalidated by month three — and if no one is tracking them, the invalidation becomes a crisis rather than a managed response.

How to avoid it: For every assumption in the log, assign a named responsible party and a target validation date. Include assumption log reviews as a standing agenda item in status meetings. Treat each assumption as a hypothesis that must be periodically tested. When an assumption is refuted, the response process (risk assessment, change request, stakeholder notification) should be triggered immediately — not discovered incidentally at the next steering committee meeting.

Error 5 — The project canvas is completed alone, by the PM, before the session

Why it happens: The PM wants to “come prepared” and pre-fills the canvas to save time in the stakeholder session. The well-intentioned preparation eliminates the canvas’s primary value: the surfacing of divergent assumptions, expectations, and interpretations through structured collaborative discussion.

How to avoid it: The project canvas is a facilitation instrument, not a form. Its purpose is to produce alignment through the process of filling it in together — not to document alignment that is assumed to already exist. A PM-completed canvas presented to stakeholders for approval is a different (and less valuable) artifact than a canvas built collaboratively. Invest the 90 minutes in a facilitated session. The alignment produced in that session prevents weeks of downstream misalignment.

9. Tailoring: Predictive, Agile, and Hybrid

PMBOK 8 places explicit emphasis on tailoring every process to the context of the project. For Initiate Project or Phase, what varies across approaches is not whether to do it, but how formally and how deeply to execute each element.

Predictive approach (Waterfall)

In the predictive context, initiation is the most formal and structured of the three approaches:

• Project Charter: Full document (3–5 pages), formally reviewed and approved by the sponsor or governance committee. Includes a milestone schedule, a summary budget, detailed success criteria, and a formally defined RACI matrix.
• Assumption Log: Formal document with all assumptions cataloged, prioritized by impact, and assigned to responsible parties with defined validation dates. High-impact assumptions are cross-referenced with the risk register.
• Governance gates: Formal gate review before advancing to planning. Without documented approval at the gate, the project does not proceed to the next phase. This gate is the mechanism that gives the organization control over multi-phase investment decisions.
• Phase initiation: Each phase has its own formal initiation, with a gate review at the end of the previous phase and explicit authorization for the next one. Phase charters may be addenda to or amendments of the original project charter.

Best suited for: Projects with well-defined and stable scope, high documentation and compliance requirements (regulated industries, government contracts, major infrastructure projects), and long lifecycles where phase-gate control is essential to investment management.

Agile approach

In the agile context, initiation is lighter, faster, and more iterative — but it still exists, and skipping it is still a mistake:

• Project Charter (or team charter): A lean version (1–2 pages) focused on product vision, business objectives, key stakeholders, investment boundaries, and the team’s working agreements. In Scrum, it is complemented by the Product Vision and the initial Product Goal. The sponsor in this context often functions as or closely with the Product Owner.
• Assumption Log: Tracked in the product backlog as investigation items (spikes) or in the definition of ready. Assumptions are validated iteratively each sprint — the sprint cycle itself is a structured mechanism for converting assumptions into validated knowledge.
• Approval: Less formal, but still required. The Product Owner and sponsor validate the vision, the investment boundary, and the initial priorities before Sprint 0 or the Discovery phase begins.
• Continuous initiation: In long-running agile products, re-initiation may occur at each major release or at each significant pivot, resetting the charter’s objectives and constraints to reflect the evolved product vision.

Best suited for: Products with emerging requirements, high uncertainty and experimentation needs, short delivery cycles, and a strong feedback loop between team and stakeholders. The sponsor functions effectively as the Product Owner or as a very close partner to one.

Hybrid approach (the ProjectAdm model)

The hybrid context — exemplified by Project ProjectAdm — combines the predictive and agile models into a coherent initiation framework that serves both the governance requirements of the organization and the delivery reality of the team:

• Formal charter for compliance and infrastructure milestones: The project charter is a formal document (2–3 pages) that defines the overall project framework, the non-negotiable constraints (budget envelope, GDPR/CCPA compliance milestones, multi-region architecture decisions), and the governance structure. This layer satisfies the need for documented authority and investment control.
• Agile team charter for sprint cadence: An addendum to the formal charter (or a separate, team-facing document) that defines working agreements, definition of ready, definition of done, sprint review cadence, and escalation paths. This layer gives the delivery team the clarity and autonomy they need to operate effectively within the sprints.
• Dual-layer assumption log: High-level assumptions (budget, schedule, regulatory constraints, infrastructure architecture) are managed formally — with named owners, validation dates, and formal escalation if refuted. Technical and feature-level assumptions are managed iteratively — validated sprint by sprint through spikes, prototypes, and user testing.
• Dual approval mechanism: Formal gate reviews for phase transitions (e.g., from architecture design to development, or from development to compliance certification) and iterative validation by the product team for feature-level scope decisions within each sprint. The gate review protects governance; the sprint review drives product value.

Best suited for: Projects that combine partially defined, stable scope (compliance requirements, infrastructure, architecture) with areas of high uncertainty or emerging requirements (user-facing features, UX, product-market fit). Organizations building software products where governance requirements (data privacy, security certifications, financial controls) co-exist with an agile product development culture.

Tailoring comparison summary

10. Interactions with Other Processes and Domains

Initiate Project or Phase is the entry point to the entire PMBOK 8 process chain. Its two outputs — the project charter and the assumption log — flow into virtually every planning process that follows. Understanding these connections is essential for both PMP exam preparation and for applying the process correctly in practice.

The most critical downstream connection: Integrate and Align Project Plans

The immediate successor process in the Governance Domain is Integrate and Align Project Plans (Governance Domain, Process 2 of 9). The project charter produced in initiation is the primary input to this process — it defines the objectives, constraints, budget envelope, and milestone framework that all subsidiary plans (scope, schedule, cost, risk, quality, resources, communications, procurement, stakeholders) must align with. Without a well-formed charter, the plan integration process has no authoritative baseline to integrate against, and the project management plan becomes a collection of disconnected sub-plans rather than a coherent governance framework.

Identify Stakeholders

The Identify Stakeholders process receives the list of key stakeholders documented during initiation as its primary input. The stakeholders identified in the project charter — sponsor, client, impacted department directors, regulatory bodies, and key technical resources — are the starting point for the comprehensive stakeholder register. Initiation provides the first cut; stakeholder identification refines and expands it through structured analysis techniques. Projects that skip formal initiation typically also have an incomplete stakeholder register — because the conversations that surface unknown stakeholders (brainstorming sessions, interviews with the sponsor) are the same conversations that produce the charter.

Plan Risk Management

The Plan Risk Management process, and the subsequent Identify Risks process, depend heavily on two outputs of initiation: the initial risks documented in the project charter, and the assumption log. The assumption log is, in a structural sense, a pre-risk register: every assumption that has not yet been validated is a potential risk, and every assumption that is validated as false becomes an active risk or issue. Organizations that maintain a rigorous assumption log during initiation find that their risk identification process is faster, more complete, and more accurate — because the structured assumption log forces the team to articulate, at initiation, all the conditions under which the project is expected to succeed.

Other key process dependencies

What feeds into Initiation: Initiation is the first process of the project lifecycle, so its inputs come from outside the project itself: portfolio or program selection decisions, organizational business case approval processes, pre-project feasibility studies, and — in multi-phase projects — the outputs of the “Close Project or Phase” process from the preceding phase (lessons learned, updated assumption log, phase completion reports).

11. Quick-Application Checklist

Use these 10 items as a completion gate before treating initiation as done. For each item where the answer is “no” or “not yet,” treat it as an open action item before advancing to planning:

1. Has the business case (or equivalent justification) been reviewed, and does it provide a quantifiable reason for the project to exist?
2. Have all relevant agreements (contracts, MOUs, letters of intent) been reviewed and their constraints reflected in the charter?
3. Have individual interviews or an alignment session been conducted with the sponsor and at least two to three key stakeholders before drafting the charter?
4. Has a project canvas or structured alignment session been facilitated collaboratively (not completed solo by the PM)?
5. Does the project charter contain measurable SMART objectives — not generic statements of intent?
6. Is the project manager formally named in the charter with an explicitly documented scope of authority?
7. Is the charter formally approved — with a documented signature or approval record, not just verbal confirmation?
8. Does the assumption log contain all known assumptions at initiation, each with a named responsible party and a target validation date?
9. Have all key stakeholders been informed that the project has been formally authorized?
10. Has the approved charter been archived in the project repository as the baseline governance document?

Scoring: If fewer than 8 of these 10 items are confirmed, initiation is incomplete. The two or more missing items represent governance gaps that will most likely resurface as scope disputes, budget conflicts, or authority confusion during execution — at a much higher cost to resolve than the hour or two required to address them now.

Conclusion and Next Steps

Initiate Project or Phase is, by design, Process 1 of the Governance Domain in PMBOK 8 — and that position reflects a fundamental truth about project management: the decisions made (and the assumptions left undocumented) in the first days of a project shape everything that follows. The six weeks between Project Phoenix’s charter signing and the chatbot demand, and the architecture decision made in hour three of Project ProjectAdm’s initiation workshop that prevented a $15,000–$20,000 post-launch compliance crisis, illustrate this principle better than any abstract framework ever could.

Three takeaways for immediate application:

• A signed project charter is not bureaucracy — it is the PM’s most powerful protection instrument. It defines scope boundaries, documents authority, and creates a reference point for every dispute, change request, and scope negotiation that follows. Without it, the PM is operating on trust alone. That is not governance; it is hope.
• The assumption log is not a compliance artifact — it is a risk radar. Every undocumented assumption is a risk waiting to materialize without warning. The 12 assumptions documented in Project ProjectAdm’s initiation prevented at least two compliance crises from becoming actual ones. The multi-region architecture assumption alone — surfaced and decided in week one — prevented a $15,000–$20,000 GDPR data migration from appearing post-launch.
• Formal initiation scales — skipping it does not. A $72,000 website project and a $280,000 SaaS platform both require formal initiation. What scales is the depth and formality of the charter and the number of assumptions documented — not the existence of the process itself. Tailoring means adjusting the document, not eliminating it.

Your concrete next step: Open your current project. Locate the project charter. Check: is every objective SMART? Is the PM formally named with documented authority? Does an assumption log exist with named owners and validation dates? If any of these questions produces a “no,” you have identified your first governance improvement action. Address it before advancing to planning — because the cost of fixing a governance gap at initiation is measured in hours; the cost of fixing it at execution is measured in weeks.

See all PMBOK 8 articles in the Complete Index

🇧🇷 Leia este artigo em português

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.