Scope, requirements and the WBS

0:00 'A portal for students'

A university in Lahore, a fictional one, launched a student portal. The scope said, in full: a portal for students. Then the workshops began, and a hundred and forty features were requested. Timetables, fees, library, alumni networking, society bookings, parking permits. Every one of them was reasonable. Together, they were impossible. Scope is where most projects quietly go wrong, not with a bang but with a slow accumulation of assumptions nobody wrote down. In this lecture you'll learn how to write a scope statement that includes explicit exclusions, how to elicit requirements well, how to prioritise them with MoSCoW, how to move from scope to a work breakdown structure, and how traceability and acceptance protect you at the end. By the end, you'll be able to turn a vague request into a scope everyone can sign.

0:59 Why it matters

Why does this matter? Because ambiguity in scope doesn't disappear. It turns into change requests, disputes and delays later, when they're most expensive. There's a principle I always teach: anything you don't explicitly exclude, someone will assume is included. If the portal scope doesn't say 'no alumni features', an alumni office will reasonably expect them. And at the end, clear acceptance criteria are what let you say 'done' without an argument. A good scope is a gift to everyone on the project, including the client, because it makes expectations visible early, when changing them costs a conversation rather than a contract variation.

1:43 The concept: scope statement and exclusions

Here's the key idea: a scope statement is a fence, and a fence needs both sides drawn. It sets out the objectives, the deliverables and the acceptance criteria for each deliverable. It lists assumptions, such as 'the registrar will provide course data in the agreed format by week four', and constraints, such as budget, dates and technology standards. And it lists exclusions explicitly: what's not included, even though someone might reasonably expect it. Think of it like booking a hotel. The confirmation says breakfast included, parking not included, late checkout on request. Nobody's surprised at the desk. For a project, five to ten clear exclusions often prevent more conflict than fifty pages of requirements. And the scope statement is signed off by the sponsor and key stakeholders, so it becomes a shared commitment rather than the project manager's opinion.

2:43 Eliciting and prioritising requirements

Requirements come from several techniques, and the best projects use more than one. Workshops bring people together to agree. Interviews go deep with individuals. Observation shows what people actually do, which often differs from what they say. And prototypes let users react to something real, which is by far the fastest way to surface what they really need. Write each requirement so it can be tested. 'Fast search' isn't testable. 'Search results appear within two seconds for ninety-five per cent of queries' is. Then prioritise with MoSCoW. Must have: the release fails without it. Should have: important, but there's a workaround. Could have: nice if there's time. And won't have this time, which is the most powerful category, because it records agreed exclusions for this release without saying never.

3:39 Worked example one: rewriting three requirements

Let's rewrite three requirements I see all the time. First: 'the portal must be user-friendly'. Testable version: 'new students can complete course registration in under ten minutes without help, in usability testing with ten students'. Second: 'the portal must be secure'. Testable version: 'single sign-on with multi-factor authentication; role-based access for students, staff and administrators; an audit log retained for twelve months'. The exact controls would come from the university's security policy. Third: 'the portal must have reports'. Testable version: 'three named reports, enrolment by programme, fee status and attendance, owned by the registrar, refreshed daily'. Each rewrite takes a minute. Each one prevents an argument at acceptance, because everyone can see whether the requirement was met.

4:30 Worked example two: the Lahore student portal

Now back to the portal from the lesson. A hundred and forty requested features. The team ran MoSCoW prioritisation with the product owner and the academic registrar. The result: thirty-five Musts, forty Shoulds, forty-five Coulds and twenty Won'ts. Release one covered all the Musts plus selected Shoulds, sized to fit the time and budget. The Could items became candidates for later releases, visible in the backlog, so nobody felt ignored. And the explicit Won't list, including alumni networking, was shared and signed. Months later, when the alumni office asked why their features weren't in the portal, the answer was a document they'd agreed to, not an argument. Notice the balance: only about a quarter of the requests were Musts. That's typical, and it's exactly why prioritisation matters.

5:25 Watch me do it: a traceability matrix

Let me show you the traceability matrix I keep, and it can live in a spreadsheet, in Jira or in a requirements tool. One row per requirement: an ID, the requirement text, the MoSCoW priority, the source, meaning who asked for it, the WBS element or backlog epic that delivers it, the test case that verifies it, and the status. Now the value comes from two filters. First: show me every Must with no test case. Here there are two, and those are acceptance arguments waiting to happen, so I get tests written now. Second: show me every test case that doesn't trace to a requirement. Here there's one, which usually means someone's building something nobody asked for, or a requirement was never written down. Both gaps are cheap to fix today and expensive to discover at go-live.

6:25 From scope to WBS, and acceptance

Next, turn the scope into a work breakdown structure: decompose each deliverable into work packages that one owner can plan and measure, apply the one hundred per cent rule so nothing is missing or double-counted, and keep a WBS dictionary describing each package. In agile projects, the equivalent is a product backlog organised by epics and features, with the same discipline about what's in and out. Then validate scope continuously with the customer, through reviews and demos, rather than waiting for a big reveal. And finally, formal acceptance: each deliverable is checked against its agreed acceptance criteria and signed off. Handle small 'can you just' requests the same way every time: log them, estimate them, and decide them as a batch, so scope creep becomes visible instead of silent.

7:21 Common mistakes

The common mistakes. A vague scope with no exclusions. Requirements that can't be tested, full of words like fast, easy, flexible and user-friendly. Prioritisation where everything is a Must, which means nothing is really prioritised. A good rule of thumb: if more than about half your requirements are Musts, challenge them. No traceability, so nobody can tell whether all requirements were built and tested. And no formal acceptance, so 'done' becomes a matter of opinion. Here's a self-check: pick any deliverable and ask, if the client disputed it tomorrow, could I show the agreed requirement, the test that verified it and the sign-off? If not, that's your next job.

8:08 Recap and try this now

Let's recap. A good scope statement sets objectives, deliverables and acceptance criteria, and draws both sides of the fence with explicit exclusions, assumptions and constraints. Elicit requirements with more than one technique, write them so they can be tested, and prioritise them with MoSCoW, protecting the Won't list. Decompose scope into a WBS or a well-structured backlog, keep a traceability matrix, validate with customers as you go, and formally accept against the criteria. Your try-this-now: write a scope statement for a project you know, with at least five explicit exclusions, and prioritise ten requirements using MoSCoW. Then check: are fewer than half of them Musts?