PMGT5871 Chap.2 Project Scope, Requirements and the WBS
Project Scope, Requirements and the WBS
Scope defines what the project will and will not deliver. This chapter separates product scope from project scope and functional requirements from technical specifications, lists the techniques for gathering requirements, and builds the scope statement element by element.
It then explains the three sources of scope creep and constructs a work breakdown structure, the hierarchy every later schedule and budget is built on, together with its six rules and the final cross-check against the scope statement. Scope is the foundation of every later plan in the unit, so errors here travel.
A missing WBS branch becomes a missing schedule activity in Week 3 and a missing cost line in Week 4. The Week 2 tutorial reflects that order: groups write prioritised requirements for the first case study, then a scope statement, then the WBS to level 2, posting each element so it can be reused when the group project management plan is compiled.
What this chapter covers
- 01
Product scope compared with project scope
- 02
Requirements compared with specifications
- 03
Requirement gathering techniques
- 04
Elements of the scope statement
- 05
Business, technological and customer-pleasing scope creep
- 06
Work breakdown structure formats and levels
- 07
WBS rules, stop rules and the final cross-check
Worked example · free
Drafting a level-2 WBS for an event
- 1Make the whole expo the single level-1 item.
- 1Split level 2 into planning, venue, exhibitors and closure so management work is included.
- 1Unpack planning and exhibitors into verb-led items such as set budget and invite firms.
- 1Check that no item has two parents and that dates and names are left out.
Key terms
- Product scope
- The features and functions that define the product, service or result being made.
- Project scope
- The work required to deliver the product with its specified features: how to make it.
- Functional requirement
- A statement of the need: who requires something, what, where, when, how often and in what quantity, without naming technology.
- Technical specification
- A description of the technical solution, architecture, infrastructure and components that will meet a requirement.
- Scope statement
- The document that describes project and product scope, objectives, deliverables, inclusions, exclusions, constraints and assumptions.
Project Scope, Requirements and the WBS FAQ
What goes into a scope statement?
The slides list objectives and success criteria, deliverables and acceptance criteria, inclusions, exclusions, constraints and assumptions. Together they document the project boundaries and progressively elaborate the charter and the requirements documentation.
What are the six WBS rules?
Each level contains all the work for the level above, work is never duplicated, no category holds just a single activity, no activity has two parents, categories are organised in a way that makes sense to the team, and chronology and resources are ignored because the schedule and the responsibility matrix handle them.
Where does scope creep come from?
Business creep comes from poor requirements definition or late stakeholder involvement, technological creep from technologists adding features, and customer-pleasing creep from extra features added to please the client. All three lead to budget and schedule overruns and extra workload.
What is the difference between a requirement and a specification?
A functional requirement states the need itself: who requires something, what, where, when, how often and in what quantity, with no mention of technology. A technical specification describes how the need will be met, including the solution, architecture, infrastructure and components. Naming a product or framework signals a specification.
When should you stop breaking down a WBS?
Stop when items can be allocated to one person, or at work-package level if the team has work-package managers. Break down further when team members need more direction, as novices do, or when part of the work is unclear, complicated or especially important.
Which techniques are used to gather requirements?
The Week 2 slides list meetings with the sponsor, client or stakeholders, contract review, interviews, workshops and focus groups, brainstorming, group decision-making techniques, questionnaires and surveys, observation, consultation with subject-matter experts, and market research. Most projects combine several of them.
Exam move
Practise sorting mixed lists into product scope and project scope, and into requirements and specifications, until the test question is automatic: does the item describe the outcome or the work, the need or the technology? Write a scope statement for a small project of your own using all six elements, giving special care to the exclusions.
Then draw its WBS twice, once as a tree and once as an indented list, and audit it against the six rules and the stop rules. Finish with the cross-check: confirm that every deliverable appears, nothing excluded has crept in, and the work required to measure success is included.
As a last check, read your WBS aloud from the top: every branch should sound like a deliverable or phase, and every lowest item like an action someone could start tomorrow.
Working through Project Scope, Requirements and the WBS in PMGT5871? Sia is AskSia’s AI Project Management tutor — ask any PMGT5871 Project Scope, Requirements and the WBS question and get a clear, step-by-step explanation grounded in how PMGT5871 is taught and assessed. Read this chapter free, then take your hardest questions to Sia.
