Project Planning Fundamentals
What planning is for
A project plan is a decision tool, not a document to file. It converts an agreed objective into a sequence of commitments: what will be delivered, by when, by whom, with what resources, and how deviation will be detected. Candidates must distinguish the project charter (authorises the project, names the sponsor and manager, states high-level scope) from the project plan (the detailed, evolving how). Also know the triple constraint of scope, time and cost balanced against quality, and that a change to one normally forces movement in another.
Core concepts
Understand stakeholders and their influence/interest, the sponsor as the escalation point and funding owner, deliverables versus milestones (a milestone has zero duration and no work), and assumptions and constraints - assumptions are believed true but unproven, constraints are fixed limits. Know the plan's progressive elaboration: rolling-wave planning refines near-term work in detail and leaves distant work coarse.
Traps in questions
- Calling a milestone a task, or giving it duration.
- Treating the charter as revisable detail; it is the authority baseline.
- Confusing a constraint ("budget capped at 50k") with a risk.
- Assuming a plan is finished at kickoff; it is re-baselined only by formal change control.
Rule of thumb
If a statement cannot be tested for true/false or measured, it belongs in an assumption or a risk, not in the plan's commitments. Plan to the level at which you can control; refine the rest later.
Worked example: A sponsor fixes the launch date (constraint), the team assumes a vendor API is ready in week 3 (assumption), and the risk register records that the API may slip. Only the date is a constraint; the API belief is an assumption with an associated risk.