How to write a research proposal

A research proposal is the first document in your degree that has to persuade a skeptical reader. Whether it goes to a supervisor, an admissions panel, or a funding committee, it will be read against three questions: is this worth doing, can it be done with the time and resources available, and is this the person to do it. Every section of the proposal exists to answer one of those three questions, and anything that does not answer one of them is padding. Experienced reviewers skim past padding quickly, and they notice how much of it there is.

This guide covers the standard structure, then concentrates on the three parts that decide most outcomes: the research question, the literature context, and the methodology. It also covers the feasibility signals reviewers scan for, the most common reasons proposals come back for revision, and how to use AI in the drafting process without importing invented references, which is the fastest way to lose a reviewer's trust before they reach page two.

What a research proposal has to do

A proposal is a plan, not a miniature thesis. You are not expected to have results, and you are not expected to have read everything ever published on your topic. You are expected to show that a specific, answerable question exists, that answering it would matter to someone beyond you, and that the method you describe would actually produce an answer within the time you have.

It is also, informally, a contract. Your committee will hold you to the scope you set here, which cuts both ways: a proposal that promises four studies invites four studies' worth of scrutiny, while a tightly scoped proposal gives you something defensible to point at when your project inevitably tries to grow. Write the proposal you want to be held to, not the most impressive one you can imagine.

Finally, it is a writing sample. Reviewers infer your ability to complete a thesis partly from whether the proposal itself is organized, precise, and correctly referenced. Sloppy citations in a proposal are read as a preview of sloppy citations in a thesis, and committees act on that prediction.

Research proposal structure: the standard sections

Departments vary in headings, ordering, and length limits, so read your handbook or the call document before anything else. Underneath the local formatting, though, almost every proposal contains the same skeleton:

• Title: a working title that names the topic, population, and method, not a pun you will regret.
• Introduction and problem statement: the gap you address and why it matters now.
• Research questions or hypotheses: one primary question, two or three subquestions at most.
• Literature context: what is known, what is contested, and what is missing.
• Methodology: design, data, sampling, analysis plan, and ethics.
• Timeline: phases mapped to your program's milestones, with slack built in.
• Expected contribution: what will exist after the project that does not exist now.
• References: every source cited in full, in your department's required style.

Start with an answerable research question

The question is the load-bearing element of the whole document. A question is answerable when you can name the data that would answer it and the method that would produce that data. 'How does social media affect mental health' is a topic. 'Does daily time on short-form video predict self-reported anxiety in first-year undergraduates over one semester' is a question: it names a population, variables, and a timeframe, and it implies a design.

Aim for one primary question and at most two or three subquestions. Subquestions should decompose the primary question, not smuggle in extra projects. If a subquestion could stand as its own thesis, cut it and mention it in a future-work paragraph instead, where it earns you credit without costing you scope.

If you are still circling a topic rather than holding a question, fix that before you write anything else. CiteDash's Question Builder is built for exactly this step, and every later section of the proposal gets easier once the question stops moving. The alignment work described below is close to impossible while the question is still soft.

The literature context: prove the gap is real

The literature section of a proposal is short and argumentative, not encyclopedic. Its job is to establish three things: what is known, what is contested, and what is missing. The gap you claim must survive a reviewer who knows the field well, so organize the section by theme or debate rather than marching through papers one at a time. A sequence of paragraph-long paper summaries reads as note-taking; a paragraph that sets two camps against each other and names what neither has tested reads as scholarship.

Every claim about the field needs a citation, and every citation must be real and correctly attributed. Reviewers spot-check references, and a single fabricated or misattributed source can sink an otherwise strong proposal, because it poisons trust in everything else. This is where generic AI assistants are most dangerous: they will happily produce plausible-looking references that do not exist, formatted perfectly.

Keep the section proportionate. In a proposal you are demonstrating command of the terrain, not reviewing it exhaustively; the full review comes later, in the thesis itself. For that longer job, see how to write a literature review with AI.

Methodology: show you know what you will actually do

This is the section reviewers read most closely, because it is where vague proposals hide. 'Interviews will be conducted and analyzed thematically' tells a reviewer nothing. How many interviews, with whom, recruited how, asked what kinds of questions, transcribed by whom, coded through what process, and analyzed against which framework? Each unanswered question is a place where the reviewer must trust you on faith, and proposals are not read in a spirit of faith.

