Difference between revisions of "Proposals"

From RoboJackets Wiki
Jump to navigation Jump to search
 
(62 intermediate revisions by 8 users not shown)
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.
  
−
==Preliminary Proposal==
+
A preliminary proposal may be requested in advance of the final deadline to allow officers to plan for the year.
−
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==
+
= Proposal Contents =
−
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:====
+
== Prior Results ==
−
# "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?
 
−
# "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.
 
−
# "Design a manipulator for the science task" - While this is specific it really is just a re-hash of the competition objectives.
 
  
−
====Good Examples:====
+
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. You should try to focus in on the question of why something failed. If the robot was unable to drive try to summarize why the issues occurred.
−
# "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.
+
Prior results should not have suggested solutions to the identified problems. Instead, it should focus on identifying problems and areas for improvement.
−
# 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.
+
== Project Description ==
−
* "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.
+
 
 +
=== 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. [[File:Objectives_Pyramid_Version_1.0.png | thumb | right | 600px | The Objectives Pyramid]]
 +
 
 +
==== Objective Statements ====
 +
 
 +
To define year long objectives, a few (3-4) short bullets, hereafter referred to as objective statements, should be written to concisely define the focus of the project in the coming year. The objective statements should be focused on desired changes and improvements in approach from year to year. An objective 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 desired improvements or changes to the approach to designing and building robots relative to the past year of the project. These objectives are at the top of the objectives pyramid, as the goals expressed in the objectives statements must be supported by all work done as a part of the team.
 +
 
 +
Each objective statement should have an associated justification. The justification explains ''why'' each objective statement is important, and, hence, why it is a goal. These justifications are for the benefit of both Core officers in understanding goals for the coming year, as well as for future generations of team leadership.
 +
 
 +
==== Subteam Objective Statements ====
 +
 
 +
From there, subteam objectives should be defined in the same format as the objective statements. Each subteam objective statement should support the overall goals of the objectives statements. A subteam objective statement should have a clear scope, a set of actions that need to be taken to successfully complete the subteam objectives in the coming year. Subteam objectives do not have to be based solely on the objectives statements, but should come from similar motivation.  
 +
 
 +
Like the objectives statement, a subteam objective statement should focus on desired outcomes, not implementation. Additionally, subteam objective statements should also have associated justifications, for the same reasons as the overall objective statements.
 +
 
 +
==== Tasks ====
 +
 
 +
The actions that need to be taken to complete the subteam objectives become tasks. A task refers to the set of actions required to successfully complete the objectives defined by the subteam objective statement. 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 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. Tasks should be on the order of a couple of months of work. For example redesign of a sub system could be a task. Tasks should be detailed enough to provide direction, but not so detailed to dictate tasks on a week-to-week or day-to-day level. 
 +
 
 +
Tasks are the first time where implementation should enter a proposal. Tasks should also have justifications, for the same reasons as objective statements and subteam objective statements. These justifications should identify the associated subteam objective, as well as explain the importance of the task.
 +
 
 +
==== Milestones ====
  
−
===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.
  
−
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.
+
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.' Specifics should be given. Milestones are the deliverable and the tasks are the action(s) that need to be taken in order to produce the milestone.
 +
 
 +
To more easily see connections between tasks and milestones, the list of milestones should be grouped with the subteam objectives and tasks.
 +
 
 +
===== 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
 +
 
 +
=== Goals For Next Year ===
 +
 
 +
Make a list of goals for the year after this one. Unlike the previous section the goals here do not need to planned out but should be reasonable within the time frame. Additionally If your team is looking to spend large amounts of money in the future for technical tasks please include that. These goals should address the issues that a team faces on the timescale of two years. What do we need to focus on now to aid us later.
 +
 
 +
==== Bad Examples: ====
 +
 
 +
#"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.
 +
#"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.
 +
 
 +
==== Good Examples: ====
 +
 
 +
#"Establish new member training for each sub-team" - A good training program can take years of tweaking to become effective.
 +
#"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.
 +
 
 +
=== Vision Characteristics ===
 +
 
 +
Write a bulleted list of characteristics that are not prevalent now that you would like to see in the future of the team. These do not need to be specific but should give a sense of the direction the team should be taking.
 +
 
 +
==== Examples: ====
 +
 
 +
#"Increasing visibility of what leadership does" - has the right time scale and does not get into implementation specifics.
 +
 
 +
=== 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 capital outlays/tooling and Travel/Registration.
 +
 
 +
==== 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.
 +
 
 +
=== 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: ====
 +
#"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.
 +
