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.

A preliminary proposal may be requested in advance of the final deadline to allow officers to plan for the year.

Proposal Contents

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

Year Long Objectives

To define objectives for the year, the proposal should have what will be referred to here on out as an objectives pyramid. The objectives pyramid is described below.

The Objectives Pyramid

Objectives Statement

To define year long objectives, a single sentence, hereafter referred to as objectives statement, should be written to concisely define the focus of the project in the coming year. The sentence should not be self explanatory; terms should be defined and qualified as footnotes. The objectives statement should be focused on changes in approach from year to year. An objectives statement should not be a statement of intention to design and build robots for competition (except in the unlikely case of a new subteam appearing), but how the approach to designing and building robots is changing relative to the past year of the project. This sentence is at the top of the objectives pyramid, as the goals expressed in the objectives sentence must be supported by all work done as a part of the team.

Subteam Objectives

From there, subteam objectives, hereafter referred to as subteam objectives, ideally as bullet points, should be defined. Each subjective should support the overall goals of the objectives statement. Objectives should have a clear scope, and a set of actions that need to be taken to successfully complete the subteam objectives in the coming year.

Tasks

The actions that need to be taken to complete the subjectives become tasks. A task refers to the set of tasks required to successfully complete its associated subjective. Tasks are then to be divied up among groups of members according to the difficulty and required skills of each task. Who partakes in which task is not required on the proposal, but a rough number of people and the required skills to complete each task should be indicated. The tasks are the bottom of the objectives pyramid. If the tasks are completed and designed correctly, they work to accomplish the overall goal of the year, I.E., the objectives statement.

Long Term Objectives

The plan should encompass goals for each year in the next three. Unlike the previous section the goals here do not need to planned out but should be achievable within that time frame. The important question that should arise is how to ensure that a consistent overall vision is passed down between generations. You should be including the younger members on your team in these plans as likely you will not be around to see them completed. These goals can be anything from team trainings to advanced technical goals. If you are looking to spend large amounts of money in the future for technical tasks please include that. This gives time to develop sponsorships and gives you more money to buy expensive things in the future. In the past there is no carry over between years of goals, the intention is this section will resolve that.

Bad Examples:

1. "Improve team specific training" - This is a meaningless statement. Improve in what way? This does not give any useful information of what needs to be done moving forward.
2. "Increase new member exposure to actual robots by adding additional outside of meetings times to only run robots" - This is a good goal. It should go in the short term objectives section. This can be accomplished as written in less than a year.
3. "Buy a really nice lidar" - There is a complete failure to develop the need for this sensor. Give more explanation as to why it would be useful. Also this does not allow for developing sponsorships since it does not answer who could give us these lidars at a reduced price. A list of prospective companies would make this good.

Good Examples:

1. "Establish new member training for each sub-team" - A good training program can take years of tweaking to become effective.
2. "Implement XX to improve motion control" - Even better would be to give a short reason as to why XX will improve motion control but technical goals that may take years are good.

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.

Milestones can be tasks, parts of tasks, or the completion of important work supporting a task, such as repairing robots. 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 SCC provide 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), when registration is due (expected if not known), when registration money is due (expected if not known), and expected cost for registration and travel. Do not forget to account for gas, rental car fees, flights, hotels,

See Budgeting for Travel and Travel Policy for information on what RoboJackets will pay for and how to accurately plan expenses.

In addition the proposal should state the anticipated cost for travel per member. This number should include lodging, but not food. 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.

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)

New Member Projects

How to incorporate new members into years of development when they lack experience is the hardest task for new leaders each year. Walking the fine line between instructive and useful is challenging. If a new member project is presented as something that will never be useful then they will have no motivation to complete it and will often quit. If the project is way beyond their experience they will feel as though they should know more and will quit out of fear. The ideal new member project is one that is non-critical to a successful competition, highly instructive, specific, visual, provides ownership for the new member, will be on the actual robot or useful, works closely with a more experienced member, and overall makes them want to keep coming to RoboJackets. These objectives often conflict with each other, the focus should be on building a better team when it comes to new members. For this section you must list at least one new member task per sub-team. Keep in mind that you will not retain every new member, make assumptions that they want to stick around and learn. Focus on the members that you keep rather than the ones that you lose.

