Initiating (Focus Area)
Focus Areas are not project phases. They describe categories of work that can occur at any point in the life cycle and often overlap dynamically.
Definition
The Initiating Focus Area consists of those processes, practices, or actions performed to define a new project or new phase of an existing project. This area often includes formal authorization to start the project or phase. The purpose is to align stakeholders’ expectations and the project’s purpose, inform stakeholders of the scope and objectives, and discuss how their participation can help ensure their expectations are met.
Among the various initiating actions, the initial scope is defined and initial financial resources are committed. Stakeholders who will interact with and influence the overall outcome are identified and project management roles are assigned. The key benefit is that projects are only authorized when aligned with the organization’s strategic objectives and when the business case, benefits, and stakeholders are considered from the start.
Processes by Domain
| Process | Domain | Note |
|---|---|---|
| Initiate Project or Phase | Governance Domain | Creates the project charter; formally authorizes the project |
| Identify Stakeholders | Stakeholders Domain | Begins at project start; should be repeated as project evolves |
All other domain processes (planning, scope, schedule, finance, resources, risk) begin in the Planning focus area.
Key artifacts created
- Project charter — formal authorization document linking project to Business Case and strategy
- Assumption log — captures initial assumptions and constraints
- Stakeholder register — records identified stakeholders, interests, and influence
Key inputs from outside the project:
- Business Case — justifies the investment; written before the charter
- Benefits Management Plan — defines how benefits will be measured and realized
Key activities
- Define initial project scope, objectives, and success criteria
- Commit initial financial resources and formally authorize the project
- Identify stakeholders who will interact with and influence the project
- Assign the project manager (ideally during charter development, before planning begins)
- Develop project charter (formal authorization linking project to Business Case and strategy)
- Align stakeholder expectations on purpose, scope, constraints, and success criteria
- Review Business Case and Benefits Management Plan to confirm viability
Agile / hybrid considerations
- Adaptive project charters are lightweight — typically a vision statement or project canvas answering why/who/what/where/when/how
- Initial product backlog creation may begin during Initiating; product owner is identified here
- In hybrid, the high-level roadmap and governance structure are defined during Initiating even if sprint-level scope is adaptive
- Sponsor engagement is critical in all approaches — the sponsor approves the charter and champions the project regardless of development method
Exam angle
- PM assignment timing: PM should be assigned BEFORE planning begins — wrong answers assign PM after the charter is already written or after planning starts
- Charter = PM authority: the project charter grants the PM authority to apply resources — without it, PM cannot commit team members or budget; charter is not optional
- Business case before charter: business case is written first, approved by the sponsor, and then the charter references it — sequence is tested on the exam
- Agile initiating: a formal charter may be replaced by a project canvas or equivalent lightweight artifact, but some form of documented authorization is always expected — “no documentation needed in agile” is always wrong