Scope definition, deliverables and stakeholder analysis
Defining scope and deliverables
Scope definition turns the project objective into a clear boundary: what is included, what is excluded, and what acceptance looks like. A scope statement lists objectives, major deliverables, assumptions, constraints and exclusions. Deliverables are tangible outputs or outcomes; activities are the work needed to produce them. Break deliverables into a work breakdown structure (WBS) using the 100% rule: the WBS captures all work and only the work required. Work packages should be small enough to estimate and control-commonly 8–80 hours, though the rule is a guide, not a law. Acceptance criteria must be measurable.
Stakeholder analysis identifies everyone who can affect or is affected by the project, then assesses influence, interest, expectations and impact. A power–interest grid helps choose engagement: manage closely, keep satisfied, keep informed, or monitor. Record engagement actions, not just names.
Traps
Examiners often test deliverable versus activity: “train staff” may be an activity, while “trained staff” is a deliverable. Scope creep is uncontrolled expansion; gold plating is extra work added without approval-both are bad, but for different reasons. A WBS is not an org chart or a schedule. Listing stakeholders is not analysis. “Out of scope” statements are as important as inclusions. Vague acceptance criteria such as “user-friendly” cannot be verified.
Worked example
For a website project, a WBS branch might be Content, Design, Build, Test, Launch. “Build” decomposes into work packages such as “implement login” and “configure payment gateway,” each with acceptance criteria. If a stakeholder asks for a blog after baselining, the project manager checks the scope statement and WBS; if absent, the request goes through change control. Rule of thumb: if it is not in the WBS or acceptance criteria, it is not in scope until approved.