On Proposing Research Ideas
I spent the last month assisting my advisors on writing an NSF research proposal. It was one of my most exhausting and educational experiences ever.
It all happened slowly through some random tasks I got assigned. Some tasks seemed trivial and even useless at the time, but it all made sense when we worked on the complete proposal draft. It started with writing a "brain dump" of all ideas we have been iterating over the past 4-6 months. Then, it got interesting.
The Interesting Platform (Motivation, use cases, existing problems)
The brain dumb is often too technical as I spent time going through related work and defining interesting problems, what people are working on, and where I stand in all of that. This all does not cut it unless there is a clear use case. A scenario where all proposed research ideas are employed to make something "cool" happen.
The idea of how such use cases look like went through several phases:
1) When I started working on the project and I had a cool idea that I wanted to realize.
2) When I started digging deep into that cool idea to define how it is currently built.
3) When I surfaced back from the details to scratch parts of the use case already addressed by related work, ideas that are just way too complex, and ideas that are not really interesting. Then, I realized that the use case I had was no longer appealing
4) Finally, I was able to articulate a use case where novel research is required and where that research is applied to make cool things happen
One mistake I made was to think that by having that use case I had an interesting problem ...
The Challenge (why not "just" build it)
A very naive question when you present a use case is "why can't I just hire a bunch of engineers to develop this?". The answer to that question is basically what makes the use case an introduction to a good research statement. In this phase, I had to define what are the "clear" challenges in building a system that helps with the proposed use case.
In this phase, my advisors asked me to identify key points that I believe helped A LOT make the problem and why it is challenging much clearer in my head. These points included: identifying tradeoffs, identifying a baseline (some approach that is clear, easy, and works poorly), and metrics of success. Going through the exercise of coming up with these points helped me form a holistic set of challenges that need addressing for the use case to work.
So far, no specific research problems have been identified in the proposal ...
The Devil is in the Detail
A proposal should have clear tasks that, when executed, can make the presented use case a reality.
The identified challenges are appealing to motivate research in the direction of realizing the presented use case and the different applications that such use cases imply. However, challenges are not clear nor thorough enough to motivate an agency to fund a proposal. Moreover, the proposal has work that will typically take multiple years to realize. Hence, the exercise for this phase was to break down the identified challenges into different research problems.
I tried to break down a solution for the use case into layers and components. For each layer and component, I identified sub-components and challenges to be addressed to make each component and layer work. I also tried to make the different problems as generic as possible to avoid having dependencies between the appeal of the different problems.
I decided to go with the layered architecture as it better suited my problem. Within each layer I identified a set of challenges and possible approaches to solve it. From that point, more focus was dedicated to the related work of the individual problems and how we can solve them.
But this is just the proposal ...
No Devil will pay you for useless specifics
A lesson learned during the different phases of writing the proposal is that: a proposal should have enough details to show that the problem is interesting, we know what we are talking about, and that we have ideas to how to solve it. Yet, a proposal should avoid going into too much detail that the problem appear solved or that it's just wasting precious space in the proposal. There is also a fine line between being clear about what the problems of interest are and making them seem obvious and easy to solve.
But what will you do if you got the money tomorrow ...
Start Already!
This part is particularly tricky. In the proposal, there should be enough details to motivate every research problem without going too deep into mere conjectures. Yet, there should be a clear to do list for one or too tasks where it should be clear in the text that we are aware of how we are proceeding with them.
To that end, my advisors asked me to identify a set of tasks that I would work on if the fund was granted now. Having that in mind, writing about the tasks, the baselines, and the possible direction much more concrete than just suggestions and ideas.
But most of it are in reality just ideas ...
Papers v.s. Proposals
This is were the difference between writing a paper and writing a proposal is most clear. In a paper, you write to make what you did most clear and try to match your writing to your implementation and approach. In a proposal, the emphasis is more on clarity of the approach. In other words, the writing of the proposed approach can be simplified and tweaked to make it simpler.
Another distinction is that the idea of a paper can be very specific, guided based on related work, and "standalone". A proposal is a story with several interesting, and potentially standalone, problems that needs addressing to make that story a reality. Hence, you can think easily of an idea for a paper based on thorough knowledge of related work and the state-of-the-art, yet, a proposal requires more crafting, deeper understanding, and much grander story.
Final remarks:
In a typical proposal, you want to motivate the funding agency to give you, and you specifically, that money to solve that problem. This can, and should, be highlighted in many ways including:
It all happened slowly through some random tasks I got assigned. Some tasks seemed trivial and even useless at the time, but it all made sense when we worked on the complete proposal draft. It started with writing a "brain dump" of all ideas we have been iterating over the past 4-6 months. Then, it got interesting.
The Interesting Platform (Motivation, use cases, existing problems)
The brain dumb is often too technical as I spent time going through related work and defining interesting problems, what people are working on, and where I stand in all of that. This all does not cut it unless there is a clear use case. A scenario where all proposed research ideas are employed to make something "cool" happen.
The idea of how such use cases look like went through several phases:
1) When I started working on the project and I had a cool idea that I wanted to realize.
2) When I started digging deep into that cool idea to define how it is currently built.
3) When I surfaced back from the details to scratch parts of the use case already addressed by related work, ideas that are just way too complex, and ideas that are not really interesting. Then, I realized that the use case I had was no longer appealing
4) Finally, I was able to articulate a use case where novel research is required and where that research is applied to make cool things happen
One mistake I made was to think that by having that use case I had an interesting problem ...
The Challenge (why not "just" build it)
A very naive question when you present a use case is "why can't I just hire a bunch of engineers to develop this?". The answer to that question is basically what makes the use case an introduction to a good research statement. In this phase, I had to define what are the "clear" challenges in building a system that helps with the proposed use case.
In this phase, my advisors asked me to identify key points that I believe helped A LOT make the problem and why it is challenging much clearer in my head. These points included: identifying tradeoffs, identifying a baseline (some approach that is clear, easy, and works poorly), and metrics of success. Going through the exercise of coming up with these points helped me form a holistic set of challenges that need addressing for the use case to work.
So far, no specific research problems have been identified in the proposal ...
The Devil is in the Detail
A proposal should have clear tasks that, when executed, can make the presented use case a reality.
The identified challenges are appealing to motivate research in the direction of realizing the presented use case and the different applications that such use cases imply. However, challenges are not clear nor thorough enough to motivate an agency to fund a proposal. Moreover, the proposal has work that will typically take multiple years to realize. Hence, the exercise for this phase was to break down the identified challenges into different research problems.
I tried to break down a solution for the use case into layers and components. For each layer and component, I identified sub-components and challenges to be addressed to make each component and layer work. I also tried to make the different problems as generic as possible to avoid having dependencies between the appeal of the different problems.
I decided to go with the layered architecture as it better suited my problem. Within each layer I identified a set of challenges and possible approaches to solve it. From that point, more focus was dedicated to the related work of the individual problems and how we can solve them.
But this is just the proposal ...
No Devil will pay you for useless specifics
A lesson learned during the different phases of writing the proposal is that: a proposal should have enough details to show that the problem is interesting, we know what we are talking about, and that we have ideas to how to solve it. Yet, a proposal should avoid going into too much detail that the problem appear solved or that it's just wasting precious space in the proposal. There is also a fine line between being clear about what the problems of interest are and making them seem obvious and easy to solve.
But what will you do if you got the money tomorrow ...
Start Already!
This part is particularly tricky. In the proposal, there should be enough details to motivate every research problem without going too deep into mere conjectures. Yet, there should be a clear to do list for one or too tasks where it should be clear in the text that we are aware of how we are proceeding with them.
To that end, my advisors asked me to identify a set of tasks that I would work on if the fund was granted now. Having that in mind, writing about the tasks, the baselines, and the possible direction much more concrete than just suggestions and ideas.
But most of it are in reality just ideas ...
Papers v.s. Proposals
This is were the difference between writing a paper and writing a proposal is most clear. In a paper, you write to make what you did most clear and try to match your writing to your implementation and approach. In a proposal, the emphasis is more on clarity of the approach. In other words, the writing of the proposed approach can be simplified and tweaked to make it simpler.
Another distinction is that the idea of a paper can be very specific, guided based on related work, and "standalone". A proposal is a story with several interesting, and potentially standalone, problems that needs addressing to make that story a reality. Hence, you can think easily of an idea for a paper based on thorough knowledge of related work and the state-of-the-art, yet, a proposal requires more crafting, deeper understanding, and much grander story.
Final remarks:
In a typical proposal, you want to motivate the funding agency to give you, and you specifically, that money to solve that problem. This can, and should, be highlighted in many ways including:
- Previous achievements and experience with related problems including publications and summary of findings.
- Preliminary results pertaining to the proposed problem and initial findings on solving one of its subtasks.
- Facilities available in your institution and any other enabling factors that make you standout.
Is shooting at personal drones flying over your house OK?
ReplyDeletephantom 4 travel case