Last updated: 2026-10-06
Scope, Feasibility, and Defining Success
Once a question is fixed, the next decisions set the boundaries of the work. What is in the project, what is out, and what would count as having done it well. Projects that drift usually do so because one of these was never settled. The student keeps adding "just one more thing", and the question is never quite answered.
This page covers scope, feasibility, requirements, and success criteria. These are linked because each one tests the others. A requirement that cannot be checked is not a success criterion, and a feature that cannot be built in the time available is outside the scope, however interesting it is.time is the silent scope-killer
Scope: What Is In, Out, and Deferred
A scope statement has three lists, not one. The first is what the project will deliver. The second is what it will explicitly not deliver. The third, which most students leave out, is what it might deliver if the first list finishes early. Writing the third list is useful because it gives you somewhere to put good ideas without letting them enter the core work.
Scope creep is usually gradual. A supervisor suggests an additional evaluation, a dataset turns out to be larger than expected, or an interesting tangent appears in the reading. Each change is small. The defence is to write the change into the scope statement and assign it to one of the three lists before work starts on it.scope is a contract with your future self
Feasibility
A feasibility check asks whether the project can be finished with the time, skills, data, and access you actually have. It is most useful when run against specific items rather than in general terms. The table below is a starting point for a check you can complete in an hour.
| Resource | Question to answer | Warning sign |
|---|---|---|
| Time | How many working weeks remain, after assessment deadlines and other modules? | The plan needs more weeks than you have, with no slack. |
| Skills | Which required skills do you already have, and which must you learn? | The learning is on the critical path and has no time allocated. |
| Data | Where does the data come from, and when will you have it? | The data depends on someone else's approval you have not requested. |
| Access | Do you have the users, systems, or organisation you need? | The project relies on access that has not been confirmed in writing. |
| Tools | Are the tools installed, licensed, and working on the machine you will use? | The first milestone depends on installing something you have never run. |
Where a check shows a gap, you have three options: reduce scope, obtain the missing resource, or change the question. The decision should be recorded. A change to the question is not a failure if it is made early and for stated reasons.pivots are features, not failures
Requirements Gathering
Requirements describe what the outcome must do or show. For a software project, they describe behaviour. For an empirical project, they describe the evidence the study must produce. In both cases, the requirements should come from the people who will use the outcome or judge it, not only from your own view of what would be interesting.
A requirement is useful when it can be checked. "The system should be fast" is not checkable. "The system should return results for a query of 10,000 records in under two seconds on the reference machine" is. The second form makes the requirement testable and also tells you what to measure. The same logic applies to requirements framed as behaviour. Written as Given, When, and Then scenarios, they become acceptance tests, as described in BDD as Specification: A Case Study in Deriving Code from Scenarios.
Requirements also carry assumptions, and assumptions are where projects tend to fail. Before accepting a requirement, ask whose view it reflects and what it takes for granted. The CATWOE framework offers a structured way to check this.whose values are baked in? CATWOE maps the hidden players
Defining Success Criteria
Success criteria are the subset of requirements that decide whether the project has answered its question. They should be few, specific, and agreed before the main work begins. Three or four well-chosen criteria are more useful than fifteen vague ones.
A good success criterion has three parts: the thing measured, the standard it must meet, and the evidence that will show it. For example, "the classifier identifies the target class with an F1 score above 0.8 on the held-out test set, reported with its confidence interval" has all three. "The classifier works well" has none.
Keep the criteria fixed once agreed, but allow them to change if the question changes. If a criterion becomes impossible to measure, say so in writing, explain why, and replace it. Silent changes are how projects end up claiming success against goals that were never written down.
Checking the Set Together
Before you move on, read the scope statement, the feasibility table, the requirements, and the success criteria together. Each success criterion should trace back to a requirement. Each requirement should sit inside the scope. Each item in scope should be feasible. If any link is missing, the project has a gap that will show up later, usually at the worst time.
Related Topics
- Finding a Project Idea and Refining the Question — the question these boundaries serve.
- Writing the Project Initiation Document — where scope and success criteria are recorded for assessment.
- Planning, Milestones, and Time — turning scope into a schedule.
- Risk Analysis for a Project — the uncertainties that a feasibility check should reveal.
- BDD as Specification: A Case Study in Deriving Code from Scenarios — writing requirements as checkable scenarios.
- Wicked Problems and Assumptions — checking whose view a requirement reflects.