How to Write a Research Proposal for a Bioinformatics PhD

A bioinformatics PhD research proposal is a write-up that shows you can frame one answerable question, name the public data and software that would answer it, and judge whether the work is feasible. India’s UGC regulations call it a “brief write-up” and give a committee the job of finalising your topic after admission.
That last sentence changes how the document should be written, and almost no page aimed at Indian applicants says it. Our guide to applying for a bioinformatics PhD in India and abroad covers routes, eligibility and what an application is judged on, and it tells you to settle four questions before you spend a weekend on a statement. This page is the document itself.
What you will find on this page
- What the UGC PhD Regulations 2022 actually define a research proposal to be, quoted from the Gazette
- Which document each admission system wants, compared in one table, because sending the wrong one is a common and avoidable waste
- The anatomy of the proposal, section by section, with the question each section has to answer
- How to prove feasibility when you have no results of your own yet, using a number you can re-derive today
- A four-part test you can run on your own draft question before anyone else reads it
- Real failure modes and their fixes, plus an FAQ
What is a research proposal actually for?
It is evidence of judgement. A selection committee reading your proposal is not deciding whether your thesis will be about this. It is deciding whether you can tell a question from a topic, whether you know where the data would come from, and whether you can see the shape of the work before you start it.
The Indian regulation says so directly. The UGC’s Minimum Standards and Procedure for Award of Ph.D. Degree Regulations, 2022 define the term in clause 2(1)(u):
“Research Proposal” means a brief write-up giving an outline of the proposed research work which the Ph.D. scholar shall submit along with the application for registration for Ph.D. programme
A brief write-up, submitted with the application. Then clause 10(1) sets up a Research Advisory Committee for every scholar, and its first listed responsibility is the one that settles the argument:
To review the research proposal and finalize the topic of research.
The committee’s second responsibility is “To guide the Ph.D. scholar in developing the study design and methodology of research”, and clause 10(2) requires the scholar to appear before that committee each semester with a brief progress report. So the topic is finalised after admission, the methodology is developed after admission, and the progress is reviewed on a running basis.
Two practical consequences follow, and they are the opposite of how most students write. First, you do not need to promise a whole programme of work; promising one is a signal that you have not understood how long one question takes. Second, you cannot hide a vague question behind scope, because the reviewer is reading for the question, not the volume.
Which document does your target system actually want?
Before you write anything, find out whether a free-standing research proposal is the document being asked for. It often is not, and the three common situations want different things.
| Situation | What you actually submit | Who finalises the topic | What the document is judged for | The rule that governs it |
|---|---|---|---|---|
| Indian HEI, admission through the institution’s own entrance test | Application plus the brief write-up, then an interview | The Research Advisory Committee, after admission | Whether you can frame a question and judge feasibility | Gazette clause 5(2)(ii) to (vi): the entrance test syllabus is “50% of research methodology, and 50% shall be subject-specific”, 50% marks are needed to be called for interview with a 5% relaxation for SC/ST/OBC/differently-abled and EWS candidates, and selection on this route carries “a weightage of 70 % for the entrance test and 30 % for the performance in the interview/viva-voce” |
| Indian HEI, admission on a national fellowship you already hold | Application plus the brief write-up, then an interview | The Research Advisory Committee, after admission | The same, but the proposal and interview carry more of the weight because there is no institutional test score | Gazette clause 5(2)(i): institutions “may admit students who qualify for fellowship/scholarship in UGC-NET/UGC-CSIR NET/GATE/CEED and similar National level tests based on an interview”. The 70/30 split does not apply here |
| A funded European project vacancy, for example an MSCA Doctoral Network post | A job application against an advertised project, usually a CV, a motivation letter and referees | The project already has a topic, written by the host before the post was advertised | Fit with that specific project and with the host | Posts are advertised as jobs, including on the EURAXESS jobs portal, and MSCA Doctoral Networks add a mobility condition on where you have lived before recruitment |
Sending a free-standing proposal to an advertised project vacancy is a real and frequent error. The topic is already fixed, so a document arguing for your own question reads as a failure to read the advert.
For the Indian route, there is one more thing to do before you write, and the regulation itself tells you to do it. Clause 5(3)(i) requires every eligible institution to “Notify a prospectus well in advance on the institution’s website specifying the number of seats for admission, subject/discipline-wise distribution of available seats, criteria for admission, the procedure for admission, and all other relevant information for the candidates”. Your target department publishes its own requirements. Read those rather than trusting any page, including this one, that prints a length as a standard.
Want the guided, hands-on version?
Our live Molecular Modeling & MD Simulations cohort bootcamp takes you from zero to running real docking and MD workflows, with a portfolio project for your grad-school applications.
What goes in each section, and what does each section have to prove?
Start from the aims and let everything else answer to them. In the fellowship literature this short front section has a name and a job. Marshall and Kelly, writing in PLoS Computational Biology, make it rule four of Ten Simple Rules for Writing a Postdoctoral Fellowship and describe a Specific Aims document as “usually a one-page description of your plan during the project period”, adding that “it is very likely your Specific Aims will be the first document your reviewers will read”.
The same rule lists the questions that section must answer: “Is the research question important?”, “What is the overall goal?”, “What specifically will be done?” and “What are the expected outcomes and impact?”. One phrase inside it is worth memorising, because it is the test most student proposals fail. The overall goal “must be attainable regardless of how the hypothesis tests”. If your proposal only produces a result when the answer comes out the way you hope, the goal is not a goal.
Above the aims sits the shape of the whole document. A 2026 guide in the same journal, Ten simple rules for turning your qualifying exam into an NIH-style fellowship proposal, describes it plainly: “The research plan for graduate funding opportunities usually consists of two sections: 1) Specific Aims and 2) Research Strategy”, with the research strategy “consisting of several subsections like the significance, innovation, approach, timeline, and future directions”. Its next sentence is the one to act on before you write a word: “Always read instructions carefully because funders can have different requirements and page limits.” That is the same instruction the UGC prospectus clause gives, arriving from the other direction.
Mapped onto a computational project, the sections and their jobs look like this.
| Section | The question it answers | How students most often get it wrong |
|---|---|---|
| Title and one-line question | What single thing are you trying to find out? | A field is named instead of a question, for example “machine learning in genomics” |
| Background and the gap | What is already known, and what is missing? | A textbook summary of the field with no sentence identifying what nobody has done |
| Aims | What will be done, and does each aim stand on its own? | Aim two cannot start unless aim one gives a particular answer, so a negative result stops the project |
| Data | Which records, from where, and how many? | “Publicly available datasets”, with no archive, no accession and no count |
| Methods | Which tools, at which versions, compared against what baseline? | Tool names with no versions, no baseline, and no statement of what would count as a failure |
| Feasibility and timeline | Can this be done with the data, software and hardware available? | Nothing on hardware or runtime, so the reviewer cannot tell whether one full pass is even possible |
| Expected outcomes | What will exist at the end that does not exist now? | Promised conclusions rather than promised artefacts such as a benchmark, a pipeline or a dataset |
| References | Have you read the field you say has a gap? | A short list of reviews, with none of the primary papers that would have shown the gap already closed |
How do you turn a vague interest into one answerable question?
By writing down the problems in your field as you read, rather than trying to invent a question from an empty page. Rule three of the same paper is blunt about the method: “Keep a list of questions or problems inherent to your field and update this list after reading germane peer-reviewed and review articles”. The questions come out of the literature, in the sentences where authors say what they could not do.
A worked narrowing looks like this. “I am interested in immunoinformatics” is a field. “I want to work on epitope prediction” is a topic. “Do structure-based B-cell epitope predictors agree with each other on predicted structures as well as they do on crystal structures, and does the disagreement track model confidence?” is a question: it names what would be measured, it can be answered either way, and a reviewer can see at a glance which data and tools it needs.
Notice what the question does not do. It does not promise a vaccine. It does not promise that the answer will be interesting. It promises a measurement, which is the only thing you are in a position to promise before you start.
How do you prove feasibility when you have no results of your own?
This is the fear that stops most students writing, and it is based on a misunderstanding of what the feasibility section is for. You are not being asked for preliminary results. You are being asked to show that the work could actually run. For a computational project that is an unusually answerable question, because the data and the software are both public and both checkable by the reviewer.
So name them, and name them precisely. The strongest feasibility paragraph a student can write says which archive, which query, how many records that query returns, which tool at which version, and what hardware one full pass needs. Every one of those is verifiable before a decision is made, which is a structural advantage no wet-lab proposal has.
Public archives are larger than most applicants assume. The NCBI E-utilities endpoint will tell you the current size of the GEO Series collection, and you can re-derive the number yourself rather than taking ours:
curl -s "https://eutils.ncbi.nlm.nih.gov/entrez/eutils/esearch.fcgi?db=gds&term=GSE%5BEntry+Type%5D&retmax=0"On 6 October 2026 that returned a Count of 297,824 GEO Series. Run the same query with a nonsense entry type and the count comes back as zero, which is how you confirm the filter is really being applied rather than reporting a collection total. Use the same discipline on whichever archive your own question needs: run the query, print the count, and cite the date you ran it.
Where you genuinely need results to carry an argument, borrowed and published results are allowed, and the 2026 guide says so in terms worth quoting to yourself the next time the blank page wins:
You may not have much in terms of your own preliminary data, depending on what stage you are in your training. This may feel daunting, but it is still possible to write an effective proposal because you can cite published data or even data from others within your research group. You can also include schematics, such as detailed analysis pipelines or your proposed hypothesis, as figures within your proposal.
A pipeline schematic is often the single most useful thing a student can add, because it shows the reviewer the shape of the work in one glance. What is not allowed is leaving feasibility unaddressed and hoping nobody asks.
What should the methods section of a computational proposal name?
Five things, and a reviewer can check all five.
- The data, with its identifier. Archive, query, record count, date. “Sequences from a public database” tells a reviewer nothing; a named accession set tells them you have already looked.
- The software, with versions. A pipeline described without versions cannot be reproduced, and a proposal that ignores versions suggests the writer has not run the tools.
- The baseline. Whatever you build has to be compared with something, usually the current standard method or a published result on the same data. A method with no baseline cannot be shown to work.
- The hardware and the scale of one pass. Whether the work runs on a laptop, a department server or a cluster. If you do not know, say which you would need and why, and if the honest answer is a cluster you do not have, that is a reason to propose the smaller version of the question.
- What a negative result looks like. Write the sentence that describes the outcome where your hypothesis fails and the work is still a result. If you cannot write it, your aims are not independent yet.
If you have never run a pipeline end to end, that gap shows in this section more clearly than anywhere else in the application, and it is the cheapest gap to close. Working through a free, certificate-backed course and keeping the output is the usual route; our list of free certifications worth doing and the longer comparison of free bioinformatics certifications are both built for that. The skills a computational biology role actually needs maps the same ground from the employment side.
How do you test your own draft before anyone else reads it?
Run these four checks on your question. Each one has a specific repair.
- Can you name the data? Write the archive, the query and the count. If you cannot, the question is not yet a project; either find the data or change the question to one the data supports.
- Can one full pass run on hardware you can reach? Not the whole PhD, one complete pass of the core analysis on real input. If not, propose the subset version and say that it is the subset version.
- Is the negative result still a result? If the answer coming out the other way would end the project, split the aims so that each one produces something regardless of outcome.
- Is there a smaller version of the same question? There almost always is, and proposing it is a strength rather than a retreat. A reviewer reads a right-sized question as evidence of judgement.
Then get a human to read it, early, while it is short. The one-page draft is the right thing to circulate for exactly the reason Marshall and Kelly give: “evaluating a one-page document is not an enormous time investment on part of the person giving you feedback”. A supervisor who will not read a full proposal will read one page.
Finally, check the application for internal contradictions. The same paper’s rule eight is that “it is important that all your documents tell a consistent and cohesive story”. The commonest break is between the proposal and the CV: a proposal claiming a method the CV shows no evidence of, or a CV listing skills the proposal never uses. Our guide to writing a bioinformatics CV as a student covers the other half of that pairing.
What goes wrong, and how do you fix it?
| What you see | What is actually wrong | The fix |
|---|---|---|
| You have written pages and the question still is not in there | The draft states enthusiasm and field importance instead of a question. This is the single most common failure | Write the one-line question first, on its own, then delete any paragraph that does not serve it |
| The proposal describes several years of work across many aims | It is scoped to a programme rather than to a question, which reads as inexperience | Keep the question. The Gazette gives topic finalisation to the Research Advisory Committee after admission, so scope is not what you are being judged on |
| The topic was chosen to match a particular supervisor | It was matched to a profile page, not to their papers, so the proposal proposes work they finished or abandoned | Read their recent primary papers and build on what the discussion sections say is unresolved |
| Feasibility is a paragraph of reassurance | No archive, no accession, no count, no hardware, so the claim cannot be checked | Replace it with the five named items from the methods list above, each with a date |
| Aim two depends on aim one giving a particular answer | The aims are a chain, so one negative result ends the project | Rewrite so each aim yields an artefact either way, and state what the negative outcome would be |
| A European project vacancy rejects the application without comment | A free-standing research proposal was sent to a post whose topic was already defined | Apply to the advertised project with a CV and motivation letter, and check the mobility conditions before you spend time on it |
| Two institutes asked for different documents and lengths | You worked from a general page instead of each institution’s own prospectus | Clause 5(3)(i) requires the prospectus to be published on the institution’s website. Read each one and keep a per-institute checklist |
| The proposal reads well but nobody senior has seen it | Feedback was deferred until the document was long, which is when feedback is most expensive to act on | Circulate the one-page aims first, revise, then write the rest |
Where does this sit in the rest of the application?
The proposal is one document among several, and it is the one that most reflects whether you have done real work. Before it, there is the question of whether you have a pipeline you have actually run: the free certifications and assessment route is the fastest way to get there, and a bioinformatics portfolio is where the evidence lives. Alongside it sit the CV and, if you have one, a first paper. After it comes the interview, which our guide to preparing for a bioinformatics interview or coding test covers, and where you should expect to defend every feasibility claim you made.
If you are earlier than that and still deciding on the route itself, start from how to apply for a bioinformatics PhD in India and abroad, or from how to become a bioinformatician in India after a BSc or MSc if you are weighing the PhD against a job. Coming from a wet-lab background changes the proposal’s methods section in particular, and we cover that move in moving into computational biology from a wet-lab background. For the order in which the underlying skills are worth learning, the computational biology skills roadmap is the pillar guide, and project ideas for MSc students is where a first question often comes from. The team’s own published work is listed on our research page.
FAQ
How long should a bioinformatics PhD research proposal be?
As long as your target institution says. The UGC regulations call it a brief write-up and require each institution to publish its own admission requirements in a prospectus on its website, so the length is set there and not by any general rule. Any page quoting a standard page count is guessing.
Does the proposal lock in my thesis topic?
In the Indian system, no. Clause 10(1)(i) of the UGC PhD Regulations 2022 gives the Research Advisory Committee the responsibility “To review the research proposal and finalize the topic of research”, and that committee is constituted after you are admitted. The proposal is evidence of judgement, not a commitment.
Can I write a proposal without any preliminary data of my own?
Yes, and most applicants do. Cite published results, or data from the group you are applying to, and include a schematic of the analysis pipeline you propose. What matters is that the feasibility argument is checkable: name the archive, the query, the record count, the tools and the hardware.
Do I need a proposal for a PhD position in Europe?
Usually not. Funded project posts, including MSCA Doctoral Network positions advertised on EURAXESS, come with a topic already written by the host, and you apply as you would to a job. Check the advert and the mobility conditions before writing anything, because a free-standing proposal is the wrong document there.
Should I contact a potential supervisor before writing the proposal?
Read their recent primary papers first, then make contact with a specific question that follows from them. A proposal built on a profile page tends to propose work that is already finished. Their discussion sections are where the unresolved problems are stated plainly.
What is the single most common reason a proposal gets dismissed?
It states interest instead of a question. A reviewer can read enthusiasm in one sentence and learns nothing from the next page of it. Name one answerable question, the data that would answer it and the method, and the rest of the document writes itself.
Written by the StemSkills Lab team, who have more than ten years of work in sequence and structural bioinformatics, drug discovery and design, and multiscale molecular modelling, and who supervise student research projects.
Want the guided, hands-on version?
Our live Molecular Modeling & MD Simulations cohort bootcamp takes you from zero to running real docking and MD workflows, with a portfolio project for your grad-school applications.
