FIT5057 · Project Management
Scope Management
You bound the work before you schedule or cost it. This chapter covers scope planning and management (and the discipline that stops scope creep), the requirements traceability matrix (RTM) that links each requirement to the deliverable that satisfies it, and the project scope statement — the detailed boundary document of in-scope and out-of-scope items the WBS is built from. The centrepiece is the work breakdown structure (WBS): a deliverable-oriented decomposition that must obey the 100% rule (the children fully define the parent — no more, no less) and is written in nouns, not verbs. It closes with an intro to quality planning (the three dimensions; plan/assure/control) and the team charter and project ethics. The quiz tests the distinctions — scope statement vs charter vs WBS, requirement vs deliverable, assurance vs control; the project assignments make you produce each artefact.
What this chapter covers
- 012.1 Scope planning & management; scope creep vs an approved change
- 022.2 Requirements & the traceability matrix (RTM)
- 032.3 The project scope statement (in-scope / out-of-scope)
- 042.4 Building a WBS — decompose, code, check the 100% rule
- 052.5 Quality planning — the three dimensions; plan / assure / control
- 062.6 The team charter & project ethics
Worked example: is this scope creep or an approved change?
- +1Dark-mode theme: added informally, with no assessment of its effect on time, cost or quality, and no approval — this is scope creep.
- +1Reporting dashboard: requested formally, assessed for impact, and approved with adjusted budget through change control — this is an approved change, not creep.
- +1Why it matters: creep silently expands the work and breaks the iron triangle (time/cost/quality absorb the hit unmanaged); a controlled change keeps the triangle balanced because a corner is explicitly adjusted.
- +1The discipline: every change — however small — goes through change control so its impact is visible and authorised before it is built.
Key terms
- Scope creep
- The uncontrolled expansion of project scope — features or work added without a corresponding adjustment to time, cost or quality and without going through change control. Distinct from an approved change, which is assessed and authorised. Creep is the silent killer of the iron triangle.
- Requirements traceability matrix (RTM)
- A table that links each requirement to its source, its priority, the deliverable that satisfies it and the test that verifies it. It proves nothing was dropped and nothing extra was built — the audit trail from "what stakeholders asked for" to "what we delivered".
- Project scope statement
- The detailed boundary document that lists what is in scope and out of scope, the deliverables and the acceptance criteria. It is more detailed than the charter's high-level scope, and it is the document the WBS is built from.
- Work breakdown structure (WBS)
- A deliverable-oriented hierarchical decomposition of the total project scope into work packages. It is written in nouns (deliverables), not verbs (activities), and must satisfy the 100% rule: the children at each level sum to exactly the parent — no more, no less.
- 100% rule
- The governing rule of a WBS: the decomposition must capture 100% of the work defined by the project scope — the sum of the child work packages equals the parent, with nothing missing and nothing extra. It is the main thing a WBS critique checks for.
Scope Management FAQ
What is the difference between a WBS, a schedule and an activity?
A WBS decomposes deliverables (nouns — "User authentication module"); it is not a schedule and has no dates or sequence. Activities (verbs — "Write the login API") are derived from the WBS work packages and are what you then sequence and schedule (Chapter 3). The quiz loves to test this: a WBS shows what, the schedule shows when, activities are the verbs in between.
How is the scope statement different from the charter and the WBS?
The charter authorises the project and gives high-level scope; the scope statement bounds the work in detail (in/out of scope, deliverables, acceptance criteria); the WBS decomposes that detailed scope into work packages. So the chain is charter (authorise, broad) → scope statement (bound, detailed) → WBS (decompose).
What is the difference between a requirement and a deliverable?
A requirement is a stated need or condition ("the system must let students reset their own password"); a deliverable is the tangible output that satisfies one or more requirements ("the password-reset feature"). The RTM links them. Confusing the two is a common quiz trap.
What's the difference between quality assurance and quality control?
Assurance is about the process — are we following the right procedures to build quality in? Control is about the product — inspecting and testing the actual deliverable to catch defects. Assurance is proactive and process-focused; control is reactive and product-focused. "Build quality in, don't inspect it in."
Exam move
Make the WBS automatic: practise decomposing a small project into a deliverable-oriented tree, written in nouns, and check it against the 100% rule — this is both a guaranteed quiz target and an A1 artefact. Keep the document chain crisp for the quiz: charter (authorise) → scope statement (bound, in/out) → WBS (decompose), and the three pairwise distinctions the quiz loves — scope statement vs charter vs WBS, requirement vs deliverable, assurance vs control. For the assignment, the RTM is your proof you delivered exactly what was asked, so build it as you go rather than retrofitting it.
