Project initiation: business case, charter and stakeholders

Initiating is the first of the five focus areas, and it sets up everything that follows. Done well, it gives the project a clear purpose, an accountable sponsor, an authorized project manager, an initial understanding of who is affected and agreement on what success means. Done badly, it leaves the team arguing about scope and authority for months. This lesson covers the documents and activities of initiation at a foundations level: the business documents that justify the project, the project charter that authorizes it, the first identification of stakeholders, and how initiation looks in adaptive settings. PMP-121 and PMP-130 build on these topics in depth.

Before the project: business documents

Projects are usually justified before they are formally started. Two business documents, introduced in lesson 2, carry this justification. The business case documents the economic feasibility and strategic rationale for the project: the business need, the analysis of the situation, options considered, the recommended option, and the expected costs, benefits and risks. The benefits management plan explains how and when benefits will be delivered and measured. These documents are typically owned by the sponsor or a business unit, not by the project manager, though the project manager may help develop them and must understand them.

A good business case considers several options, including doing nothing. Options analysis forces the organization to compare alternatives honestly. For each option, the case typically states costs, benefits, risks, timing and fit with strategy, and then recommends one. Needs assessment, sometimes called business analysis, may come first: understanding the problem or opportunity, current-state gaps and the stakeholders affected.

The project charter

The project charter is the document issued by the project initiator or sponsor that formally authorizes the existence of a project and provides the project manager with the authority to apply organizational resources to project activities. It links the project to the organization's strategic objectives and creates a shared understanding of the project at a high level. Ideally, the project manager is assigned before or while the charter is developed, so they can help shape it.

The charter is deliberately high level. It is not the project management plan, which comes later and contains detailed baselines. Nor is it a contract, though on projects for external customers it may be supported by one. Once signed, the charter is changed only with the sponsor's approval. In exam scenarios, if team members are confused about the project manager's authority or the project's purpose, revisiting or creating the charter is often the right answer. If a project starts work without a charter, the project manager should work with the sponsor to create one.

Alongside the charter, the team starts an assumption log, recording high-level assumptions and constraints identified during initiation. Lesson 8 explained how these trace back to EEFs and OPAs. The assumption log continues throughout the project and is regularly reviewed.

Identifying stakeholders

A stakeholder is an individual, group or organization that may affect, be affected by, or perceive itself to be affected by a decision, activity or outcome of a project. Identifying stakeholders begins in initiation and continues throughout the project, because new stakeholders appear and existing ones change their interest or influence. The output is a stakeholder register, which records each stakeholder's identification information, assessment (such as requirements, expectations, influence and interest) and classification.

Stakeholders include the sponsor, customers and users, the project team, functional managers, the PMO, operations staff, suppliers, regulators, communities, and sometimes the public or the media. Stakeholders can be supportive, neutral or resistant, and some may never be satisfied. Missing a stakeholder early is a frequent cause of late surprises: a regulator who was not consulted, a union that was not informed, a community group that learns about a project from the news.

Other classification models add dimensions. A salience model considers power, urgency and legitimacy. A stakeholder cube adds attitude. Direction of influence describes whether a stakeholder is upward (senior management), downward (team), outward (suppliers, regulators) or sideward (peer project managers). For the exam, focus on the purpose of classification: to decide how much engagement each stakeholder needs and what kind.

Initiation in adaptive settings

Adaptive projects still need authorization, a purpose and known stakeholders, but the artifacts look different. Instead of, or alongside, a detailed charter, teams may use a product vision statement, a lean canvas or a team charter. A product vision states who the product is for, what problem it solves and how it differs from alternatives. Funding may be allocated to a product team for a period rather than to a fixed scope. The team charter, covered in PMP-120, sets working agreements such as values, communication norms and the definition of done. An initial product backlog captures high-level features or epics, to be refined later.

Hybrid projects often combine a formal charter for governance with a product vision for the adaptive team. What matters is that someone with authority has approved the project and its funding, the project manager or team lead knows the limits of their authority, and everyone shares an understanding of why the project exists and how success will be judged.

Canadian federal projects typically move through departmental gates during initiation. A business case and a Project Complexity and Risk Assessment are prepared, and for projects above a department's approved capacity or financial thresholds, Treasury Board approval is sought, often in two stages: preliminary project approval and effective project approval. Indigenous consultation, accessibility and official languages considerations may need to be identified as stakeholder and requirement issues at this stage.

Common initiation problems

Several patterns appear repeatedly in practice and on the exam. The project starts without a charter, so authority is disputed. Objectives are vague ("improve customer service") rather than measurable ("reduce average response time from 48 to 24 hours by June"). Key stakeholders are missed. The sponsor is absent or disengaged. The project manager is assigned after commitments have been made. Each has a typical remedy: create or revisit the charter with the sponsor, make objectives SMART (specific, measurable, achievable, relevant and time-bound), broaden stakeholder identification, secure the sponsor's engagement and clarify authority early.

Kickoff

Initiation usually ends, and planning begins, with a kickoff meeting, though some organizations hold one kickoff at the end of initiation and another when execution starts. A kickoff brings together the sponsor, the team and key stakeholders to share the project's purpose, objectives, scope boundaries, high-level schedule, roles, governance and ways of working. It is also a chance to build relationships and surface concerns early. A good kickoff ends with participants able to explain, in their own words, why the project matters and how they contribute.

In adaptive projects the equivalent might be a chartering or inception workshop in which the team, product owner and key stakeholders agree the vision, high-level backlog, working agreements and first release goals. The format differs; the purpose of shared understanding is the same.

After the kickoff, the project manager confirms that actions are recorded, that the stakeholder register and assumption log reflect what was learned, and that any concerns raised are logged as risks or issues. Initiation is complete when the charter is approved, key stakeholders are identified and the team is ready to plan in detail. Moving into planning without these foundations usually costs more time later than it saves now.

One more point about the charter: it is valuable precisely because it is short. A two- or three-page charter that people actually read does more for alignment than a forty-page document nobody opens. If stakeholders want more detail, that detail belongs in the project management plan, the requirements documentation or the business case, which the charter can reference. Keep the charter focused on purpose, success, boundaries, authority and the few facts everyone must share.