--- title: "Scope, requirements and the WBS | Optimize All Academy" description: "Scope is where most projects go wrong Poorly defined scope drives rework, disputes and overruns. Planning starts by agreeing what will be delivered and…" url: https://optimizeall.com/learn/project-management-leadership-with-ai/scope-and-requirements updated: 2026-10-05 --- Project Management Leadership with AI · Planning scope, schedule, budget and resources · lesson 5 of 21 · 14 min # Scope, requirements and the WBS ## Scope is where most projects go wrong Poorly defined scope drives rework, disputes and overruns. Planning starts by agreeing **what will be delivered and what will not**. ## Project scope statement ``` Project objective: ______ In scope: ______ Out of scope (explicit exclusions): ______ Deliverables: ______ (each with acceptance criteria) Constraints: budget cap, fixed dates, regulations, technology standards Assumptions: ______ (to be validated) Key dependencies: ______ ``` Explicit exclusions are as valuable as inclusions: they prevent assumptions from turning into expectations. ## Eliciting requirements Use several techniques, because each reveals different needs: - **Interviews and workshops** with users and stakeholders. - **Observation** of current processes (people often describe what should happen, not what actually happens). - **Document and data analysis** (reports, policies, logs). - **Prototyping** to make needs concrete. - **User stories** in agile contexts: "As a [role], I want [capability] so that [benefit]", with acceptance criteria. Write requirements that are clear, testable and prioritised. Separate **functional** requirements (what the solution does) from **non-functional** ones (performance, security, accessibility, availability, compliance). ## Prioritisation with MoSCoW | Category | Meaning | Guideline | |---|---|---| | Must have | Without it, the solution fails or is unlawful/unsafe | Keep a minority of total effort, so there is room to flex | | Should have | Important but workarounds exist | | | Could have | Desirable, small impact if left out | First to drop under pressure | | Won't have (this time) | Agreed out of current scope | Recorded to manage expectations | A useful discipline (used in DSDM/Agile Business Consortium guidance) is to keep "Must haves" to a limited proportion of effort so that the team can protect dates and budgets by flexing lower priorities. ## From scope to WBS The **work breakdown structure** decomposes scope into deliverables and work packages. The 100% rule applies: children sum to 100% of the parent, with nothing missing or duplicated. Include project management, testing, training, data migration, documentation and handover; they are frequently forgotten. ``` 1 Customer Portal Project 1.1 Project management 1.2 Requirements & design 1.3 Portal build (sprints) 1.4 Integrations (CRM, payments) 1.5 Data migration 1.6 Testing (system, UAT, security) 1.7 Training & change management 1.8 Deployment & hypercare ``` In agile projects, the equivalent is a **product backlog** organised by epics and features; a lightweight WBS at the epic level still helps with budgeting and dependencies. ## Traceability A **requirements traceability matrix** links each requirement to its source, design element, test case and status. It ensures nothing is lost and helps assess the impact of changes. ``` Req ID | Requirement | Source | Priority | Design ref | Test case | Status R-012 | Customer can reset password | Workshop 2 | Must | UX-07 | TC-044 | Passed R-031 | Dashboard loads < 3s at peak | Ops interview | Must | ARCH-03 | PT-005 | In test ``` ## Worked example *Illustrative.* A fictional university in Lahore launched a student portal. The initial scope said "a portal for students". Workshops revealed 140 requested features. The team used MoSCoW with the product owner and academic registrar: 35 Must, 40 Should, 45 Could, 20 Won't. Release 1 covered the Musts plus selected Shoulds; Could items became candidates for later releases. The explicit Won't list (e.g., alumni networking) prevented later disputes. ## Common mistakes - No explicit exclusions. - Requirements that cannot be tested ("user-friendly"). - Everything marked "Must". - Forgetting non-functional requirements until testing. - No traceability, so changes have unknown impacts. ## Quick self-check Can you show a stakeholder, for any requirement, where it came from, how it will be tested and what its priority is? If not, build a simple traceability matrix before build starts. ## Scope validation and acceptance Agreeing scope at the start is not enough; you also need a way to confirm deliverables meet it. Define who accepts each deliverable, against which criteria, and how disputes are resolved. In predictive projects this is often a formal sign-off at the end of each stage; in agile projects, the product owner accepts items against acceptance criteria and the Definition of Done during each sprint. Either way, record acceptance so there is no later argument about what was agreed. ## Handling "small" requests Many scope problems begin with small, reasonable-sounding requests made informally. Make it easy to log them, estimate them quickly and decide in batches. Visible trade-offs ("adding this means delaying that") help stakeholders prioritise rather than simply ask for more. ## Hands-on: a traceability matrix with gap checks (Excel) ```text Columns: A Req ID | B Requirement (testable) | C MoSCoW | D Source | E WBS/epic | F Test ID | G Status | H Accepted by I Gap flag =IFS(AND(C2="Must",F2=""),"MUST WITHOUT TEST",E2="","NOT IN WBS/BACKLOG",TRUE,"") Share of Musts =COUNTIF(C:C,"Must")/(COUNTA(A:A)-1) (header excluded; challenge if > ~50%) Tests sheet: A Test ID | B Linked Req ID Orphan test flag =IF(COUNTIF(Reqs!A:A,B2)=0,"TEST WITHOUT REQUIREMENT","") ``` In Jira, the same checks can be run with JQL filters, for example issues of type Story with priority "Must" and no linked test issue, depending on how your instance links tests. ## Prompt template: sharpening requirements (approved AI tool) ```text Rewrite each requirement below so it is testable: add a measurable criterion, the user role and the condition. Do not invent numbers: where a threshold is needed, write [AGREE THRESHOLD] and suggest what data would set it. Flag any requirement that combines several needs and propose how to split it. Output a table: original | rewritten | open question for the product owner. ``` The product owner and users agree the final wording and thresholds. ## How to measure success - Every deliverable has acceptance criteria; every Must has a test. - Share of Musts kept to a level the team can deliver with contingency. - Change requests traceable to specific scope items, with exclusions cited when declined. ## Video lecture: Scope, requirements and the WBS Lecture coming soon · 10 chapters · about 9 minutes. Read the full transcript below. 1. 'A portal for students' 2. Why it matters 3. The concept: scope statement and exclusions 4. Eliciting and prioritising requirements 5. Worked example one: rewriting three requirements 6. Worked example two: the Lahore student portal 7. Watch me do it: a traceability matrix 8. From scope to WBS, and acceptance 9. Common mistakes 10. Recap and try this now ## Lecture transcript ### '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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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. ### 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? ## Key takeaways - Agree in-scope, out-of-scope, deliverables, constraints and assumptions in a scope statement. - Use multiple elicitation techniques; write testable functional and non-functional requirements. - Prioritise with MoSCoW and keep Musts limited so scope can flex. - Build a WBS or backlog covering all work, and trace requirements to design and tests. ## Try it Write a scope statement with at least five explicit exclusions for a project you know, and prioritise ten requirements with MoSCoW. - [Previous: The business case and benefits realisation](https://optimizeall.com/learn/project-management-leadership-with-ai/business-case-and-benefits) - [Next: Estimating, scheduling and budgeting essentials](https://optimizeall.com/learn/project-management-leadership-with-ai/estimating-scheduling-budgeting) - [All lessons of Project Management Leadership with AI](https://optimizeall.com/learn/project-management-leadership-with-ai)