Anatomy of a project proposal

The project proposal is a critical document laying out the specification for a research project. It is the first deliverable in any research program, and will often be dynamically updated over the course of the project. It is likely to become a part of a future writeup / academic paper.

Big picture

Specific project scope

Create and include one or two graphics that capture and communicate the problem and proposed solution to technical but non-expert audiences.

Can you create a one or two sentence summary of the problem and the proposed solution approach?

Broader impact

In other words, even if someone doesn't care about the big picture problem that you started with, why should they still care about the specific work that you've produced? Who else can use your processes and results, and how?

Background / related work / references

Find external sources that support your framing of the research problem. In particular, you should establish your answers to all of the above questions using only material from other researchers.

You should also find additional sources that address:

Be sure to cite all potential sources, and summarize each one in terms of its content and relation to your project.

Capabilities, deliverables, tasks

Recursively break down the proposed project starting from the highest level specifications spanning the complete research period down to individual atomic steps spanning days to at most a week. At each level of hierarchy, specify:

Distill the entire hierarchy into a list of weekly or shorter milestones. What will you need to achieve by when in order to attain your objectives for the end of the project on time?

Keep in mind that these capabilities, deliverables, and tasks are all distinct characterizations of required research. Tasks are verbs that you as the engineer must fulfill. They are done in order to enable your engineered system to accomplish its desired capabilities. In order for your system to achieve a single capability, you may need to execute several subtasks; each of your subtasks may have required your system to have accomplished a sub-capability enabling an incremental update in its abilities. The collection of deliverables should be sufficient for someone who hasn't seen you working to certify that your capabilities have been met, and your system can in fact achieve the prescribed abilities. When generating deliverables, keep in mind that one data point does not indicate a trend, and appropriate statistical rigor should be applied to the presented results. Try to address counterfactuals, edge cases, and competing explanations in your deliverables.

As an example:

A bad example: