4.2 Comprehensive Project Planning & Baselines

Once a project is officially authorized by the Project Charter in the initiation phase, it immediately transitions into the Planning phase. The planning phase is often the most time-consuming and effort-intensive part of the entire project life cycle, and for very good reason. A common project management adage states, 'Failing to plan is planning to fail.' In this critical phase, the project manager and the team break down the high-level goals established in the charter into actionable, detailed, and measurable plans. The ultimate, overarching output of this phase is the Project Management Plan, a comprehensive document that guides the execution, monitoring, and controlling, and closure of the project.

The Project Management Plan

It is crucial to understand that the Project Management Plan is not a single, monolithic document written in one sitting. Rather, it is a master plan composed of numerous subsidiary plans and baselines that are integrated together. These subsidiary plans dictate exactly how specific knowledge areas will be managed throughout the project's duration. Examples include the Scope Management Plan, Schedule Management Plan, Cost Management Plan, Quality Management Plan, Resource Management Plan, Communications Management Plan, Risk Management Plan, Procurement Management Plan, and Stakeholder Engagement Plan.

The Project Management Plan is a living document, meaning it can and will be updated as the project progresses and more information becomes available. However, changes to its core components—specifically the project baselines—require strict adherence to formal change control procedures.

Understanding Project Baselines

A baseline is defined as the approved version of a work product that can be changed only through formal change control procedures and is used as a basis for comparison to actual results. In traditional, predictive (Waterfall) project management environments, there are three primary baselines that collectively make up the Performance Measurement Baseline (PMB). The CompTIA Project+ exam expects you to intimately understand these three baselines and how they interact.

1. The Scope Baseline

The Scope Baseline is the approved version of a scope statement, work breakdown structure (WBS), and its associated WBS dictionary.

• Project Scope Statement: A highly detailed description of the project scope, major deliverables, assumptions, and constraints. Importantly, it clearly defines what is strictly out of scope. Defining exclusions is vital to prevent 'scope creep'—the uncontrolled, insidious expansion to product or project scope without corresponding adjustments to time, cost, and resources.
• Work Breakdown Structure (WBS): A hierarchical decomposition of the total scope of work to be carried out by the project team. It breaks down massive, complex deliverables into smaller, more manageable components called work packages. A critical rule for the exam: The WBS is deliverable-oriented, not task-oriented. It shows what needs to be built, not how to build it.
• WBS Dictionary: A companion document to the WBS that provides detailed deliverable, activity, and scheduling information about each component in the WBS. It acts as a reference guide, often including acceptance criteria, responsible individuals, cost estimates, and technical references for each work package.

2. The Schedule Baseline

The Schedule Baseline is the approved version of a schedule model that can be changed only through formal change control procedures. Developing the schedule is a complex process that involves defining activities, sequencing them based on dependencies, estimating durations, and analyzing the critical path.

• Milestones: Significant points or events in a project. A milestone has zero duration because it represents a moment in time (e.g., 'Phase 1 Complete' or 'Software Deployed'). Milestones are critical for high-level executive reporting.
• Network Diagrams: Visual representations of the project's schedule activities and their logical relationships and dependencies. They illustrate predecessor and successor activities.
• Critical Path Method (CPM): The sequence of activities that represents the longest path through a project, which determines the shortest possible project duration. Any delay on the critical path delays the entire project completion date. Activities on the critical path have zero float (or slack). Understanding the critical path is essential for knowing where to focus monitoring efforts.

3. The Cost Baseline

The Cost Baseline is the approved version of the time-phased project budget, excluding any management reserves, which can be changed only through formal change control procedures. It is used as a basis for comparison to actual financial results as the project progresses.

• Budgeting: The process of aggregating the estimated costs of individual activities or work packages to establish an authorized cost baseline.
• Contingency Reserves vs. Management Reserves:
  • Contingency Reserves: Funds allocated specifically for identified risks (often referred to as 'known unknowns'). The project manager generally has the authority to use these funds when a recognized risk occurs. They are included in the Cost Baseline.
  • Management Reserves: Funds allocated for unforeseen risks ('unknown unknowns'). These are withheld by senior management, and the project manager must formally request approval to use them if an unexpected disaster strikes. They are NOT part of the Cost Baseline, but they are included in the total project budget.

Change Control and Baselines

Once the Scope, Schedule, and Cost baselines are established and approved by the sponsor and key stakeholders, they are officially 'locked.' If a stakeholder approaches the project manager requesting to add a new feature (which affects scope), the PM cannot simply agree and add the work. They must run the request through the Integrated Change Control process.

This formal process involves analyzing how the new feature impacts the cost and schedule baselines. Does it require more money? Will it push back the delivery date? If the change is formally approved by the Change Control Board (CCB), the baselines are officially updated to reflect the new reality.

Exam Trap: A highly tested concept on the Project+ exam is the handling of baseline changes during project execution. If a project is running behind schedule or over budget due to poor performance by the team, you do NOT change the baseline to make the metrics look better. Baselines are only updated when a formal change request (like a scope addition or reduction) is approved. Poor performance requires corrective action and coaching, not a baseline adjustment to hide the failure.

In conclusion, robust planning and the establishment of firm, approved baselines are non-negotiable for traditional project management. They provide the objective measuring stick against which all project success is evaluated. Without baselines, a project manager has no objective way to know if the project is ahead of schedule, under budget, or delivering the promised value to the organization.

Complete Planning-Phase Checklist

The PK0-005 planning objective expects operational preparation as well as baselines:

• Assess the resource pool, identify preliminary procurement needs, assign resources, and train team members where skill gaps exist.
• Develop the communication plan, including meeting cadence and the methods appropriate to distributed, technical, executive, and external audiences.
• Define units of work as a WBS for predictive delivery or a backlog for adaptive delivery, then build the schedule and establish cadence.
• Determine budget considerations, create the quality-assurance plan, and perform the initial risk assessment.
• Build a transition or release plan that addresses operational training, go-live, operational handoff, and internal and external audiences.
• Integrate the work into the project management plan with baselines, milestones, and a minimally viable product (MVP) when incremental validation is appropriate.

A plan is useful only when its owners, dates, acceptance criteria, dependencies, and update rules are clear. Planning outputs should trace back to the charter and forward to execution, reporting, testing, transition, and closure.