3.1 The Project Management Plan
Key Takeaways
- 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
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, aligned to the PMBOK Guide Seventh Edition), 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.
Which three baselines combine to form the Performance Measurement Baseline?
A stakeholder formally requests a change after the plan has been baselined. What should the project manager do FIRST?
The risk register is best classified as a: