3.1 The Project Management Plan

CAPM Certified Associate in Project Management Exam

Track your progress as you read

Finished sections get a check mark.

1 Chapter 1: Introduction & CAPM Exam Overview

1.1 About the CAPM Exam 1.2 PMBOK 7th Edition Overview 1.3 Exam Content Outline (ECO) 1.4 CAPM vs. PMP: Understanding the Differences

2 Chapter 2: Project Life Cycles and Processes (Domain 1, Tasks 1-2)

2.1 Projects, Programs, and Portfolios 2.2 Project Life Cycle Phases 2.3 The Five Process Groups 2.4 The Ten Knowledge Areas

3 Chapter 3: Project Management Planning (Domain 1, Task 2)

3.1 The Project Management Plan 3.2 Scope Management and the WBS 3.3 Schedule Management 3.4 Cost Management and Earned Value 3.5 Quality Management

4 Chapter 4: Project Roles, Responsibilities, and Ethics (Domain 1, Tasks 3-4)

4.1 Project Roles and Responsibilities 4.2 Leadership and Emotional Intelligence 4.3 Risk Management Fundamentals 4.4 PMI Code of Ethics and Professional Conduct 4.5 Problem-Solving Tools and Techniques

5 Chapter 5: Resource, Communication, and Stakeholder Management (Domain 1, Tasks 2-3)

5.1 Resource Management 5.2 Communications Management 5.3 Stakeholder Management 5.4 Procurement Management 5.5 Issues, Risks, Assumptions, and Constraints

6 Chapter 6: Predictive, Plan-Based Methodologies (Domain 2)

6.1 When to Use a Predictive Approach 6.2 WBS, Work Packages, and Activity Definition 6.3 Predictive Project Controls and Artifacts 6.4 Critical Path and Schedule Calculations

7 Chapter 7: Agile Frameworks and Methodologies (Domain 3, Tasks 1-3)

7.1 When to Use an Adaptive (Agile) Approach 7.2 The Scrum Framework 7.3 Kanban, XP, and SAFe 7.4 Agile Planning, Estimation, and Metrics 7.5 Agile Project Controls and Artifacts

8 Chapter 8: Business Analysis Roles and Stakeholder Communication (Domain 4, Tasks 1-2)

8.1 Business Analysis Roles and Responsibilities 8.2 Stakeholder Communication in Business Analysis 8.3 Business Case and Needs Assessment

9 Chapter 9: Requirements Gathering and Product Roadmaps (Domain 4, Tasks 3-4)

9.1 Requirements Gathering Approaches 9.2 Requirements Traceability Matrix 9.3 Product Roadmaps

10 Chapter 10: BA Methodologies and Requirements Validation (Domain 4, Tasks 5-6)

10.1 Business Analysis in Predictive and Agile Approaches 10.2 Acceptance Criteria and Requirements Validation 10.3 Business Analysis Tools and Techniques Summary

3.1 The Project Management Plan

Key Takeaways Explain This Topic AI

The project management plan is the master document that integrates and consolidates all subsidiary management plans plus the scope, schedule, and cost baselines

Subsidiary plans cover scope, requirements, schedule, cost, quality, resource, communications, risk, procurement, configuration, change, and stakeholder engagement

The three baselines (scope, schedule, cost) together form the Performance Measurement Baseline used in Earned Value Management

Project documents such as the risk register, issue log, and stakeholder register are NOT part of the project management plan

Once baselined, the plan changes only through Perform Integrated Change Control via an approved change request
Last updated: October 2026

The Master Integration Document

The project management plan is the single most important deliverable a project manager produces in predictive, plan-based work. It is the integrated, approved document that describes how the project will be executed, monitored, controlled, and closed. On the CAPM exam (150 questions, 3 hours, with the PMBOK Guide Seventh Edition among its listed references), planning content sits heavily inside the Fundamentals and Predictive domains, so expect several questions on what the plan contains and how it is changed.

A critical exam trap: the plan describes how the work will be managed, not the work itself. "Build the bridge" is the deliverable; "we estimate cost using bottom-up estimating and control it through a change control board" is the plan.

Subsidiary Management Plans

The project management plan integrates these subsidiary plans, each produced by its own planning process:

Subsidiary plan Defines how you will...

