Proposals

From RoboJackets Wiki
Revision as of 16:11, 28 June 2009 by Marksp (talk | contribs)
Jump to navigation Jump to search

Proposals serves two purposes: To inform the officers and the club about the plans of each project and to help team leaders in their project planning. It is comprised of a description of the project objectives for the new year, a schedule, and a budget. Generally, the proposals are due to the officers by the beginning of the school year. Final budget amounts are then determined and announced in the subsequent weeks.

Preliminary Proposal

An impromptu preliminary proposal maybe asked of the team leaders when the officers need information for planing purposes before the proposal deadline. These preliminary proposals can range from an item on a meeting agenda to a small worksheet or questionnaire. They are not binding and are strictly for pre-planning purposes.

Prior Results

A short description (one to two paragraphs) of what went right and what went wrong in the previous year. Serves as in introduction to proposal.

Project Description

The project description is the heart of the proposal and contains the objectives, the milestones for reaching those goals, the resources that will be needed, and any travel plans.

Objectives

The project's objectives should be carefully considered as they will guide the planning of the project from the proposal on. The best objectives are ones that give one a good idea of what is being planned for the year and gets members excited. They are specific enough that they can be handed-off to a team without many changes, but aren't so specific that they look more like a to-do list. Most importantly, the objectives should reflect that some high-level design decisions have already been made. These sort of decisions actually

Bad Examples:

  1. "To be competitive relative to the current field" - Too broad and not clearly defined. There is no indication of what capabilities are considered competitive in the field and if a team needs to implement all of them.
  2. "Fix the code for estimating position" - This sounds more like a bug fix or a to-do list than an objective. There is nothing new here and unless this one fix will take an entire semester its not worth noting in a proposal.
  3. "Design a manipulator for the science task" - While this is specific it really is just a re-hash of the competition objectives.

Good Examples:

  1. "Gain a competitive advantage by building a rotary based weapon" - Like the above objective the goal of being competitive is clearly conveyed and in addition details are given as to what ways the team will be competitive. Note that the objective is specific enough that the type of weapon is given but general enough that further details are omitted. Also note that the team already at this point has an idea of what type of robot is going to be built instead of starting from a clean slate.
  2. "Train new members by having them fix some of Glados's simpler problems" - This objective is more general and it achieves a much bigger goal in terms of training. A team leader should be careful in choosing this goal though, as it indicates that they will need to allocate time and resources to training, time that could be spent on new systems for Glados.
  3. This one can go two ways:
    • "Define the objectives for and build a manipulator for the science task" - Not the best objective but at least its this shows that there has been some thought on this objective.
    • "Evaluate two prototype manipulators for the science task in the fall" - Much better. Instead of there being endless discussion on designs, this objective shows that two real prototypes will be designed and evaluated.

Descibes:

  • Goals and Objectives
    • Attempts should be made to limit the goals in scope and number
    • The officers will look to see that the project is possible and make recommendations
    • Team leader and officers sign-off on goals and objectives
    • Team leaders should inform officers of any new changes, such as reducing or removing a goal, or adding a new one at the officer meetings
    • Officers should be expected to give feedback on any changes and make further recommendations
    • Team advisors will also have a say in objectives and goals
  • Milestones
    • Project milestones are required for all projects
    • This section should contain a description of each milestone
    • Milestone scope should be appropriate for amount of time; this means accounting for build and debug time
    • Milestone should be easily demonstrable.
    • At the very least there must be a milestone for prototype or first revision by the end of fall semester, and the start of testing by the end of spring semester. The reason is for demo days
    • Additional milestones are heavily encouraged
    • Penalties for missing milestones
    • Can be changed up until the milestone deadline pending officer approval
    • Approval will be granted based on proximity to existing deadline, outside circumstances (ex:issues with vendor, or personel) and if the deadline is achievable
    • If changes are not approved then the original deadline stands along with penalties for missing it.
    • Team advisors will have say in milestones and are expected to attend all demonstrations
  • Resources
    • Indicate what resources will be needed
      • Monetary - overview of the attached budget
      • Personnel - Skills needed (ex: ME with CAD experience, CS with interest in vision, Mgmt to organize)
      • Capital Outlays/Tools - Describe what tools you'd like and why. Anything that last more than a year
  • Travel/Registration
    • Registration cost
    • Preliminary travel plan
      • Full plans will be submitted before the end of the spring semester
    • Location
    • Expected cost
    • Hotel, food, sigh-seeing, anything not for the project are not covered! See travel policy
    • Will cover transportation, gas, materials (Luggage, travel tools and kits), and fees (Luggage fees, shipping, customs)
    • Will also cover any incidentals needed for the robot, First Aid,
    • Would also like anticipated cost per member to travel (Hotel, food, etc) This is based on an expected number of attendance
    • Travel plans can change
    • Major penalties for not turning in full travel plans by end of spring semester

Schedule

Budget

Supplemental Documentation

Deadlines

Penalties

Procedure for Submittal

What is the procedure

  • Contains
    • Four sections detailed above
    • Budget is two parts. Adjusted budget for the this fiscal year, and new budget for the next one
    • Preliminary proposal worksheets due by the 1st week of school
    • Full proposals due on the date of the 1st general meeting at 11:59pm
    • E-mailed to President and hard copies submitted to President
    • No spending on new budgets until budget is approved by the officers
    • Penalties for missing deadlines
    • Formating Guidelines
      • 12pt Font, double spaced, one side only
      • Sections clearly indicated
      • Budget must be in excel format
      • Gnome Planner is preferred format for schedule (You can get it here:http://live.gnome.org/Planner)
      • Failure to meet these basic guidelines will result in a re-submittal. For any re-submittal the team leader is still responsible for meeting the deadline. So its better to turn them in early then to wait till the last minute.
      • Once proposals are all in the budget process can begin
      • Officers will also review each proposal with the Team leader and provide feedback or request clarification
      • Budgets and recommendations will be delivered to the Team leaders as promptly as possible (deadline depends on when officers get proposals)