Justify the design against alternatives. If you chose a survey over interviews, say why in one or two sentences. Reviewers do not need a lengthy defense; they need evidence that you knew the alternatives existed and chose deliberately rather than defaulting to the method you find least frightening.

Name your analysis plan concretely. If your data will be quantitative, name the tests you expect to run and the environment you will run them in. If it will be qualitative, name the coding approach and the framework behind it. If human participants are involved, state the ethics approval you will seek and when you will seek it. Specificity in this section is the single strongest competence signal in the whole document.

State the expected contribution plainly

Somewhere near the end, the proposal should say in one or two sentences what will exist after the project that does not exist now. Contributions come in recognizable kinds: empirical (new evidence about a population or setting), theoretical (a concept extended, challenged, or connected), methodological (a technique adapted or validated), and practical (guidance a named group can act on). Name the kind you are claiming, then state the specific contribution in language a reviewer could quote in their report.

Be specific rather than grand. 'This study will contribute to the literature on X' claims nothing and is read accordingly. 'This study will provide the first longitudinal evidence on X in population Y, allowing Z to be tested directly' is a claim a committee can weigh, and the act of writing it forces you to check that your design can actually deliver it.

Timeline, scope, and feasibility

Reviewers read the timeline to find out whether you understand the work, not to hold you to particular weeks. A credible timeline has phases, dependencies, and slack:

• Ethics approval: placed early, because data collection cannot begin without it.
• Recruitment and data collection: assume it takes longer than your first estimate, because it will.
• Analysis: scheduled as its own phase, not squeezed into a week at the end.
• Writing: chapters drafted alongside the work, not deferred until after it.
• Buffer: a named contingency period, which reviewers read as realism rather than weakness.

Why proposals get sent back

If the timeline does not fit, cut scope rather than compressing the schedule; a smaller project completed is worth more than an ambitious one abandoned, and reviewers know which outcome an overloaded timeline predicts. Beyond feasibility, committees see the same problems over and over. Before you submit, check your draft against the usual suspects:

• A question too broad to be answered by the methods described.
• A literature section that summarizes without arguing, so no gap ever emerges.
• Methodology written in the passive future tense with no specifics: participants, instruments, and analysis all unnamed.
• Misalignment: the question asks one thing, the methods measure another, and the contribution claims a third.
• A timeline with no ethics phase, no analysis phase, or no slack anywhere.
• Reference errors: missing sources, wrong years, inconsistent style.

Drafting the proposal with grounded AI

Alignment failures are the most common of those faults and also the most fixable: read the proposal once through asking only whether each section follows from the one before it. AI can legitimately speed up the drafting itself: structuring sections, tightening prose, turning your notes into readable paragraphs. The risk concentrates in one place: references. A general-purpose chatbot generates citations from patterns rather than from a database, so a proposal drafted that way needs every reference manually verified against the actual paper before submission.

CiteDash removes that failure mode structurally. In the Thesis Editor you draft section by section against the real papers in your project library. Every citation is a database object that resolves to an actual paper, never free text, and the Fact Checker verifies claims against held full-text PDFs before the draft reaches you. An invented reference cannot survive that pipeline, because there is no path for one to enter it.

When the draft is ready, the Thesis Assembler compiles it to DOCX, PDF, or LaTeX with a citeproc bibliography in your department's style, from a list of 12 supported styles. If your department asks for a statement about AI assistance, it can generate an AI-use disclosure to submit alongside the proposal.

Final checks before you submit

Reread the call or handbook one last time and check every stated requirement: length, required sections, referencing style, submission format. Requirements compliance is the cheapest possible win, and its absence is the cheapest possible rejection. Committees with many proposals to read are actively looking for easy reasons to shorten the pile.

Then do the alignment read: question, gap, method, timeline, contribution, in one sitting, asking whether each follows from the last. Have your supervisor or a peer do the same read cold; they will catch the leap of logic you can no longer see because you have read the document forty times.

Finally, verify that every reference resolves to the paper you think it does. If your references live in CiteDash this is already enforced by the system; if any were added by hand, check them by hand. A proposal is a promise about how carefully you will work for the next several years. Make the first piece of evidence count in your favor.