This chapter is from the book
This chapter is from the book
This chapter is from the book
Initiating a Project
The initiating process group refers to the processes required to start a new project or start a phase of an existing project. The purpose is to
Ensure stakeholders have a clear and common understanding of the project or phase
Align stakeholders’ expectations with the project purpose at the beginning of the project or phase
Ensure that the project aligns with the organization’s strategic objectives
Ensure each phase aligns with the project’s objectives
Officially authorize the project to begin
However, we all know what happens in reality! Stakeholders might agree and understand the goals at the kickoff of the project, but they can rapidly forget them as the project progresses, leading to scope creep and unnecessary additional work throughout the project. So, it is the project manager’s responsibility to ensure that stakeholders have the same clear and common understanding of the goals throughout the project.
During the initiating stage of the project, the project charter is authorized by the sponsor, which allows the project manager to start detailed planning and to obtain resources for the project. Key stakeholders are also identified, and the project manager holds several meetings to ensure stakeholders understand and agree to their roles and responsibilities on the project. Involving the sponsor, customers, and other key stakeholders early in the project aims to create a shared understanding of the goals and success criteria and increases the likelihood of project acceptance and stakeholder engagement.
There are two processes in the initiating process group of the PMBOK® Guide, Sixth Edition, process map:
Develop Project Charter
Identify Stakeholders
Chapter 5, “Stakeholder Engagement,” describes the Identify Stakeholders process in detail. The Develop Project Charter process is discussed here.
Develop Project Charter
Develop Project Charter is the first of the PMBOK® Guide, Sixth Edition, processes; it establishes the authorization for the project to begin. This process documents how the project is aligned to the strategic objectives of the project, creates a formal record of the project, and describes the organization’s commitment to the project.
During this process, the project manager may be identified and assigned if they haven’t been already, and the project manager either assists the sponsor in writing the project charter, or the project manager may write the entire charter with the sponsor signing the charter after it is written. In all cases, the sponsoring entity must sign the project charter.
After the project charter has been authorized by the project sponsor, the project manager can start planning activities and assigning resources.
Key Artifacts of Developing the Project Charter
Several artifacts are related to developing the project charter. Some of these artifacts are starting points (inputs) for developing the project charter, and some artifacts are created as a result of this process (an output). The sections that follow describe these artifacts (business documents, project charter, project overview statement, and assumptions log) in more detail.
Business Documents
For PMI’s purposes, business documents are artifacts that are generally originated outside the project and used as a starting point (or an input) to developing the project charter. PMI refers to two such documents, as described in the sections that follow.
The Business Case
PMI defines the business case as “a documented economic feasibility study to establish the validity of the benefits.” It documents the reasons and objective for project initiation and provides the basis to measure success and progress throughout the project life cycle.
A business case may be developed for a variety of reasons, such as
Market demand
Organizational need
Customer request
Technological advancement
Legal requirements
Ecological impacts
Social need
The business case can include many items but typically contains the following:
Business Need
Identifies the gap, the problem, or the opportunity
Documents the reasons for doing the project and what would happen if you don’t do this project
Documents the value that should be achieved by performing the project and how the project aligns to the strategic goals of the organization
Analysis of the Situation
Identifies the organization’s goals, strategies, and objectives
Identifies the root cause of the gap, problem, or opportunity
Identifies any known risks and critical success factors
Decision criteria for actions to take to address the gap, problem, or opportunity, such as
– Required actions
– Desired actions
– Optional actions
Alternative courses of action
The business case also describes the recommended course of action and the plan for evaluating and measuring the benefits that will be delivered should the project be approved.
Benefits Management Plan
The benefits management plan documents how the benefits of the project will be realized. It describes how and when the benefits of the project will be delivered and describes the mechanisms that should be in place to measure those benefits. The exact benefit naturally varies from project to project as does the timeframe of when the benefit will be achieved. This is also dependent on the life cycle.
For example, a process improvement project may realize expected benefits immediately after the project is closed. However, the benefits of a project to create a new product expected to increase sales by $200 million a year might not be realized for a few years. Predictive projects typically realize benefits after the project is closed, whereas an agile project generally realizes benefits at the end of each sprint during the project.
The benefits management plan is developed early in the project, sometimes while the business case is being developed, and it typically contains the following:
Target Benefits: Describes the value the organization will achieve by performing this project.
Strategic Alignment: Describes how the value aligns with the strategic direction of the organization. Sometimes this may be obvious; sometimes it may not. For example, with a project to create a new product expected to increase sales by $200 million a year, it might be obvious to most people how that project fits in with the goals of the organization (increase sales and profits). However, a process improvement project that impacts only one department might not be as well understood as to how this project benefits the whole organization.
Timeframe: Describes when the benefits will be realized.
Benefits Owner: Describes who will record and monitor the benefits.
Metrics: Provides measurements that will be used to determine benefits realization.
Assumptions: Describes any assumptions you are making when planning the expected benefits.
Risks: Describes any risks involved in achieving the benefits (for example, competitors may build a similar product).
In addition, a benefits management plan should identify other stakeholders who might need to be involved in achieving the benefits (such as the sales and marketing team to promote a new product).
Per PMI, this document needs to be progressively elaborated on over time.
The Project Charter
The project charter is the formal authorization for the project to begin and, after it is signed by the sponsor, allows the project manager to apply organizational resources to project activities. It documents the business justification for the project and the reasons for the project to exist. The project charter is a high-level document that describes the measurable objectives and related success criteria; and it ensures a common understanding by the stakeholders of the key deliverables, milestones, and the roles and responsibilities of all involved.
The components of the project charter might include the following:
Identities of the project manager and the sponsor and their authority levels
High-level budget and schedule (as constraints, not baselines)
High-level scope and requirements
High-level assumptions and constraints
High-level risks
Any preassigned physical resources or team resources, such as specialized machines or key team members on the project
Any key stakeholders who have been identified
Summary of milestones and exit criteria in case of project failure
The stakeholder who will approve the deliverable
Although a summary document, the project charter is not a document that should be written quickly or without much thought. Because it constitutes the formal authorization for the project, care should be taken to involve appropriate decision makers and other key stakeholders to ensure everyone has a clear and common understanding of the project. Although a high-level document, it must also be a SMART document (Specific, Measurable, Achievable, Realistic, Time-bound). There are other small variations of this acronym, too.
Project Overview Statement
Another document that conveys the intent and vision of a project is the project overview statement. It communicates the intent and vision of the project and contains the following:
Problem or opportunity
Project goal
Project objectives
Success criteria
Assumptions, risks, and obstacles
Authorization of the project starts when the project charter is signed, or a project overview statement is approved. Then the project manager can start spending money on the project and obtaining resources.
Assumption Log
The assumption log documents all the detailed assumptions and constraints identified throughout the project. For example, if you need to use a machine that is shared among other teams, and that machine is available for only two hours a day, that constraint is documented in the assumption log. The team now knows that any activities that use said machine need to be scheduled during those available hours only.