This chapter is from the book
This chapter is from the book
This chapter is from the book
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 |