A computer science PhD research proposal has eight parts that a selection panel or supervisor reads in this order: title, problem statement, research questions, related work positioning, methodology, contribution and evaluation plan, timeline, and resources required — typically 1,500–2,500 words for a UK studentship application. Below is the method, step by step, with a fully worked example for an edge-computing topic. The worked example is invented for illustration; it is not a real submitted proposal.
Step 1: Choose a problem that is novel, feasible and stated in one sentence
The single biggest reason computer science proposals are rejected is scope: a problem broad enough to be a research agenda, not a three-to-four-year PhD. A working test is whether the problem statement fits in one sentence that names a gap, not a field. Weak: “This project investigates machine learning for the Internet of Things.” Working: “Current federated learning algorithms assume reliable network connectivity between edge devices, but intermittent connectivity on low-power IoT hardware causes model convergence to fail in ways existing aggregation methods do not correct for.” The second version names a specific mechanism (aggregation under intermittent connectivity), not a broad area.
Step 2: State two or three research questions the thesis will actually answer
Each question should be answerable with a method you can name today, not a method you hope to discover. A worked set, illustrative: RQ1 — How does intermittent connectivity affect convergence time in standard federated averaging? RQ2 — Can an adaptive aggregation schedule recover convergence without increasing communication overhead? RQ3 — Does the proposed schedule generalise across at least two device classes with different power constraints? Three is a practical ceiling; a fourth question is usually a sign the first three are not yet specific enough.
Step 3: Position the work against related work in one page, not ten
A proposal is not a literature review — it needs enough related work to show the gap is real and the panel that a candidate already knows the field, in roughly 300–500 words. The convention is three clusters: the closest prior work (what it does and where it stops), the broader area (why the problem matters at all), and one adjacent field the approach borrows from (control theory, distributed systems, or signal processing, depending on the topic). Naming specific venues where this subfield publishes — for computer science that typically means naming conferences such as NeurIPS, ICML, MobiSys or SenSys rather than only journals — signals the candidate already reads the field’s actual publication venues.
Step 4: Choose and justify a methodology that fits a systems or algorithms thesis
Computer science doctoral work usually falls into one of three methodological shapes, and a proposal should name which one applies rather than leave the panel to guess: (1) an algorithmic/theoretical thesis, where the contribution is a proven bound or a novel algorithm evaluated against baselines; (2) a systems/empirical thesis, where the contribution is a built artefact evaluated on benchmark workloads or a testbed; (3) a human-centred or HCI thesis, where the contribution is evaluated through a user study and needs ethics approval before data collection starts. A worked justification, illustrative: “This is a systems/empirical thesis: the proposed adaptive aggregation schedule will be implemented as an extension to an existing federated learning framework and evaluated on a physical testbed of resource-constrained devices, rather than through purely theoretical convergence bounds, because the connectivity failure modes this thesis addresses are not fully captured by existing theoretical models.”
Step 5: State the contribution and the evaluation plan together
A panel wants to see, on one page, what “success” looks like before the candidate has done the work. A worked contribution-and-evaluation pairing, illustrative: “Contribution: an adaptive aggregation schedule for federated learning under intermittent connectivity, with a formal characterisation of the connectivity conditions under which it outperforms standard federated averaging. Evaluation: convergence time and final model accuracy compared against three baseline aggregation methods, on two public IoT benchmark datasets and one physical testbed of ten resource-constrained devices, under three simulated connectivity profiles.” Naming the baselines and the datasets, even provisionally, is what separates a proposal a panel can assess from one that only states an ambition.
Step 6: Build a year-by-year timeline that survives contact with reality
A studentship-application timeline does not need the depth of a full multi-year thesis chapter planner, but it needs to show the panel the work is sequenced sensibly. A worked skeleton for a three-year full-time UK PhD, illustrative: Year 1 — literature review, baseline reimplementation, initial testbed build; Year 2 — core algorithmic contribution, first evaluation round, first conference submission; Year 3 — extended evaluation, generalisation experiments, thesis writing. Building in a deliberate slack period before the funded end date, rather than assuming every experiment succeeds first time, is one of the details panels read for.
Step 7: State the resources the project actually needs
For a computer science proposal this is rarely a cash budget in the way a lab science needs reagents — it is compute access (a GPU cluster, cloud credits, or a specific hardware testbed), software licences if any are not open source, and, for a human-centred thesis, ethics approval lead time before any user study can begin. Naming the specific facility a department already holds (a named HPC cluster, an existing IoT testbed in the research group) rather than a generic “sufficient compute resources” line shows the proposal has been checked against what the host institution can actually provide.
Step 8: Reference the proposal like the literature review it partly is
Fifteen to twenty-five references is a realistic range for a proposal at this stage — enough to demonstrate command of the related work in Step 3, not a full thesis bibliography. Every claim about what existing work does or does not do needs a citation attached at the point the claim is made, not bundled into a reading list at the end.
The proposal at a glance
| Section | Typical length | What a panel is checking |
|---|---|---|
| Title | One line | States the mechanism, not just the area |
| Problem statement | 150–250 words | One sentence a panel can restate back to you |
| Research questions | 2–3 questions | Each answerable with a named method |
| Related work | 300–500 words | Three clusters: closest work, broader field, adjacent borrow |
| Methodology | 300–500 words | Names which of the three CS thesis shapes applies |
| Contribution + evaluation | 250–400 words | Named baselines, datasets or testbed, metrics |
| Timeline | 150–250 words | Sequenced across the funded period, with slack built in |
| Resources | 100–150 words | Specific facilities, not a generic sufficiency claim |
Full worked example (illustrative — not a real submitted proposal)
Title: Adaptive Aggregation for Federated Learning Under Intermittent Edge Connectivity.
Problem statement: Federated learning enables model training across distributed edge devices without centralising raw data, but standard aggregation methods such as FedAvg assume each participating device reliably reports an update every round. Low-power IoT devices operating on constrained or intermittent connectivity routinely miss rounds, and existing aggregation methods either exclude these devices (biasing the model against the populations they represent) or average stale updates in ways that slow convergence and can prevent it entirely under sufficiently unreliable conditions.
Research questions: RQ1 — How does intermittent connectivity, modelled at three severity levels, affect convergence time and final accuracy under standard federated averaging? RQ2 — Can an adaptive aggregation schedule that weights updates by recency and device reliability recover convergence without a proportional increase in communication overhead? RQ3 — Does the proposed schedule generalise across device classes with materially different power and connectivity constraints?
Methodology: a systems/empirical thesis. The adaptive schedule will be implemented as an extension to an open-source federated learning framework and evaluated first in simulation across three connectivity profiles, then on a physical testbed of ten resource-constrained devices built in the host research group’s existing IoT lab.
Contribution and evaluation: an adaptive aggregation schedule with a formal characterisation of the connectivity conditions under which it improves on FedAvg and two other published baselines, evaluated on convergence time and final accuracy across two public benchmark datasets and the physical testbed described above.
Timeline: Year 1, baseline reimplementation and simulation environment; Year 2, adaptive schedule design, first simulation results, first workshop submission; Year 3, physical testbed evaluation, generalisation experiments, thesis writing, with a two-month slack period before the funded end date.
Resources: access to the department’s existing ten-node IoT testbed and a modest cloud-compute allocation for simulation at scale; no additional ethics approval is required, as the work does not involve human participants or personal data.
Frequently asked questions
Is this a real, previously accepted computer science PhD proposal?
No. Every detail — the topic, the research questions, the testbed, the timeline — is invented for illustration. Use it to check the shape and register of your own proposal, not as a source of real citations or claims.
How is a computer science proposal different from the generic UK studentship proposal guide on this site?
The site’s general guide to writing a PhD research proposal for a UK studentship application covers what selection panels assess across all fields, the funding and fee figures, and how to write a feasible timeline in general terms. This piece adds what is specific to computer science: the three methodological shapes a CS thesis can take, how to position work against a fast-moving field where the leading venues are conferences rather than only journals, and a fully worked systems/empirical example.
Should I name specific conferences rather than journals as target venues?
Yes, for most computer science subfields — naming the actual top venues a subfield publishes in (which are very often conferences, unlike most other sciences) signals the candidate already reads the field the way active researchers in it do.
Do I need preliminary results to submit a strong proposal?
No, though a small proof-of-concept or baseline reimplementation strengthens a proposal considerably where the candidate already has the skills to produce one. A studentship-stage proposal is assessed on feasibility and framing more than on results that do not yet exist.
How long should the whole proposal actually be?
Most UK computer science departments expect 1,500–2,500 words excluding references, though the exact figure is set by the individual scheme or supervisor — check the specific call rather than assume a network-wide number.
What is the single most common reason a strong idea gets a weak proposal?
Scope stated at the level of a field rather than a mechanism — see Step 1. A panel cannot assess feasibility against “machine learning for IoT”; it can assess feasibility against a named failure mode in a named algorithm class.
Does the methodology section need to commit to every technical detail in advance?
No — it needs to commit to the methodological shape (Step 4) and a plausible evaluation plan, not to every hyperparameter or dataset split; those are refined once the project starts and are expected to evolve.
Where can I find real funding figures to reference in the resources section?
The site’s own piece on UKRI doctoral training by research council sets out current award types and figures by discipline, useful context for a computer science proposal typically funded through EPSRC.
Is an AI research-proposal generator a shortcut worth using here?
The site’s own honest assessment of what an AI research proposal generator can and cannot do applies directly here: it can structure and draft alongside you, but a generated proposal that has not been shaped by the candidate’s own reading of the field fails at interview.
Does the proposal need to state the original contribution to knowledge the way the final thesis will?
Not in the fully tested form a completed thesis needs — see the site’s piece on what an original contribution to knowledge actually requires — but the contribution statement in Step 5 is that claim’s first draft, and panels do check whether it is a claim the proposed methodology could plausibly support.