From an Interest in Research to Writing My First Research Proposal
For the first few weeks of DataraFlow, the work had been fairly tangible. There was Python to practise, concepts to understand, assignments to complete, and code to write. You could look at a problem, work through it, and eventually see whether your solution worked.
Weeks 4 and 5 took a different direction.
Instead of focusing primarily on writing code, we were introduced to research and how to write a research proposal. Our task was to take a research idea, develop it into a topic, and turn that topic into a proposal.
It sounded straightforward enough when the task was first introduced. I soon realised that having an interesting idea and knowing how to investigate it properly are two very different things.
Learning How to Think About Research
Research was something I had been interested in for a while, particularly where machine learning intersects with healthcare and computational neuroscience. I had questions I wanted to explore, and I knew I wanted to build the technical skills to investigate them.
But interest alone does not make a research project.
The module introduced us to the process of developing a research topic and writing a proposal. It pushed me to think beyond the subject I found interesting and consider the actual research problem, the questions I wanted to answer, the existing work in the field, and the methods I could use to investigate those questions.
A research proposal has to do more than announce an interesting idea. It needs to explain what you want to investigate, why the question matters, what is already known, how you intend to approach the problem, and whether the proposed work is achievable.
That last part matters more than I initially appreciated.
It is easy to become attached to an idea because of its potential. It is harder to examine what the idea would require in practice, what evidence would be available, and whether the proposed methodology could genuinely answer the research question.
I had to start thinking about research as a process of making and defending decisions, not simply choosing a topic I cared about.
Choosing a Research Topic
When it was time to develop our own topics, I naturally gravitated towards my existing interests.
I am particularly interested in how computational methods can help us understand neurological conditions, including dementia and cognitive decline. I find the intersection of brain imaging, machine learning, and healthcare fascinating, especially the possibility of using data to investigate changes in the brain and their relationship with cognitive outcomes.
I wanted my project to connect with that broader interest while giving me something practical to work on as a data science and machine learning student.
The challenge was figuring out how to turn a broad area of interest into a question that could be investigated within the limits of a small research project.
There is a considerable difference between saying you want to use machine learning to study neurological diseases and identifying a specific problem, a dataset, measurable outcomes, and a method that could realistically address it.
The former describes an area I am interested in. The latter begins to describe a research project.
That distinction shaped the direction I eventually took.
From a Broad Interest to a Specific Problem
My proposal developed around evaluating automated brain MRI segmentation tools using clinical MRI data from Nigeria.
Brain MRI segmentation involves identifying and separating structures or tissue classes within magnetic resonance images. Automated tools can help perform this task, but their outputs depend on the images being processed and the methods used.
I became interested in what happens when these tools are applied to heterogeneous clinical data, particularly data acquired using different scanners and imaging protocols.
The project led me to the Nigerian Clinical-MRI dataset published by Wogu and colleagues in 2025. The dataset contains scans from 88 participants, including controls and people with dementia or Parkinson’s disease, collected across three Nigerian diagnostic centres.
This gave me something more concrete than a general interest in machine learning and brain health: an existing dataset, a specific computational task, and a question about how reliably automated tools could process the available images.
My working topic became “Evaluating the Robustness of Automated Brain MRI Segmentation Tools on Heterogeneous Nigerian Clinical Data.”
Getting to that point required me to think more carefully about the relationship between the problem I wanted to investigate and the evidence I could realistically collect.
Get tinkerwkoko’s stories in your inbox
Join Medium for free to get updates from this writer.
For example, evaluating whether a tool processes images successfully is not the same as proving that its segmentation is anatomically accurate. The latter requires an appropriate reference against which the results can be assessed.
That distinction affects what a study can claim, which measurements are appropriate, and how its findings should be interpreted.
Writing the Proposal Was a Different Challenge
Once I had a topic, I needed to develop it into a proposal.
This meant working through the research questions, identifying relevant literature, defining the proposed methodology, considering the data available, and deciding what the study would actually measure.
I also had to think about feasibility. Which tools would I compare? Which scans would be suitable? What would count as a processing failure? How would I compare outputs from different tools? What could I conclude without having reference tissue segmentations?
These questions forced me to examine the project at a much more practical level.
A proposal can sound convincing while leaving important details unresolved. It is possible to describe an ambitious study without explaining how its objectives will be achieved or whether the available data can support the conclusions.
I did not want to produce something that merely sounded like research. I wanted a proposal for a project I could eventually implement and defend.
That meant being willing to narrow the scope, question my assumptions, and distinguish between what I hoped to investigate and what my proposed methods could genuinely establish.
The Proposal Was Not Approved
My initial proposal was not approved.
I would be lying if I said that was the outcome I wanted. I had spent time developing the idea, thinking through the problem, and trying to turn my interests into something concrete. Having it rejected meant there was still work to do.
But it also made the purpose of the assignment clearer.
I could not treat the proposal as finished simply because I had chosen a good topic and written several sections around it. The proposal needed enough specificity for someone else to understand exactly what I intended to investigate, how I planned to do it, and what the expected output would be.
An interesting research direction is a starting point, not a substitute for a well-developed methodology.
I had to revisit the work, examine where it lacked detail, and make the research design more explicit. That included being clearer about the dataset, the tools to be compared, the definitions of success and failure, the characteristics to investigate, and the limitations of the proposed analysis.
I also had to resist the temptation to make the project sound more impressive by expanding its scope. Adding more tools or promising to establish more than the available evidence could support would not necessarily make the research stronger.
Sometimes, the better decision is to do less, but define it properly.
The goal is not to make a proposal sound ambitious. It is to make the proposed work credible.
What I Took Away From Weeks 4 and 5
These two weeks changed how I think about approaching a technical problem.
In programming, I can often begin with a defined task and work towards a solution. Research requires me to spend more time establishing what the task should be in the first place.
I have to understand the problem before deciding how to solve it. I have to examine what others have already done before claiming that something needs to be investigated. I have to choose methods that match the question, and I have to acknowledge when the available evidence cannot support a particular conclusion.
I also learned that research is iterative. A proposal can go through several rounds of refinement before it is ready, and feedback is part of that process. Rejection does not automatically mean the underlying idea is worthless, just as an interesting idea does not automatically mean the proposal is sound.
For me, one of the most valuable parts of this assignment was having to connect an area I genuinely care about with a specific, manageable technical problem.
I am still working towards a proposal that is both scientifically defensible and feasible to implement. There are implementation details I need to verify before I can confidently move from the written methodology to the actual analysis.
That is part of the process too. I would rather identify those uncertainties now than build an entire project around assumptions I have not tested.
Weeks 4 and 5 were a reminder that data science involves more than learning programming languages, applying algorithms, or building models. Before any of those things, there is a problem to understand and a question worth asking.
I have a lot more to learn about research, but I now have a clearer picture of what it takes to turn an interest into an investigation.
And that is what I am taking into the next stage of DataraFlow.
