Proposals

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 the proposal.

Project Description

The project description is the heart of the proposal and contains the objectives, the milestones for reaching those objectives, 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. Most likely these sort of decisions may have already been made at competition or in a previous year. In any case making them before the first team meeting makes it easier to get members on the ground and running with a design, which helps towards retention. Also, objectives should be tangible. Abstract objectives generally don't get implemented as no ones knows what they are. Finally, efforts should be made to limit the scope and number of objectives.

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. Without that how does one go about implementing it?
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.

Milestones

The milestones are a means of demonstrating progress to the officers, the advisers, sponsors, and the campus as a whole. They also give members a clear sense of where the team is headed and provide motivation. They should be easily demonstrable and realistic without pushing back dates. A good milestone is one that members will prepare for with the same vigor as the actual competition deadline.

The project description should clearly describe what each milestone is, and a date. Milestones can be an objective, parts of several objectives, or the completion of a set of small task such as repairing the robot. Milestones shouldn't be vague objectives such as 'working robots' or 'be ready for competition.' Like objectives some specifics should be given.

At the very least the officers would like to see a milestone for a prototype/rev 1 sometime in the late fall, and a milestone for testing in the late spring. Beyond that milestones for sub-systems are a good place to start. Below is an example of a good set of milestones for a Mars Rover themed competition

Milestones Example

• Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task
• After fall break - Demo at least 2 new prototype drive-trains
• Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector,
• Feb 1st - Demo new manipulator using individual joint control
• March 1st - Extended range driving
• Spring Break - Demo some of the competition tasks using the manipulator
• April 30th - Finalize travel plans, demo robot performing some competition objectives

Resources

Every team will need resources to complete their project and the proposal is where teams indicate what will be needed to successful complete the project. Resources are broken down into monetary, personnel and capital outlays/tooling.

Monetary

This is mainly covered in the budget but the proposal should contain a few words on why the team needs the items its requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.

Personnel

Team leaders should indicate the number of people they feel they will need to be successful and their skill sets. Since we are mostly undergrads skill sets roughly means interest.

Capital Outlays/Tooling

While our shop and the Tin building provides an abundance of tools, team leaders may find that certain items are not available. There may also be large equipment purchases that the robots will need. In both cases those items should be listed here. Team leaders should also consider what resources will be needed to manufacture parts and should list those resources here.

Travel/Registration

In the proposal teams should indicate what competition they are going to, what dates the competition is held (or at least a rough idea of when those dates are known), and expected cost for registration and travel. Per the internal travel policy, RoboJackets will only cover the following

• Transportation - Gas at the SGA mileage rate, plane, train, or bus tickets, and rental vehicles.
• Incidentals - Materials for competition, items for the robot, First Aid, anything that would be of use to every member of the team for the purposes of competition except, food, hotel, and entertainment. Example: Ponchos
• Luggage for the robot
• Shipping for the robot
• Fees - Excess baggage, duties,

In addition the proposal should state the anticipated cost for travel. This number should include hotel and possibly food, especially if you are going overseas. It should be based on a projected number of attendees.

Schedule

The schedule should detail what phases of the project the team will be working on throughout the year. These phases are derived from the objectives and the milestones and should be broken up by subsystem. A phase called design would not be a good choice as subsystem design times vary and can't all be lumped into one. If at all possible teams should be involved in multiple task according to subsystem and personnel. For example a software team could be working re-building the system architecture while a mechanical team builds a simple base.

There are no formatting rules for the schedule other than it be a separate page and look similar to a Gantt chart. Gnome Planner is preferred though.(You can get it here:http://live.gnome.org/Planner)

Budget

The budget contains details on the cost to build the robot and should provide sufficient detail. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final desing will look like (for example which motor they will go with). Carefully study the market and the competition then, to determine what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. For an example see the 2009-2010 SGA budget. Capital outlays (items that can reasonably get more than a year of use) shouldn't be on the budget.

Supplemental Documentation

Any documentation that the team leader feels is required in addition to the above

Deadlines and Penalties

Proposed

In years past teams have found it hard to meet self imposed deadlines, resulting in lopsided development schedules. In addition, member retention has been an issue as new members often leave during lulls in the development, indicating that 'not much was going'. To address these concerns and to help the club be more successful in its endeavors, there are new rules regarding milestones. If a team misses a milestone that team's leader must be prepared to meet with the officers and the team's adviser to discuss plans moving forward. If a team leader fails or objects to attending such a meeting, their budget will be frozen until such a meeting takes place. Furthermore, any travel arrangements will be effectively put on hold and no new travel plans can be made. If a team remains in this state of limbo for significant time the officers will taken further action including but not limited to the removal of the team leader per policy and possibly the disbandment of the team per the constitution.

Travel

Final travel plans include all members paid, all paperwork filled out. hotels and flights booked, and preliminary iternaries are up. Any no competition plans don't need to be ready at that time.

• 'Final travel plans for summer competitions' - 1 week before the end of the spring semester
• 'Final travel plans for any other competition or event' - One month out

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)