The goal of a project proposal is to determine the scope of a project and whether the team should take it on. Before work can start on a project its proposal must be accepted.
Project proposals take the form of a 1-2 page document that outlines:
Background and Motivation - Why is this a valuable project to work on?
Explain any background information required to understand why this project is important, and show why you are motivated to work on it.
Project Description, Requirements and Scope - What is the work involved in the project?
In broad strokes, go over what is being designed / built / done for the project (remember no specific design work yet). Also define preliminary requirements that the resulting design must meet. Try to make requirements concrete and justify them (“make the requirements less dumb”). Comment on what is within the scope of the project, but also what is out of scope.
Required Documentation - What documents are required for this project to be called “complete”?
A project isn’t complete without documentation. Figuring out what documentation to write ahead of time will greatly reduce the burden of writing it, so it is important to put some thought into this section. Start by picking out which types of Common Documentation are applicable to this project, but don’t limit yourself to documents on that list.
Deliverables Timeline - When do you expect to complete milestones, tests, and documentation?
The deliverables timeline is the most important part of a project proposal. Having a detailed timeline with concrete deadlines is crucial to staying on top of a project’s progress. Having deadlines to work towards helps drive projects forward and project managers will be using this timeline to determine if a project needs more support.
Take this time to determine development milestones (when various phases of design / manufacturing are complete), and plan out what tests the project will require. Also include dates for when various parts of the required documentation should be written by. The more deliverables you can make into tests the better, since we know this team works best when there is a test coming up and we can’t afford to fall behind schedule.
Remember to add lots of margin to your timelines for when stuff goes wrong, a common rule in software development is to double your internal estimate (see: Hofstadter's law).
Cost Analysis - What is the projected cost of the project? What sponsorship opportunities are there?
Try to estimate how much funding the project will require. Also think about what might be able to be sponsored and what companies we should reach out to.
Integration Concerns and Stakeholders - What other systems will this project affect / be affected by?
Think about what sort of dependencies this project has on other projects or systems. This can be a high-level list, but consider what may affect this project’s design and timelines and conversely what this project may affect. Also note down people who need to know about the design and any future changes to it.