2.2.1. Planning Fundamentals and Baselines
💡 First Principle: Every planning document exists to answer one specific question about the project — cost documents answer "how much," schedule documents answer "when," quality documents answer "how good," and risk documents answer "what could change the other three." Knowing the purpose of each is more testable than memorizing its contents.
| Planning Element | Purpose | Answers |
|---|---|---|
| Cost management | Establishes the budget and how spending will be tracked | "How much will this cost, and how will we know if we're overspending?" |
| Schedule management | Establishes the timeline and sequencing of work | "When will things happen, and in what order?" |
| Quality management | Establishes the standards the deliverable must meet | "How good does 'done' need to be?" |
| Risk management | Establishes how uncertainty will be identified and handled | "What could change our cost, schedule, or quality — and how do we respond?" |
Project management plan vs. product management plan. These get confused constantly. The project management plan describes how the project itself will be run — its baselines, its processes, how changes get approved. A product-related plan (or the product roadmap, covered in Phase 3) describes the product's own features and requirements. One is about managing the work; the other is about defining what the work produces.
⚠️ Exam Trap: If an answer choice describes "the document that says how change requests get approved," that's the project management plan. If it describes "the document that lists what features the product will have," that's product-related documentation — not the project management plan, even though both get called "the plan" informally on real teams.
Milestones vs. task duration. A milestone marks a significant point in time — it has zero duration by definition (e.g., "Phase 1 complete," "Contract signed"). Task duration measures how long a specific piece of work takes to execute. A common exam trap treats a milestone like it has a length; watch for scenarios that ask you to calculate something "at" a milestone versus something "over the course of" a task.
⚠️ Exam Trap: "The milestone lasted three weeks" is a contradiction — milestones are events, not spans. If a scenario describes something with a start and an end that takes time to complete, it's describing a task or activity, not a milestone.
Determining resources. Planning also means identifying the number and type of resources a project needs — people with specific skills, equipment, materials, facilities. The exam tests recognizing resource type mismatches: assigning a generalist where a scenario calls for a specialist, or under-planning for equipment that a deliverable clearly requires.
Why resource-type planning is about more than headcount. A team can be fully staffed in terms of raw numbers and still be badly under-resourced if the wrong skills are sitting in the wrong seats — a specific two-week task requiring a database-migration specialist doesn't get any easier because a generalist developer happens to be available. Documenting resource type, not just resource count, is what catches this kind of mismatch before it becomes a schedule problem.
When a baseline needs to change mid-project. A cost baseline set using current material prices doesn't stay accurate forever — a sudden price shift (a steel shortage, a currency swing) is exactly the kind of event that should trigger a formal reassessment through change control, not a quiet, undocumented adjustment or a decision to simply ignore the new reality. The baseline exists to be updated through a defined process when genuinely new information arrives, not treated as permanently fixed the moment it's first set.
How the four planning elements connect. Cost, schedule, quality, and risk aren't four unrelated checklists — risk planning specifically exists to protect the other three baselines from uncertainty, while cost, schedule, and quality each address a distinct dimension of the deliverable itself. A scenario testing whether you understand this connection is really testing whether you see risk management as protective infrastructure for the other three, not a separate, standalone activity.