#"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: ====
 +
#"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.
 +
#"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.
 +
 
 +
== Changes ==
 +
 
 +
Changes can be made to any master schedule milestone, pending Vice President 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.
  
−
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
+
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. Working directly with the Vice President to keep the master schedule relevant is a good place to start. You should consider why the issue has occurred and realize that the master schedule is a living document that should be changed to reflect changing priorities or unforeseen roadblock, not a lack of effort.
  
−
* Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task
+
=== Authority ===
−
* Demo at least 2 new prototype drive-trains
 
−
* Prototype - Demo new drive-train in a tele-op driving. Successfully, acquire data from
 
  
−
Notice that in the above milestones there is no design milestone.
+
The authority to approve or pull 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.
  
−
===Resources===
+
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:
−
** 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===
+
#if appointed by a team leader,
−
===Budget===
+
#if there are no members to take lead of project,
−
===Supplemental Documentation===
+
#or if a project has repeatedly missed deadlines and is sufficiently behind schedule to the point where competition appearance may be in question.
−
==Deadlines==
 
−
===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
 
  
−
==Penalties==
+
[[Category: Core]]
−
==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)
 
−
==Changes==
 

Latest revision as of 23:05, 20 August 2018

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. You should try to focus in on the question of why something failed. If the robot was unable to drive try to summarize why the issues occurred.

Prior results should not have suggested solutions to the identified problems. Instead, it should focus on identifying problems and areas for improvement.

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

Objective Statements

To define year long objectives, a few (3-4) short bullets, hereafter referred to as objective statements, should be written to concisely define the focus of the project in the coming year. The objective statements should be focused on desired changes and improvements in approach from year to year. An objective 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 desired improvements or changes to the approach to designing and building robots relative to the past year of the project. These objectives are at the top of the objectives pyramid, as the goals expressed in the objectives statements must be supported by all work done as a part of the team.

Each objective statement should have an associated justification. The justification explains why each objective statement is important, and, hence, why it is a goal. These justifications are for the benefit of both Core officers in understanding goals for the coming year, as well as for future generations of team leadership.

Subteam Objective Statements

From there, subteam objectives should be defined in the same format as the objective statements. Each subteam objective statement should support the overall goals of the objectives statements. A subteam objective statement should have a clear scope, a set of actions that need to be taken to successfully complete the subteam objectives in the coming year. Subteam objectives do not have to be based solely on the objectives statements, but should come from similar motivation.

Like the objectives statement, a subteam objective statement should focus on desired outcomes, not implementation. Additionally, subteam objective statements should also have associated justifications, for the same reasons as the overall objective statements.

Tasks

The actions that need to be taken to complete the subteam objectives become tasks. A task refers to the set of actions required to successfully complete the objectives defined by the subteam objective statement. 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 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. Tasks should be on the order of a couple of months of work. For example redesign of a sub system could be a task. Tasks should be detailed enough to provide direction, but not so detailed to dictate tasks on a week-to-week or day-to-day level.

Tasks are the first time where implementation should enter a proposal. Tasks should also have justifications, for the same reasons as objective statements and subteam objective statements. These justifications should identify the associated subteam objective, as well as explain the importance of the task.

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.' Specifics should be given. Milestones are the deliverable and the tasks are the action(s) that need to be taken in order to produce the milestone.

To more easily see connections between tasks and milestones, the list of milestones should be grouped with the subteam objectives and tasks.

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

Goals For Next Year

Make a list of goals for the year after this one. Unlike the previous section the goals here do not need to planned out but should be reasonable within the time frame. Additionally If your team is looking to spend large amounts of money in the future for technical tasks please include that. These goals should address the issues that a team faces on the timescale of two years. What do we need to focus on now to aid us later.

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.

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.

Vision Characteristics

Write a bulleted list of characteristics that are not prevalent now that you would like to see in the future of the team. These do not need to be specific but should give a sense of the direction the team should be taking.

Examples:

  1. "Increasing visibility of what leadership does" - has the right time scale and does not get into implementation specifics.

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 capital outlays/tooling and Travel/Registration.

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.

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.

Changes

Changes can be made to any master schedule milestone, pending Vice President 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.

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. Working directly with the Vice President to keep the master schedule relevant is a good place to start. You should consider why the issue has occurred and realize that the master schedule is a living document that should be changed to reflect changing priorities or unforeseen roadblock, not a lack of effort.

Authority

The authority to approve or pull 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.
Retrieved from "https://wiki.robojackets.org/index.php?title=Proposals&oldid=16947"