Starting a Project and Integration
By Gregory M. Horine and Asad E. Haque
Date: Jul 3, 2023
In this sample chapter from Project Management Professional (PMP)® Cert Guide, you will learn the key processes, tools, and artifacts for starting a project and integration management, from starting a project to monitoring it.
This chapter discusses the key processes, tools, and artifacts for starting a project and integration management. The following topics are covered:
What Is Integration Management?: Review the project management plan and learn how each component is integrated to create the plan.
Initiating a Project: Review the common processes, tools, and artifacts needed to start the project.
Planning a Project: Examine the common processes, tools, and artifacts needed to plan the project.
Executing the Project: Learn the common processes, tools, and artifacts needed to execute the project to deliver value.
Monitoring and Controlling the Project: Review the common processes, tools, and artifacts needed to determine the performance of the project. Although change control is discussed in detail here, other important concepts of monitoring and controlling are discussed in Chapter 14, “Project Measurement.”
In this chapter, we discuss in detail the initiating, planning, and executing aspects of integration management as needed for the PMP exam. The monitoring and controlling aspects of change control are discussed here, but other important concepts of monitoring and controlling are discussed in Chapter 14, “Project Measurement.” Chapter 15, “Closing a Project,” discusses the closing processes in detail.
We discuss the principles related to the PMBOK® Guide, Sixth Edition; the PMBOK® Guide, Seventh Edition; and the Exam Content Outline (ECO).
This chapter addresses the following objectives from the PMP Exam Content Outline:
Domain |
Task # |
Exam Objective |
|---|---|---|
People |
Task 2 |
Lead a team |
People |
Task 3 |
Support team performance |
People |
Task 6 |
Build a team |
People |
Task 7 |
Address and remove impediments, obstacles, and blockers for the team |
People |
Task 9 |
Collaborate with stakeholders |
People |
Task 10 |
Build shared understanding |
People |
Task 11 |
Engage and support virtual teams |
Process |
Task 1 |
Execute project with the urgency required to deliver business value |
Process |
Task 2 |
Manage communications |
Process |
Task 3 |
Assess and manage risks |
Process |
Task 4 |
Engage stakeholders |
Process |
Task 7 |
Plan and manage quality of products/deliverables |
Process |
Task 9 |
Integrate project planning activities |
Process |
Task 12 |
Manage project artifacts |
Process |
Task 15 |
Manage project issues |
Process |
Task 16 |
Ensure knowledge transfer for project continuity |
Business |
Task 2 |
Evaluate and deliver project benefits and value |
“Do I Know This Already?” Quiz
The “Do I Know This Already?” quiz allows you to assess whether you should read this entire chapter thoroughly or jump to the “Exam Preparation Tasks” section. If you are in doubt about your answers to these questions or your own assessment of your knowledge of the topics, read the entire chapter. Table 4-1 lists the major headings in this chapter and their corresponding “Do I Know This Already?” quiz questions. You can find the answers in Appendix A, “Answers to the ‘Do I Know This Already?’ Quizzes and Review Questions.”
Table 4-1 “Do I Know This Already?” Section-to-Question Mapping
Topics Section |
Questions |
|---|---|
What Is Integration Management? |
1 |
Initiating a Project |
2–3 |
Planning a Project |
4–6 |
Executing the Project |
7–8 |
Monitoring and Controlling the Project |
9–10 |
1. Who should the project manager interact with when performing integration processes?
The sponsor
Team members
Key decision makers on the project
Any stakeholder
2. Which of the following is not documented in the project charter?
Requirements
Business justification
Team ground rules
Identified resources
3. Of the following, which represent the purpose of creating the project charter? (Choose two.)
Officially authorizes the project to begin
Documents the baseline budget for the project
Creates the detailed scope of the project
Ensures stakeholders have a clear and common understanding of the project
Details the deliverables and timelines of the project
4. When is the project management plan baselined?
When all stakeholders have approved and signed off
When the sponsor and senior management have approved and signed off
When all the required stakeholders have approved and signed off
When the project team has approved and signed off
5. You are near the end of a sprint when a stakeholder identifies some additional requirements they would like to include. What should you do?
Decline the request because you are near the end of the sprint.
Add the requirement to the product backlog.
Perform an impact analysis and send a change request to the change control board.
Implement the additional requirement.
6. The project manager has completed the project management plan and sent it to the sponsor, other key stakeholders, and team leads for their approval. Upon review, one of the team leads notices an important activity is missing and requests that it be added to the project management plan. What should the project manager do?
Perform an impact analysis of the missing activity.
Submit a change request because the team lead has already performed the impact analysis and stated that the activity needs to be added.
Advise the team lead that adding the activity at this stage is gold plating.
Add the missing activity to the project management plan.
7. You are requesting a status from your team. One team member states that they are 60 percent complete and the activity has cost $48,000 so far. How would you classify these results?
Work performance information
Work performance data
Work performance figures
Work performance reports
8. Which of the following are examples of business value? (Choose three.)
25 percent increase in sales
Finish by September 30
3 percent increase in market share
Our product will be well-known nationwide
Project budget of $150,000
9. Your team lead has approached you with an issue that you think might be a quick and easy fix. However, this was not in the original scope of the project. What should you, as project manager, do next?
Tell the team lead to go ahead and fix the issue because it’s a quick and easy fix.
Perform an impact analysis.
Document and submit the change request to the change control board.
Inform the sponsor.
10. You are managing a project for a client to move a data center and call center offshore. Many changes have been made throughout the project, but you notice that during meetings team members frequently refer to different versions of the same document, which is causing confusion. What would have prevented this?
Assigning one team member to ensure all documents are up to date
Implementing an adequate change control system
Ensuring the file management system procedures are being followed
Implementing an adequate configuration management system
Foundation Topics
Understanding the vision and purpose of a project is the key to successful planning, and communicating the vision and purpose of a project regularly is the key to successful implementation.
Every project needs to have a purpose and needs to align with the strategic direction of the organization. If it does not, you need to ask, “Why are we doing this project?”
In this chapter, we discuss the initiation and integration elements of projects and how the project manager must balance the constraints, processes, and needs of stakeholders so that project success can be achieved.
We first discuss the initiation of the project and describe the major artifacts for starting a project. We then move on to the planning of a project and discuss the many artifacts that constitute the project management plan. We also discuss the aspects of executing a project to achieve project success before finally moving on to the monitoring and controlling aspects of integration management.
All of these processes appear in the PMBOK® Guide, Sixth Edition, knowledge area of integration management, so let’s begin with integration management.
What Is Integration Management?
Project management processes and procedures are performed throughout the project multiple times, simultaneously. Although technical project work may be performed once on certain projects (especially on predictive projects), the project management processes themselves are performed throughout. The constraints of budget, schedule, resources, risks, scope, quality, regulations, and standards all impact one another, so the project manager must balance all of these factors simultaneously when managing a project. The project manager must guide the team and ensure they are collaborating and working together to achieve project success. The project manager must also understand the strategic objectives of the project and ensure they align with the goals and expectations of the program and the portfolio.
Integration management is the key to performing these processes and a critical success factor on projects. It is an essential skill set for project managers. This is also the first knowledge area of the PMBOK® Guide, Sixth Edition, which describes integration management as “the processes and activities to identify, define, combine, unify and coordinate the various activities within the project management process groups.”
As with any definition, it may sound a little confusing, so let’s examine what it means. Knowledge areas represent the areas of project management that need to be properly planned, managed, and controlled, and integration management is the area in which the project manager must have expertise. A failure in any one knowledge area may lead to a failure of the project. However, all knowledge areas impact one another, so the processes and activities of all knowledge areas must be performed simultaneously. For example, the scope of the project directly impacts the cost and schedule, and vice versa. When you are determining any changes to the scope of a project, you simultaneously think about the impact to the budget, timeline, resources, risks, quality, and other factors. If material prices suddenly increase, your project may end up going over budget, and this may result in a reduction of the scope of the project. A sudden increase in processing of raw materials is usually accompanied by delays in delivery of said raw materials, which in turn has an impact on the project schedule.
As a project manager, you must balance all these constraints and processes to ensure project success.
Integration management is not a standalone knowledge area by itself, but moreover it is a combination of all the other knowledge areas. The fact that you are performing the tasks of all the knowledge areas simultaneously means that you are integrating the processes of your project. Integration management is sometimes known as the “master” knowledge area because it includes all other knowledge areas and essentially means that processes are performed concurrently.
Whereas the tasks of other knowledge areas may be delegated to team members and specialists (such as development of the schedule, budget, and risk management process), the processes of integration can be performed only by the project manager because the PM brings all of these processes together as a unified whole. The project manager brings teams and team members together to perform all the tasks of the project in unison. Thus, on predictive projects the project manager is ultimately accountable for the project by ensuring that all these processes work in unison.
Table 4-2 shows the PMBOK® Guide, Sixth Edition, integration management processes and the process groups each process relates to. This is an extract from page 25 of the process map in the PMBOK® Guide, Sixth Edition.
Table 4-2 Integration Management Processes and Process Groups
Process Group Knowledge Area |
Initiating |
Planning |
Executing |
Monitoring and Controlling |
Closing |
|---|---|---|---|---|---|
4.0 Project Integration Management |
4.1 Develop Project Charter |
4.2 Develop Project Management Plan |
4.3 Direct and Manage Project Work 4.4 Manage Project Knowledge |
4.5 Monitor and Control Project Work 4.6 Perform Integrated Change Control |
4.7 Close Project or Phase |
Notice that this is the only row of the process map that is fully populated, further signifying the importance of this knowledge area. In performing each of these processes of integration management, the project manager performs all the respective processes in the knowledge areas that fall below integration management on the process map.
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.
Planning a Project
The PMBOK® Guide, Sixth Edition, discusses planning in the planning process group. The PMBOK® Guide, Seventh Edition, discusses planning in the Planning Performance domain.
Planning is the foundation for all project success. Many projects fail due to inadequate planning. Planning is considered one of the critical steps toward project success because it provides the structure and foresight for the execution and monitoring steps of a project. It is an essential guide for the project manager, project teams, stakeholders, and sponsors to achieve successful completion of each stage of the project.
However, there are different levels of planning based on the size and nature of the project and the development approach. In predictive projects, detail planning is done at the beginning of the project, and any changes to the plan need to be constrained and go through a change control process. In agile, only a high-level “relative estimate” is made at the beginning of the project, with the detailed estimates performed per sprint.
Per the PMBOK® Guide, Seventh Edition, “the Planning Performance domain addresses the activities and functions associated with the initial, ongoing, and evolving organization and coordination necessary for delivering project deliverables and outcomes.”
Throughout the planning process, the project manager must consider internal and external factors that could impact the project. The PM needs to identify assumptions and constraints that could lead to uncertainty and risks on the project. The project manager also needs to progressively elaborate on projects to ensure correct ranges are calculated and management plans are updated. However, planning also needs to be an efficient process. If there are many unknowns and many uncertainties on a project (risks), it is challenging to perform detailed planning of the scope. In this case, more time should be spent on planning for risk, and the scope should be progressively elaborated over time. The project manager and the project team determine the exact parameters of planning.
Some of the key points regarding planning are that
Time spent on planning should be appropriate for the project. It is very easy to “overplan” when there are many uncertain parameters that impact the project. Likewise, not enough planning may lead to issues and problems during delivery.
Planning is sufficient to deliver value and manage stakeholders’ expectations. The purpose of a project is to deliver value for the customer, so the project manager and/or team must plan sufficiently to deliver the value. The exact meaning of value differs based on many parameters, such as the nature of the project, the stakeholders, and the industry. This issue is discussed in more detail later in the “Executing the Project” section of this chapter.
Project plans are progressively elaborated on throughout the project life cycle to adapt to changes as needed. This is true for both predictive and adaptive projects. A change to one project constraint may lead to a change in another constraint, so plans need to be able to adapt (even on predictive projects).
Variables that impact project planning can include
Development Approach
Based on whether this is a predictive, adaptive, incremental, iterative, or hybrid project, this approach can influence how much planning and the type of planning that needs to be done.
You might need to plan phases, iterations, increments, or sprints.
Project Deliverables: The product or service that is being delivered determines the type and extent of planning. For example, a construction project requires extensive planning to minimize scope changes, whereas the scope of research and development projects can be dynamic.
Organizational Requirements: The company’s governance, policies, procedures, and culture determine project planning procedures.
Market Conditions: External factors such as scarcity of resources and competition determine the level of planning that needs to be performed. If, for example, a competitor is releasing a superior product to yours, the schedule for your upgrade project may need to be moved forward, thus impacting planning.
Legal or Regulatory Requirements: Your project might need regular approvals from regulatory authorities before proceeding to the next stage. This step needs to be planned, but any delays need adjustment to the schedule and plans. For example, construction projects require inspections at various stages. If the inspector doesn’t approve the deliverable, it needs to be fixed before the building team can continue to the next stage.
The PMBOK® Guide, Sixth Edition, defines the planning process group as consisting of the processes required to establish the scope of the project, refine the objectives, and define the course of action required to attain the objectives that the project was undertaken to achieve.
Twenty-four processes in the PMBOK® Guide, Sixth Edition, process map are associated with the planning process group, as shown in Table 4-3. There are 49 processes altogether in the entire process map, and almost half of them are in planning, showing that PMI has placed a huge emphasis on planning a project.
Table 4-3 PMBOK Guide, Sixth Edition, Knowledge Areas and Processes Associated with the Planning Process Group
Knowledge Area |
Planning Processes |
|---|---|
Project Integration Management |
Develop Project Management Plan |
Project Scope Management |
Plan Scope Management Collect Requirements Define Scope Create WBS (Work Breakdown Structure) |
Project Schedule Management |
Plan Schedule Management Define Activities Sequence Activities Estimate Activity Durations Develop Schedule |
Project Cost Management |
Plan Cost Management Estimate Cost Determine Budget |
Project Quality Management |
Plan Quality Management |
Project Resources Management |
Plan Resource Management Estimate Activity Resources |
Project Communications Management |
Plan Communications Management |
Project Risk Management |
Plan Risk Management Identify Risks Perform Qualitative Risk Analysis Perform Quantitative Risk Analysis Plan Risk Responses |
Project Procurement Management |
Plan Procurement Management |
Project Stakeholder Management |
Plan Stakeholder Management |
In this chapter, we concentrate on the integration management aspects of planning. The other planning processes are discussed in the appropriate chapters related to those knowledge area topics.
The PMBOK® Guide, Sixth Edition, planning process for integration management is called Develop Project Management Plan, which includes the plans for all the other knowledge areas.
Table 4-4 highlights the PMBOK® Guide, Sixth Edition, process that we describe in this section.
Table 4-4 PMBOK® Guide, Sixth Edition, Develop Project Management Plan
Process Group Knowledge Area |
Initiating |
Planning |
Executing |
Monitoring and Controlling |
Closing |
|---|---|---|---|---|---|
4.0 Project Integration Management |
4.1 Develop Project Charter |
4.2 Develop Project Management Plan |
4.3 Direct and Manage Project Work 4.4 Manage Project Knowledge |
4.5 Monitor and Control Project Work 4.6 Perform Integrated Change Control |
4.7 Close Project or Phase |
The Project Management Plan is made up of many planning documents (artifacts), as follows:
Subsidiary Management Plans, which include
Scope Management Plan
Requirements Management Plan
Schedule Management Plan
Cost Management Plan
Quality Management Plan
Resource Management Plan
Communications Management Plan
Risk Management Plan
Procurement Management Plan
Stakeholder Engagement Plan
Baselines, which include
Scope Baseline
Schedule Baseline
Cost Baseline
Additional Components, which include
Change Management Plan
Configuration Management Plan
Performance Measurement Baseline
Project Life Cycle
Development Approach
Management Review
Understanding the purpose of each of the components of the project management plan is important, so let’s discuss each of these components.
Subsidiary Management Plans
Each of the subsidiary management plans documents how you are to plan, execute, manage, and control the respective knowledge area. They do not contain the actual results of that knowledge area.
For example, the requirements management plan does not contain any requirements. It documents the procedures for collecting requirements. It documents how you are going to collect requirements, what tools you are going to use to collect requirements, and the level of details you need to collect requirements. It also documents procedures for missed requirements and procedures for adding new requirements.
Likewise, the cost management plan does not tell you what the project is going to cost. It documents how you are going to estimate cost, the formulae used, the assumptions made, and the procedures for trying to get back on track if you start to go over budget.
All subsidiary management plans document procedures on how to plan, execute, manage, and control each particular knowledge area.
The only subsidiary management plan that does not have the words management plan in the title is the stakeholder engagement plan. However, it, too, documents procedures on how to engage and motivate stakeholders.
It’s also important to understand that a project manager does not know all these procedures at the beginning of the project. The project manager must work with the project team to figure out all these procedures throughout the project and progressively elaborate on the plan documents as necessary.
Baselines
A baseline is simply the approved version of a plan. Plans need to be approved by appropriate stakeholders, such as the project manager, sponsor, project leadership team, and key members of the project team. During planning, the project manager, senior management, and other key stakeholders determine who will have such approval responsibilities.
The three basic baselines—the scope baseline, schedule baseline, and cost baseline—represent the approved versions of the scope, schedule, and budget, respectively. In addition, a fourth baseline, the performance measurement baseline, represents these three basic baselines combined.
These baselines represent the plan for the project, and actual results are compared against the baselines. However, the main significance of the baselines is that any changes to the baselines must go through a change control process.
On predictive projects, changes must be properly controlled, so changes always need to go through a change control process.
The work of the project is executed according to the baseline.
Actual results are compared to the baseline.
Subsequent changes must go through the change control process.
Project may be re-baselined after sign-off from appropriate stakeholders.
On pure agile projects, there are no baselines. The scope of the work is determined by the product backlog, which will change as user stories are added, removed, and reprioritized.
Additional Components
Two additional management plans and an additional baseline are listed under this subsection, as follows:
Change Management Plan: Documents the procedures for change control.
Configuration Management Plan: Documents procedures regarding version control.
Performance Measurement Baseline: This artifact is a combination of the scope, schedule, and cost baselines.
Three other documents listed in this section are
Project Life Cycle: Discussed in Chapter 3, “Development Approach and Life Cycle Performance,” these are the series of stages a project goes through from start to finish.
Development Approach: This document identifies the approaches used, such as predictive, agile/adaptive, iterative, incremental, or hybrid.
Management Review: This document provides the points on the project where appropriate stakeholders will review project progress and make appropriate decisions.
Table 4-5 is an extract of the PMBOK® Guide, Sixth Edition, process map highlighting the planning group and the processes referred to in the preceding exam tip.
Table 4-5 PMBOK® Guide, Sixth Edition, Processes in Planning
Process Group Knowledge Area |
Initiating |
Planning |
|---|---|---|
4.0 Project Integration Management |
4.1 Develop Project Charter |
4.2 Develop Project Management Plan |
5.0 Project Scope Management |
|
5.1 Plan Scope Management 5.2 Collect Requirements 5.3 Define Scope 5.4 Create WBS |
6.0 Project Schedule Management |
|
6.1 Plan Schedule Management 6.2 Define Activities 6.3 Sequence Activities 6.4 Estimate Activity Durations 6.5 Develop Schedule |
7.0 Project Cost Management |
|
7.1 Plan Cost Management 7.2 Estimate Costs 7.3 Determine Budget |
8.0 Project Quality Management |
|
8.1 Plan Quality Management |
9.0 Project Resource Management |
|
9.1 Plan Resource Management 9.2 Estimate Activity Resources |
10.0 Project Communications Management |
|
10.1 Plan Communications Management |
11.0 Project Risk Management |
|
11.1 Plan Risk Management 11.2 Identify Risks 11.3 Perform Qualitative Risk Analysis 11.4 Perform Quantitative Risk Analysis 11.5 Plan Risk Responses |
12.0 Project Procurement Management |
|
12.1 Plan Procurement Management |
13.0 Project Stakeholder Management |
13.1 Identify Stakeholders |
13.2 Plan Stakeholder Engagement |
Executing the Project
Executing the project refers to implementing the plan and performing the work of the plan to create the deliverables.
The PMBOK® Guide, Sixth Edition, processes of executing in integration management are
Direct and Manage Project Work
Manage Project Knowledge
The PMBOK® Guide, Seventh Edition, discusses execution and delivery of the project in the following Performance domains:
Project Work Performance Domain
Delivery Performance Domain
We discuss the main contents of these Processes and Performance domains as they relate to the PMP exam.
First, let’s examine the purpose of executing the project. The main purpose of execution is to deliver the business value of the project.
The exam content outline (ECO) mentions two tasks related to business value as follows:
Process Domain Task 1: Execute the project with the urgency required to deliver business value.
Business Environment Domain Task 2: Evaluate and deliver project benefits and value.
With two ECO tasks mentioning value, you can see the significance that PMI places on this term for the PMP exam.
It is important to understand what is meant by business value.
What Is Business Value?
Business value is the net quantifiable benefit derived from the business endeavor that may be tangible, intangible, or both. The reason for doing a project in the first place is to realize the business value, and this value varies depending on the project. For example, the benefit of one project may be to increase market share, whereas the benefit of another may be to improve processes. Benefits can also be intangible; for example, the benefits of a homeowner building a house are that the owner moves into their dream home.
Some examples of tangible benefits include
Financial
Market share
First to market
New customer
Technological
Improvements
Social
Equity
Some examples of intangible benefits include
Goodwill
Brand recognition
Reputation
Strategic alignment
When does the business value get realized? It depends!
The time frame determining when business value will be realized is dependent on many factors. On a predictive project, the business value generally is realized after the close of the project, whereas on an agile project, the business value is realized at the end of each sprint. The benefits of a process improvement project may be realized at various increments throughout the project, whereas a new product development project aimed at increasing sales, profits, and market share may not be realized for several months or even years after the start of production.
At a project level, business value needs to be defined and understood during the early stages of the project. The project charter documents what success and failure mean on the project.
What Does Project Success Mean?
Is project success achieved by being within schedule and budget? Is that the true measure of project success?
For the most part, many people will say yes to this question. For many project managers, the classic success criteria for a project are being within schedule and within budget.
However, is that really a true and accurate measure of success? There is no right or wrong answer to this; it depends on many factors and situations.
For example, let’s say a new product development project was expected to increase sales by $5 million a year, and this project finished 10 percent ahead of schedule and 5 percent under budget. At this point, you would be congratulating yourself on a job well done; however, if the sales ended up so low that the company went out of business, would this be considered a success now?
On the other hand, if this same project ended up 10 percent behind schedule and 20 percent over budget, you would initially be concerned by these metrics and might need to explain to senior management what went wrong. But if the sales doubled expectation, then would you consider this a failed project? Absolutely not.
So, measuring project success and failure based on budget and schedule alone may not always be the best metrics to use. You need to look at the overall picture and consider the business value. Success on a project should be determined by whether the business value was attained.
There are various different ways of measuring business value, such as
Benefit-Cost Ratio
Return on Investment (ROI)
Internal Rate of Return (IRR)
Present Value (PV)
Net Present Value (NPV)
On adaptive projects, business value is realized at the end of each sprint when the product owner approves the deliverables, which in turn creates the potentially shippable product increment. Two important terms related to this are
Minimum Viable Product (MVP): This is the smallest collection of features that can be included for a product to be considered functional. These are the bare-bones, no-frills type of functionality required for the product or system to work. As an analogy, these could be considered the must-haves of the MoSCoW analysis. The aim is to do the minimum amount of work to deliver value to the customer.
Minimum Business Increment (MBI): This is the smallest amount of value that can be added to a product or service that benefits the business. The aim is to deliver the highest value first.
Now that you understand business value, plus the success and failure of a project, let’s further discuss the execution of the project within this context.
The Project Work Performance domain of the PMBOK® Guide, Seventh Edition, results in the efficient and effective project performance where the team uses appropriate processes and tools to complete the work and produce the deliverables. The project work keeps the team focused and the project activities running smoothly by managing the workflow; effectively and efficiently communicating with stakeholders; and managing materials, equipment, supplies, logistics, and vendors.
The project manager and the project team should regularly review the processes and procedures to identify any inefficiencies and bottlenecks and resolve issues and impediments. The team might use lean systems such as the value stream map to identify such bottlenecks and use continuous improvement tools such as retrospectives and lessons learned to make small, incremental, and continuous improvement steps. The project manager has the responsibility to maintain the team’s focus on the work and ensure the sense of urgency is instilled to deliver the work in a timely manner.
Now let’s discuss the two PMBOK® Guide, Sixth Edition, processes of executing in integration management.
Direct and Manage Project Work
The project manager is the visionary leader of the project and as such must constantly communicate the goals and value to stakeholders throughout the project. The project manager must also ensure that deliverables and goals are met throughout the project by ensuring that the team is consistently performing the appropriate tasks to meet those goals and expectations. The project manager must therefore instill a culture of urgency throughout the project to ensure deliverables are being met and stakeholders agree with the timeline of these deliverables.
Direct and Manage Project Work is the process of implementing the plan and leading the execution of the plan. The project manager leads the team through the execution of tasks and activities. The result of executing the work is to create the deliverables of the project, which then are tested as part of the quality management process (discussed in Chapter 11, “Project Quality”).
Another major result of this process is to create the work performance data that will be analyzed and compared to the plan to create the work performance information and summarized in the work performance report.
Let’s look at these terms in detail:
Work Performance Data (WPD): This refers to raw observations or actual results. This data provides no context and must be analyzed to understand what it means. For example, a page of numbers collected by market research may be meaningless without any analysis. For a project, an example might be, “We have spent $50,000 so far on this project.”
Work Performance Information (WPI): This is the interpretation of the data, and it provides some meaning to what the data means. For example, after the pages of numbers from the previous example have been analyzed, the interpretation of those numbers is the work performance information. A project example is, “We are $5,000 over budget.”
Based on the previous example, if you have spent $50,000 so far but should have spent $45,000, you are $5,000 over budget. In this example, the $50,000 is the work performance data (actual results), the $45,000 is the plan, and the $5,000 over budget is the work performance information. To get the work performance information, you should always compare the actual results with the plan.
Work Performance Report (WPR): This is a representation or a summary of the work performance information in a physical or electronic report format that is used for decision-making and shows the status of the project. Because the information contains the data and the plan, it could be regarded as containing all three.
Manage Project Knowledge
Learning new knowledge, reusing existing knowledge, and transferring knowledge are important skill sets for team members and critical success factors for collaboration and project success.
Team members must not hoard knowledge but should share their knowledge with other team members and stakeholders as needed. This aids in collaboration and engagement. When we all learn from one another, we all develop new skills and understanding, and we all win.
Knowledge transfer also includes passing on information and knowledge to other stakeholders, such as the ongoing operations team. At the end of the project, the project team will pass on pertinent information to the production team or operations team so that they understand the capabilities and weaknesses of the deliverable. This information will be in the form of documentation, meetings, work shadowing, and training the production staff.
There are two classifications of knowledge:
Explicit Knowledge: This knowledge is tangible and easily codified into words, pictures, numbers, chart, graphs, reports, and so on. For example, this book is considered explicit knowledge.
Tacit Knowledge: This knowledge is more intangible and personal, based on beliefs, thought processes, insights, and experiences. This type of knowledge is more difficult to express and codify. For example, your experience as a project manager and your approach to resolve an issue based on your past experience are tacit knowledge.
Knowledge management refers to both explicit knowledge and tacit knowledge. You should always learn new knowledge and reuse existing knowledge (lessons learned).
Knowledge transfer refers to both explicit and tacit knowledge. Knowledge within an organization exists on three levels:
Individual Knowledge: This is mostly tacit knowledge but can include some explicit knowledge.
Project Knowledge: This is mostly explicit knowledge because it refers to project documentation.
Organization Knowledge: This is mostly explicit knowledge because it refers to the organization’s documentation (OPA). This term also refers to such knowledge as the skills and experiences of employees that can be reused across the organization.
Tacit knowledge generally resides within the minds of individuals, and it is not possible to force people to share their knowledge and experiences. Consequently, creating an atmosphere of trust among team members is important so that they are motivated to share their experiences and knowledge. Even the best tools and processes will not work if people are not motivated to share what they know or pay attention to what others know. Effective transfer of knowledge includes both knowledge management tools and documentation as well as interactions and networking between people.
A key artifact of Manage Project Knowledge is the lessons learned register, which documents what went well, what went badly, and what improvements can be made. However, that is not the only artifact for knowledge management. All project documentation is a form of knowledge transfer, so all project documents are used for managing project knowledge.
Monitoring and Controlling the Project
Monitoring and controlling refers to comparing the actual results with the plan, which is a task that a project manager performs throughout the project. This is the process of tracking, reviewing and regulating the performance of the project to determine whether corrective actions, preventive actions, or defect repair (rework) is needed. You are essentially determining the health of the project by comparing metrics. For example, you need to determine whether the project is ahead of schedule or behind schedule by comparing the actual schedule with the planned schedule. You also need to determine whether the project is over or under budget by comparing the actual amount spent with the planned amount that should have been spent.
The actual results are known as work performance data.
This is compared against the plan to determine the variance.
The interpretation of the variance is considered work performance information.
For example,
“We have spent $30,000 so far on this activity” is our work performance data.
“We should have spent $25,000 so far on this activity” is our plan.
“The difference of −$5,000 is our variance.”
“Therefore, we are $5,000 over budget so far” is our work performance information.
Any changes to the baseline must go through a change control process.
On adaptive projects, monitoring and controlling may compare the actual number of user stories approved so far versus what was planned at this stage (or the actual story points delivered versus the story points planned).
For more details on monitoring and controlling, see Chapter 14. Here we concentrate on one aspect, integrated change control.
Integrated Change Control
On predictive projects, having a robust and efficient change control process is vital to ensure changes are properly controlled and approved. Otherwise, the project may end up with runaway costs, it may fall way behind schedule, and tasks may be performed inefficiently and haphazardly.
The perform integrated change control process of the PMBOK® Guide, Sixth Edition, is the process of reviewing, approving, and managing all changes on a project.
The project manager must properly control all changes on a project. The PM does not need to eliminate all changes, but those changes do need to be properly controlled. The project manager needs to prevent unnecessary changes to a project.
Why is that?
On predictive projects, most changes are going to cost money! You need to determine who is going to pay for it. So, changes need to go through a proper change control process to avoid scope creep, gold-plating, and uncontrolled costs. Of course, there may be other impacts to the project as well, such as schedule and resources, but regardless, they still need to be properly controlled.
There are many reasons why you would need to go through a change control process, such as
Team members realize they missed a requirement.
The customer wants to include some additional requirements.
Senior management decides to increase the scope.
A machine breaks down and needs to be fixed or replaced (corrective action).
One of the components of the machine is wearing down and may cause the machine to fail. You need to replace that part before the machine fails (preventive action).
There are regulatory changes.
These are just a few reasons why you may need a change on a project. This is not an exhaustive list by any means.
Key Artifact of Integrated Change Control: Change Management Plan
The change management plan documents procedures regarding change control, and each organization has its own procedures regarding change control, which are documented here. Following are some of the items that the change management plan can include:
Identifies who has the authority to approve or reject changes—Generally, the change control board (CCB) is the authority to approve or reject requested changes. The change management plan documents who will be part of the change control board and what level of authority each member has. Even if there is no official change control board, there still must be some authority who can approve or reject changes, even if this authority is one person. If no one has been identified initially, the authority may be the project sponsor. The project manager, too, may have a certain authority to approve or reject changes, which are initially documented in the project charter but also are documented here. For example, if the project manager has the authority to approve changes up to the value of $5,000, this is documented in the project charter and also documented in the change management plan.
Identifies who can submit a change request: The entire change control process needs to be properly controlled, and that includes who can submit a change request to the change control board. Although any stakeholder on a project can propose a change, there should be only a limited number of people who can actually submit the change request document to the CCB. Generally, the project managers have this authority, but the change management plan identifies who these people are. They determine whether the change is valid, is relevant for the project, and adds value to the project.
Identifies what constitutes a change: Generally, any changes that impact the baseline must go through the change control process. As the team is planning the project, any work identified is added to the plan. When the scope, schedule, and costs have been baselined, any identified changes must go through the change control process. However, each organization may have its own definition of what constitutes a change, which also is documented here. For example, “Any task that is less than two hours of work will not be considered a change.” If that is the case, it is documented here.
Describes the change control process: Each organization has its own procedures regarding change control, but a basic understanding of PMI’s general process is needed for the PMP exam. This process is discussed next.
Describes documentation and templates that must be used and updated during the change control process: Each organization has its own templates and documents that must be used for requesting changes, analyzing changes, and submitting change requests.
Key Artifact of Integrated Change Control: Configuration Management Plan
Configuration management refers to version control of artifacts, ensuring that team members and stakeholders are accessing the latest version of documents. The configuration management plan documents the configuration management system and procedures.
Distinguish this with the version control system:
Configuration management retrieves the latest version of the document.
Version control allows access to the previous versions of the documents.
Steps Involved in the Change Control Process
Each organization has its own procedures for change control, but the following are the basic steps that you need to know for the PMP exam:
Step 1. A stakeholder identifies the need for a change.
This is documented in the change log.
This request may be initiated verbally, but it must still be documented.
Step 2. Perform an impact analysis.
The team analyzes the change to determine the impact to the budget, schedule, resources, and other constraints.
You also need to determine the impact to other areas of the project, such as other project processes or impacts to other project teams.
You also identify any possible alternative actions.
Step 3. Submit the change request to the change control board.
Step 4. Follow the steps outlined in the change management plan to obtain approval (or rejection) from the appropriate authority (CCB, sponsor, or other authority).
Step 5. Update the change log with the status and any other project documents to reflect the change. Communicate the status to any other interested stakeholders.
Step 6. Implement the change.
Step 7. Verify/test the change (control quality).
Change Control in an Adaptive Environment
For the most part, the day-to-day work of an agile project does not always require a change control process in the same way as a predictive project. Any new user stories are added to the product backlog, which is regularly reprioritized. Only the high-priority user stories are implemented in a sprint. So, in an adaptive environment, change control is built into the agile process.
In addition, the many levels of feedback cycles that are performed frequently on an agile project ensure that potential changes are communicated and understood to ensure an adequate change management process is in place.
However, any major changes to the vision of the agile project or any additional sprints needed will require an approval process. The approval process in agile is beyond the scope of the PMP exam.
Exam Preparation Tasks
As mentioned in the section “How to Use This Book” in the Introduction, you have a couple of choices for exam preparation: the exercises here, Chapter 18, “Final Preparation,” and the exam simulation questions on the Pearson Test Prep practice test software.
Review All Key Topics
Review the most important topics in this chapter, noted with the Key Topic icon in the outer margin of the page. Table 4-6 lists a reference of these key topics and the page numbers on which each is found.
Table 4-6 Key Topics for Chapter 4
Key Topic Element |
Description |
Page Number |
|---|---|---|
Table 4-2 |
Integration Management Processes and Process Groups |
123 |
Section |
Key Artifacts of Developing the Project Charter |
124 |
Section |
Benefits Management Plan |
126 |
Section |
The Project Charter |
127 |
List |
The project management plan is made up of many planning documents |
132 |
Section |
Subsidiary Management Plans |
133 |
Section |
Baselines |
133 |
Section |
Additional Components |
134 |
Exam Tip! |
Components of the project management plan |
135 |
Section |
What Is Business Value? |
137 |
List |
MVP and MBI |
139 |
List |
WPD, WPI, and WPR |
140 |
List |
Two classifications of knowledge |
141 |
Section |
Key Artifact of Integrated Change Control: Change Management Plan |
144 |
Section |
Key Artifact of Integrated Change Control: Configuration Management Plan |
145 |
Section |
Steps Involved in the Change Control Process |
146 |
Define Key Terms
Define the following key terms from this chapter and check your answers in the glossary:
project management plan
project charter
business documents
business case
benefits management plan
subsidiary management plans
baselines
business value
minimum viable product (MVP)
minimum business increment (MBI)
work performance data (WPD)
work performance information (WPI)
work performance report (WPR)
explicit knowledge
tacit knowledge
corrective action
preventive action
defect repair
configuration management
Review Questions
1. Who is responsible for integrating the activities of a project?
The project manager
The project manager and the project team
The project manager and subject matter experts
The sponsor and the project manager
2. Your project has a tight deadline, and planning needs to start immediately; otherwise, there may be risks of delays. The sponsor has not signed the project charter and will not be available for another two weeks. What should you do?
Explain the urgency of the situation to the sponsor but start planning the project. You can have the sponsor sign the project charter when they are available.
Explain the urgency of the situation to the sponsor but do not start work until you have a signed project charter.
Explain the urgency of the situation to the sponsor and escalate to senior management for resolution.
Explain the urgency of the situation to the sponsor and request senior management assign another sponsor.
3. Which of the following are not components of the project management plan? (Choose two.)
Risk management plan
Schedule baseline
Requirements documentation
Resource management plan
Risk register
4. You are an experienced team facilitator recently hired by your company to lead its first agile project. Your team members are asking which artifacts they will need to update as the project progresses. Which of the following is not an artifact used in Agile?
Sprint backlog
Product backlog
Schedule baseline
Burndown chart
5. Which of the following is work performance information?
“We have spent $80,000 so far on this deliverable.”
“We are four weeks into the project and have completed 50 tasks.”
“We are 10 percent complete.”
“We are 10 percent over budget.”
6. You are managing a project using a new approach for your organization. There are three distinct phases that are divided into several short iterations, and each iteration will deliver a valuable product to the organization. What are these products best described as?
Minimum business increment
Deliverables
Minimum viable product
Requirements
7. You are in a meeting with your team. You present some reports, show a PowerPoint presentation, and discuss your own past experiences to offer insight on how to improve certain procedures on the project. Which of the following is true?
You are discussing lessons learned, which is tacit knowledge, but your experience is explicit knowledge.
Your reports and PowerPoint presentation would be classified as explicit knowledge, whereas your experience would be tacit knowledge.
Your reports and PowerPoint presentation would be classified as tacit knowledge, whereas your experience would be lessons learned knowledge.
Your reports and PowerPoint presentation would be classified as tacit knowledge, whereas your experience would be explicit knowledge.
8. You are managing a small construction project, and one of the team leads informs you that there is a problem with the plumbing, but it will be a quick and easy fix. What should you do next?
Tell the team member to go ahead and make the fix.
Perform an impact assessment.
Create the change request.
Notify the change control board.
9. The agile team and product owner are in a meeting discussing a feature, but there is much confusion between team members about the coding. After some discussion, it transpires that one developer was looking at a piece of code from the day before and another from an hour ago. What did the team probably fail to do?
Implement an adequate file management system.
Update the communication management plan.
Communicate with one another.
Implement an adequate configuration management system.
10. Regarding change, the project manager’s attention is best spent doing which of the following?
Informing the sponsor and stakeholders of changes
Tracking and recording changes
Building relationships with the change control board members
Preventing unnecessary changes