Difference between revisions of "Proposals"
(→Procedure for Submission) |
(Updated to current standards. Removed Submission instructions, so this doc will not need to be updated each year.) |
||
| Line 1: | Line 1: | ||
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. | 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. | |
| − | A preliminary proposal may be | + | |
| + | = 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. | 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== | + | |
| − | ===Objectives=== | + | == Project Description == |
| + | |||
| + | === Objectives === | ||
| + | |||
The project's objectives should be carefully considered as they will guide the planning of the project. Clear, concise objectives help keep a team focused without pulling the development in too many directions at once. Abstract, far reaching objectives are discouraged as they are hard to fully satisfy and give the team no clear direction. The best objectives focus in on each aspect of the project, and provide detail about what the expectations, such as performance and ease of use, will be for those aspects. Finally, the objectives shouldn't enumerate specific tasks. There should be at least 1 primary objective and 2 secondary objectives. Secondary objectives are defined as something that if not met will not prevent the project from failing to compete. | The project's objectives should be carefully considered as they will guide the planning of the project. Clear, concise objectives help keep a team focused without pulling the development in too many directions at once. Abstract, far reaching objectives are discouraged as they are hard to fully satisfy and give the team no clear direction. The best objectives focus in on each aspect of the project, and provide detail about what the expectations, such as performance and ease of use, will be for those aspects. Finally, the objectives shouldn't enumerate specific tasks. There should be at least 1 primary objective and 2 secondary objectives. Secondary objectives are defined as something that if not met will not prevent the project from failing to compete. | ||
| − | ====Bad Examples:==== | + | ==== Bad Examples: ==== |
| − | # "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. | + | |
| − | # "Fix the code for estimating position" - This sounds more like a bug fix or a to-do list than an objective. | + | #"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. |
| − | # "Design a manipulator for the science task" - While this is specific it really is just a re-hash of the competition objectives. | + | #"Fix the code for estimating position" - This sounds more like a bug fix or a to-do list than an objective. |
| + | #"Design a manipulator for the science task" - While this is specific it really is just a re-hash of the competition objectives. | ||
| + | |||
| + | ==== Good Examples: ==== | ||
| − | + | #"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. | |
| − | # "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. | + | #"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. |
| − | # "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. | + | #This one can go two ways: |
| − | # 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. | ##"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. | ||
| − | ## "Design a manipulator that penetrate six inches of earth for the science task and has minimal size and power requirements" - Much better. Everything is spelled out and the objectives for the manipulator, though general are given. One can use this objective to really guide a design. | + | ##"Design a manipulator that penetrate six inches of earth for the science task and has minimal size and power requirements" - Much better. Everything is spelled out and the objectives for the manipulator, though general are given. One can use this objective to really guide a design. |
| + | |||
| + | === 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 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. | ||
| Line 29: | Line 37: | ||
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 | 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==== | + | ==== 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 | + | *Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task |
| − | * Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector, | + | *After fall break - Demo at least 2 new prototype drive-trains |
| − | * Feb 1st - Demo new manipulator using individual joint control | + | *Week before dead week - Prototype - Demo new drive-train in tele-op driving, successfully acquire data from sensors, demo a new end-effector, |
| − | * March 1st - Extended range driving | + | *Feb 1st - Demo new manipulator using individual joint control |
| − | * Spring Break - Demo some of the competition tasks using the manipulator | + | *March 1st - Extended range driving |
| − | * April 30th - Finalize travel plans, demo robot performing some competition objectives | + | *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. | 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==== | + | ==== 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. | 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==== | + | ==== 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. | 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==== | + | ==== Capital Outlays/Tooling ==== |
| − | While our shop and | + | |
| + | 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), and expected cost for registration and travel. Per the internal travel policy, RoboJackets will only cover the following | 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. | + | *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 | + | *Accomodations for cheaper trips as funding allows. |
| − | * Luggage for the robot | + | *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 and entertainment. Example: Ponchos |
| − | * Shipping for the robot | + | *Luggage for the robot |
| − | * Fees - Excess baggage, duties, | + | *Shipping for the robot |
| + | *Fees - Excess baggage, duties, etc. | ||
| + | |||
| + | No trips will be completely free for members. For cheaper trips, a payment of $30-$60 per person is appropriate to ensure that they will attend the trip. Historically, people would sign up for free trips and drop out at the last minute, leaving many unused competition registrations and empty seats in rental vehicles. | ||
In addition the proposal should state the anticipated cost for travel per member. This number should include hotel and possibly food, especially if you are going overseas. It should be based on a projected number of attendees. | In addition the proposal should state the anticipated cost for travel per member. This number should include hotel and possibly food, especially if you are going overseas. It should be based on a projected number of attendees. | ||
| − | |||
| − | |||
| − | 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) | + | === Schedule === |
| − | ===Budget=== | + | |
| − | The budget contains details on the cost to build the robot and should provide | + | 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) | ||
| + | |||
| + | === 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 along 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. Look at a prior budget proposal for an example. SGA budgets are formed by heavily condensing budget proposals. Capital outlays (items that can reasonably get more than a year of use) 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. | ||
| + | |||
| + | === Supplemental Documentation === | ||
| − | |||
Any documentation that the team leader feels is required in addition to the above | Any documentation that the team leader feels is required in addition to the above | ||
| − | ==How funding works== | + | == How funding works == |
| − | ==='''Important'''=== | + | |
| + | === '''Important''' === | ||
| + | |||
=== Overview === | === Overview === | ||
| + | |||
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 once a month or at the initial design completion of a major project component (ie, drive system, main board, overall wiring plan, etc). | 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 once a month or at the initial design completion of a major project component (ie, drive system, main board, overall wiring plan, etc). | ||
| − | ===Milestones and Partial Completion=== | + | === 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. | + | |
| + | 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. | ||
=== Penalities === | === Penalities === | ||
| + | |||
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. | 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 === |
| − | Changes can be made to any deadline pending officer approval. The criteria for approval are: | + | |
| + | Changes can be made to any deadline, pending officer approval. The criteria for approval are: | ||
| − | * Time | + | *Time until deadline in question |
| − | * Progress made | + | *Progress made |
| − | * External factors | + | *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 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 === | === 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 | + | |
| + | 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 === | === Authority === | ||
| − | The authority to approve funding rest solely with the officers. Team leaders | + | |
| + | 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: | 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: | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | #if appointed by a team leader, | |
| − | + | #if there are no members to take lead of project, | |
| + | #or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question. | ||
Revision as of 16:45, 22 June 2016
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
Objectives
The project's objectives should be carefully considered as they will guide the planning of the project. Clear, concise objectives help keep a team focused without pulling the development in too many directions at once. Abstract, far reaching objectives are discouraged as they are hard to fully satisfy and give the team no clear direction. The best objectives focus in on each aspect of the project, and provide detail about what the expectations, such as performance and ease of use, will be for those aspects. Finally, the objectives shouldn't enumerate specific tasks. There should be at least 1 primary objective and 2 secondary objectives. Secondary objectives are defined as something that if not met will not prevent the project from failing to compete.
Bad Examples:
- "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.
- "Fix the code for estimating position" - This sounds more like a bug fix or a to-do list than an objective.
- "Design a manipulator for the science task" - While this is specific it really is just a re-hash of the competition objectives.
Good Examples:
- "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.
- "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.
- 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.
- "Design a manipulator that penetrate six inches of earth for the science task and has minimal size and power requirements" - Much better. Everything is spelled out and the objectives for the manipulator, though general are given. One can use this objective to really guide a design.
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. 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 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), 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.
- Accomodations for cheaper trips as funding allows.
- 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 and entertainment. Example: Ponchos
- Luggage for the robot
- Shipping for the robot
- Fees - Excess baggage, duties, etc.
No trips will be completely free for members. For cheaper trips, a payment of $30-$60 per person is appropriate to ensure that they will attend the trip. Historically, people would sign up for free trips and drop out at the last minute, leaving many unused competition registrations and empty seats in rental vehicles.
In addition the proposal should state the anticipated cost for travel per member. 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.
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 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 along 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. Look at a prior budget proposal for an example. SGA budgets are formed by heavily condensing budget proposals. Capital outlays (items that can reasonably get more than a year of use) 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.
Supplemental Documentation
Any documentation that the team leader feels is required in addition to the above
How funding works
Important
Overview
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 once a month or 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.
Penalities
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:
- if appointed by a team leader,
- if there are no members to take lead of project,
- or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question.
