Project Planning and Scope Management
What the exam tests
Scope planning: requirements, the scope statement, WBS quality, and how the scope baseline is established and controlled.
Planning is iterative. The scope management plan defines how requirements are collected, how scope is defined and verified, and how changes are controlled. The project scope statement records deliverables, acceptance criteria, exclusions, constraints, and assumptions. The WBS decomposes deliverables into work packages; the 100% rule requires child elements to capture all of the parent's scope and no more. The WBS dictionary describes each package's work, acceptance criteria, and responsible party. Scope baseline = scope statement + WBS + WBS dictionary.
Verification versus control
- Validate Scope: formal acceptance of completed deliverables by the customer or sponsor.
- Control Scope: monitoring status and managing changes to the baseline.
- Quality control asks whether the deliverable is correct; Validate Scope asks whether the customer accepts it.
Worked example
Mid-execution, a client requests an extra reporting dashboard "since the team is already in the system." Approach: log a change request, analyse impact on scope, schedule, cost, quality, risk, and resources, route it to the change control board, and update baselines only if approved. Doing the work first creates scope creep and invalidates the performance baseline. If rejected, record the decision and communicate it.
Traps
- Decomposing the WBS by org chart rather than by deliverable.
- Treating a work package as a single activity; work packages are decomposed into activities for scheduling.
- Confusing assumptions (believed true without proof) with constraints (fixed limits).
- Gold plating: adding unrequested features is a scope and quality failure, even if the client likes it.