Project Proposal
The project proposal must clearly define what is to be designed, define the project objectives (i.e., specifications or functional requirements of the end result), and identify the initial plan for the problem solution
Basically the Project Proposal consists of a design specification and a management plan.
The specification is an itemized list of functional capabilities or hard specifications for the project, which delineate the performance requirements you intend to meet. In the case of software projects, a software requirements specification and a software flow chart (or similar documentation) must be provided. These requirements will be used later in the project as a means of validating or demonstrating successful completion of the project.
The management plan is a detailed description of tasks graphically (i.e., Gantt chart) showing the relationship of each task to other tasks. The task detail should be to the lowest practical level of comprehension. For example, it is not adequate to simply provide a bar labeled as design. You should break this down into specific tasks such as design parser, design oscillator, research background, perform circuit or software testing, etc. A detailed breakdown of tasks to be done is required. Take your time to prepare a good management plan as an updated plan will be expected in your Oral Project Reviews, your Design Reviews, your Interim and Final Report, and your final Oral Presentation.
E-mail your project proposal to Prof. Merat and Gura.
Executive Summary
This should be the first page of your Project Proposal and will be completely separate from the rest of your proposal. Write this as if you were describing your project to the Department Chair or Dean in two to three paragraphs. You should be sure to state the goal of your project, why it is important, and what it is expected to do when completed. It should be e-mailed independently of your project proposal.
Title Page
You should list the title of the project, the project team (indicate the initial team leader), the project technical advisor,the class for which this proposal is being submitted, and the date.
This section must include a statement of the problem that you plan to solve. Typically, this will be given to you by your technical advisor or sponsor. If you propose your own project there must still be a problem statement. If there is no problem there is no reason to do any work! The problem statement is to be followed by a short discussion of how you propose to solve the problem and what will have been produced by the end of the project. The items to be produced must include the things that you expect to hand to your technical advisor. These are the deliverables. This could include a piece of hardware or a computer program. You must also discuss the design aspects of the project.
1.2. Project Specifications
One of the most important things in the real world is for the designer and customer to agree upon what the product should do. This is important to verify that the designer has properly completed the design and eliminates many disagreements between the designed and the customer. For the purposes of your project these specification are probably somewhat vague at this point and will become much more concrete as you work with your technical advisor.Your final technical specifications upon which your project will be graded will be included in your Interim Technical Report due at mid-semester.
The proposal must include a preliminary list of any functional requirements or hard specifications that can be determined through discussions with your advisor. This includes for example the accuracy, sensitivity, longevity, cost, etc. for the product. This is VERY IMPORTANT and must be specific. They must be somewhat challenging, but don’t get carried away. Remember, you have a finite length of time in which to complete the project.
A detailed requirements statement should be provided. This section is one of the most important parts of the project definition. It shall delineate all functional requirements for the deliverables and any specifications that can be defined. For hardware projects, specific specifications are necessary. For software projects, a software requirements list and modularized flow chart is required.
1.3. Strategy for Achieving Objectives
What do you need to do. Describe any investigation of prior work, design of solution, prototyping, testing, final product.
1.4. Verification and/or Testing
This section goes hand in hand with Section 1.2. For each specification described in Section 1.2 you should describe how you will know that your project meets this requirements. It is not enough for an engineer to say that it works — an engineer should be able to say that it works to specification.
A specific task shall be included in the detailed plan showing how project validation or verification to original requirements will be carried out. It is not sufficient to just indicate validation as a task bar. Rather a specific approach to the proof of the project completion is required. Software projects shall have a software test description to be used as the validation instrument.
2.1. Team Complement
Team members should be identified with their contributing roles. An initial team leader should be identified. The team leader will be responsible to organize the individual tasks, see that the task plan is implemented and orchestrate the preparation of the reports.
2.2. Project Management Plan
A detailed implementation plan is required showing a set of tasks broken down to their lowest reasonable level. Include your ongoing reports as a task item. Intermediate tasks of major significance are known as milestones. Milestones must be quantifiable so that you know when you have reached them, e.g., a completed circuit design or software flow-chart. The implementation plan must be presented using a suitable software package such as Microsoft Project or equivalent, which permits a detailed task listing with updateable bars (Gantt Chart) showing start and finish dates. Some tasks will be performed concurrently as is usually the case in a team environment. The tasks should have some form of legend identifying the team member performing them. This chart will be used in the weekly reports and in the periodic project reviews to track progress.
2.3. Budget
Your best estimate (at this time) of what the project will cost.
Download a copy of the evaluation form that will be used to grade your proposal.
Download a short project proposal similar to that described above.