Scope Management Plan Define, validate, and control scope
Requirements Management Plan Analyze, document, and trace requirements
Schedule Management Plan Develop, monitor, and control the schedule
Cost Management Plan Estimate, budget, and control cost
Quality Management Plan Apply quality policies and metrics
Resource Management Plan Estimate, acquire, manage, and release resources
Communications Management Plan Plan and monitor information flow
Risk Management Plan Structure and perform risk activities
Procurement Management Plan Acquire goods and services externally
Stakeholder Engagement Plan Engage stakeholders by interest and influence

Three additional components frequently tested: the change management plan (how change requests are processed), the configuration management plan (how versions and product configuration are controlled), and the development approach (predictive, iterative, incremental, agile, or hybrid).

The Three Baselines

Baselines are the approved versions used as a comparison standard. Actuals are measured against them.

Baseline Components Measures
Scope Baseline Project scope statement + WBS + WBS dictionary Scope delivery
Schedule Baseline Approved version of the schedule model Schedule performance
Cost Baseline Time-phased budget, excluding management reserves Cost performance

Together the three baselines equal the Performance Measurement Baseline (PMB) used in Earned Value Management. Note the cost baseline includes contingency reserves but excludes management reserves.

How the Plan Is Developed and Changed

The Develop Project Management Plan process (Planning) consolidates outputs of the other planning processes. Key inputs are the project charter, outputs from subsidiary planning, Enterprise Environmental Factors (EEFs) such as market conditions and organizational culture, and Organizational Process Assets (OPAs) such as templates and lessons learned. The plan is progressively elaborated : a high-level draft first, then increasing detail as requirements firm up, then formal baselining.

After baselining, the only legitimate route to change is Perform Integrated Change Control : a change request is logged, evaluated for impact, approved or rejected (often by a change control board), and the baselines are updated. The PM never quietly edits a baseline.

Plan vs. Documents vs. Performance Data

Term What it is
Project management plan How the project is managed (plans + baselines)

Project documents Supporting records NOT in the plan: risk register, issue log, stakeholder register, assumption log, RACI

Work performance data Raw measurements during execution (e.g., 4 of 10 tasks done)
Work performance information Data analyzed in context (e.g., SPI = 0.9, behind schedule)
Work performance reports Compiled information packaged for decisions (status reports, dashboards)

A common exam scenario: a stakeholder asks for a change. The correct first action is almost always to evaluate it through integrated change control, not to immediately update the schedule or refuse it outright.

Why Integration Matters

The reason the plan is called an integration document is that the subsidiary plans are not independent — changing one almost always ripples into the others. If a stakeholder adds a deliverable to scope, the schedule baseline must absorb new activities, the cost baseline must absorb new estimates, the resource plan may need new staff, and the risk register may gain new threats. The project manager's job in planning is to keep these views consistent. This is exactly why an unmanaged scope change is dangerous: it silently invalidates the schedule and cost baselines, so performance reporting against those baselines becomes meaningless.

A second reason integration is tested heavily is that the CAPM exam frequently presents a situation and asks which document to consult or update. Memorize the mapping: questions about how decisions are made point to a subsidiary management plan; questions about current status of identified risks or open issues point to a project document; questions about the approved measurement standard point to a baseline.

Tailoring and the Development Approach

Not every project uses every subsidiary plan, and the PMBOK Guide Seventh Edition emphasizes tailoring — selecting the right processes, methods, and rigor for the specific project. A small internal project may fold several plans into a one-page document, while a regulated construction project may maintain every plan formally. The development approach component records whether the work is predictive (this chapter's focus, with full upfront planning and baselines), iterative, incremental, agile, or hybrid.

On a predictive project the baselines are set early and defended through change control; on an adaptive project the plan is deliberately lighter and re-planned each iteration. The exam expects you to recognize that the rigor of planning should match the project's size, complexity, and uncertainty, never a one-size-fits-all template.

Quick Self-Check Checklist

Is it a plan (how) or a document (current record)? Plans are integrated; documents are not.

Is it inside or outside the cost baseline? Contingency is inside; management reserve is outside.

After baselining, is there an approved change request? No request, no baseline change.

Does the development approach match the work? Predictive needs firm baselines; adaptive needs lighter re-planning.