Scope a capstone project with clear deliverables
Match a capstone deliverable to your available time, skills and access. Use a scope worksheet and a worked example with a smaller fallback project.
About 7 min read · Allow extra time for the practical checks
A capstone scope should tell you what you will deliver, for whom and within which limits. “Improve student communication” is a starting interest. It becomes a workable project when the output, evidence, access and completion test are specific.
The worksheet below helps you decide whether a proposed deliverable fits the resources you can actually use. It suits practical undergraduate, professional and MBA projects, but your module requirements and supervisor’s decisions determine which outputs are acceptable.
Begin with the required output
Write down what the assessor expects: perhaps a report, design, prototype, analysis or a combination. Include any required evaluation, presentation or process record. A smaller project is not a workable fallback if it removes an assessed requirement.
Separate the thing you will produce from the change you hope it might cause. A student-information guide is a deliverable. Fewer missed deadlines is a possible outcome that would need appropriate evidence. Finishing the guide does not demonstrate the outcome.
If your main difficulty is choosing the question itself, start with planning a focused research question. This worksheet addresses the next decision: what you can credibly complete with your available capacity.
Fill in the scope and capacity worksheet
Copy these fields into your project notes. Where the answer is uncertain, record what you must confirm rather than filling the gap with an optimistic assumption.
- Required deliverable and reader: What will you hand over, and who needs to understand or use it? List assessed components separately.
- Completion test: What observable features will show that the deliverable is finished? Name the files, functions or checks rather than writing “complete”. Distinguish producing it from demonstrating its effectiveness.
- Evidence and access: Which documents, facilities, people or datasets does it depend on? Which are available now, and which require a decision or permission?
- Capacity: How many usable hours remain after other commitments? Which skills do you already have? Include learning, revision and checking time.
- Work estimate: Break the deliverable into tasks and estimate each. Mark uncertain estimates so you can revisit them after a small trial.
- Scope boundary: What is essential, what is optional, and what will this project explicitly leave out?
- Decision point and fallback: When must an unresolved dependency be settled? What alternative could still meet the assessment requirements, subject to supervisor approval?
Leeds’ Starting Your Project asks students to consider time, skills and access when judging manageability. Its project-management guidance recommends dividing work into stages with deadlines. The worksheet is an original way to apply those checks; it is not a university-prescribed planning formula.
Worked example: a student-information resource
Everything in this example is hypothetical. Assume a student’s module permits a documented prototype and an evidence-based design rationale, with the exact evaluation approach agreed with the supervisor.
The student’s first idea is to build a college-wide information portal, interview students, integrate account access and show that the portal reduces missed deadlines. That combines product development, access to participants, integration work and outcome evaluation. The student has not secured the necessary access and cannot treat those dependencies as completed tasks.
A smaller proposal for discussion is:
Produce a non-live guide prototype for one programme, using publicly available official information about three administrative tasks. Supply a source record, a design rationale and a documented check that each step and destination matches the source material. Treat the prototype as complete only when all three paths have a named starting point, a working destination and a matching entry in the source record. Do not claim that the prototype improves student outcomes.
The three tasks might be finding published submission instructions, locating an extension-request procedure and finding the correct support contact. The prototype would direct readers to the official information, not invent or replace programme rules. No real enquiries or applications need to be submitted to demonstrate the navigation concept.
Core work: the limited prototype, source record, rationale and agreed checks. Stretch work: a second presentation format if the core work is complete. Outside scope: live deployment, account integration, private student records and a claim of reduced missed deadlines. These boundaries become the working scope only after the supervisor confirms that they retain every assessed component.
Test the proposal against available hours
Assume this student has six working weeks and can realistically allocate eight hours per week after other commitments. That gives 48 hours. Reserving eight hours for uncertainty leaves 40 planned task hours. These are invented planning estimates, not recommended durations or a forecast for another student’s project.
On a narrow screen, scroll the table sideways to read every column.
| Work | Hours | Completion evidence |
|---|---|---|
| Confirm assessment fit and boundaries | 4 | Scope note identifying every required component and recording the supervisor's decisions |
| Read official sources and record task steps | 8 | Source log with page titles, destinations and access dates for all three paths |
| Create the limited prototype | 10 | Three navigable paths, each with a named start and working destination |
| Check source accuracy and revise | 6 | Checklist tracing every displayed step to the source log, plus resolved issue notes |
| Write rationale and limitations | 8 | Rationale separating design choices, documentary checks and unevaluated usability |
| Final checks and submission preparation | 4 | Submission files checked against every retained module requirement |
| Unallocated contingency | 8 | Capacity for uncertainty; not extra features |
The task estimates total 40 hours, with eight hours left unallocated. That arithmetic only shows that the plan fits its own assumptions. It does not prove the work can be completed. If an initial source check takes much longer than expected, revise the remaining estimates before committing to the whole scope.
Working hours and elapsed time are different. A short supervisor discussion might take little work time but require a longer wait. Put access and approval decisions early enough that their delay does not consume the entire project window.
Give uncertainty a decision point
Suppose interviews with current students were originally intended to shape the guide. Record access as unconfirmed until the relevant recruitment and approval requirements are settled. Do not begin collecting data merely because an interview slot appears in a plan.
At a checkpoint agreed with the supervisor, choose between continuing the approved interview route and proposing a document-based prototype. Do not substitute the fallback unless the supervisor confirms that it still meets the assessment requirements. The fallback changes what the project can claim: checking against official documents can establish consistency with those documents, but cannot establish whether students find the guide usable.
Carnegie Mellon’s guidance on independent student projects likewise asks supervisors to consider time, resources and permissions when setting a feasible task. It is supervisor-facing guidance, not an approval for this hypothetical fallback. If participant-based evaluation is compulsory in your module, this fallback may be unsuitable. Bring that conflict to the supervisor while there is still time to revise the plan.
Take a decision-ready scope to your supervisor
Bring the proposed output, capacity estimate and unresolved dependency together. For the invented project, the useful questions would be:
- Does a non-live prototype with this evaluation approach meet the assessed requirements?
- Are three task paths sufficient to demonstrate the required work, and which components are missing?
- What access or approvals are needed for the proposed evidence?
- When should we decide whether the alternative scope is necessary?
Record what was agreed, what remains open and what you will do next. Revisit the scope when access or estimates change. If you need help making the plan and its limits clearer, research support can help you develop the proposal for that discussion.