Bad Examples:

1. "Fix computer vision" - You are giving the impression that they must fix computer vision. This is not practical and will not happen. More specificity and an experienced member assisting would make this project good.
2. "Manufacture part X to be used on the robot" - Teaching a new member to manufacture a part is good, but here there is potential for a lack on context on why the part is useful, why it works they way that is does. Favor design work with new members when possible.

Good Examples:

1. "Implement GUI to display robot state" - This requires a full knowledge of relevant state variables and where to get them from. Once complete this new member should have an overview of what comes from where and what it should look like.
2. "Use machine learning to detect XX" - If your team has a high focus on machine learning or wants to experiment with it this is a good goal. Giving a new member a chance to work with the existing tech stack or to create one is admirable. Be careful to have an experienced member assisting.

Budget

The budget contains details on the cost to build the robot and should provide as much detail as possible. An example of sufficient detail are cost for metal for the frame. Its understood that teams may not know what their final design will look like (for example which motor they will go with). Careful study of the market and the competition though can go a long way in determining what a maximum cost would be for an item. For RoboJackets, surpluses are okay, deficits are impossible since we can't operate in debt. Ask a core officer for assistance if you are lost. SGA budgets are formed by heavily condensing budget proposals. Capital outlays (items that will last three or more years) should be listed on the teams budget as they require purchasing, but should be listed in a Capital Outlays Section. Please anticipate costs for shipping in your line items so the amount you have after submitting a PO and after receiving it will reflect shipping.

Supplemental Documentation

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

How funding works

In the past project budgets were set at the beginning of the year with the entire budget for each team be allocated in one step. Since 2009 teams will have their budgets allocated in phases based on development the milestones they have specified. Not all milestones define a separate phase though but all phases will culminate with some milestone. It is required that teams at least have a design and and build phase with the milestone for the design phase being a successful design review. The design review shall be arranged by the team leader, the officers, and interested parties. Interested parties shall include all parties recognized by the officers and team leaders. Design reviews must happen at least at the initial design completion of a major project component (ie, drive system, main board, overall wiring plan, etc).

Milestones and Partial Completion

Milestones for projects are the milestones and the final travel deadline. Completion of a milestone will be defined by the milestone itself. Partial completion of milestones will be defined by the officers and other interested parties with the input of the team leader. The travel deadline is set as the date in the spring semester by which all travel plans are finalized including, who is going, deposits from members, any paperwork from Tech, and hotels and flights booked. Leniency is given for extenuating circumstances only.

Penalties

Failure to meet a milestone will result in the team losing out on additional funding until they have either completed the milestone or made satisfactory progress towards the milestone. Satisfactory progress will be defined by the officers and other parties in with input from the team leader and will take into account external factors such as vendor related issues.

Changes

Changes can be made to any deadline, pending officer approval. The criteria for approval are:

• Time until deadline in question
• Progress made
• External factors

Changes should be made well before the deadline in question will be missed. Problems such as 11th hour vendor issues or broken hardware are better served by partial completion instead of change requests.

Changes vs. Partial Completion

It is understood that problems will arise along the way (Robotics is still very much a research field). As such, team leaders have several options when their projects come into unexpected problems. Change requests are best suited for bigger problems that can't be solved by simply moving the deadline back a few weeks. Examples include problems obtaining long lead (3+ weeks) items, inability to complete an objective, and changes to the competition. For problems that can be easily solved partial completion is better. The idea is that if a team has been worked hard to meet a deadline but hits a snafu, no additional stress is placed on the members by having to continue to work to meet a new deadline.

Authority

The authority to approve funding rest solely with the officers. Team leaders and interested parties can offer input but can not make decisions regarding funding. Funding decisions are approved with a unanimous vote by the officers. This authority is not dictated in the constitution but has been standard operating procedure.

In general the officers can only enforce the milestones and objectives that the team leader defines. Even in the event of a change request the officers can only approve or dis-approve changes that the team leaders comes up with. Under normal circumstances officers cannot create objectives, milestones, or otherwise guide a team. Any officer on a team, on matters of team objectives and milestones, is subject to the decisions of the team leader. The only applicable events in which an officer can have any leadership of a team is:

1. if appointed by a team leader,
2. if there are no members to take lead of project,
3. or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question.