Proposals - Revision history

Jspalten6 at 03:05, 21 August 2018

2018-08-21T03:05:51Z

Jspalten6 at 19:32, 15 August 2018

2018-08-15T19:32:23Z

Jspalten6 at 19:29, 15 August 2018

2018-08-15T19:29:35Z

Jspalten6 at 03:35, 15 August 2018

2018-08-15T03:35:36Z

Jspalten6 at 03:34, 15 August 2018

2018-08-15T03:34:34Z

Jspalten6 at 02:10, 14 August 2018

2018-08-14T02:10:59Z

Jspalten6 at 02:08, 14 August 2018

2018-08-14T02:08:05Z

Jspalten6 at 01:39, 14 August 2018

2018-08-14T01:39:10Z

Jspalten6 at 02:01, 10 August 2018

2018-08-10T02:01:56Z

Jspalten6 at 01:47, 10 August 2018

2018-08-10T01:47:24Z

@@ Line 77: / Line 77: @@
 === 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 capital outlays/tooling and Travel/Registration.
 ==== Capital Outlays/Tooling ====

@@ Line 41: / Line 41: @@
 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, milestones should immediately follow their corresponding tasks in the proposal.
+To more easily see connections between tasks and milestones, the list of milestones should be grouped with the subteam objectives and tasks.
 ===== Milestones Example =====

@@ Line 35: / Line 35: @@
 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.
@@ Line 41: / Line 41: @@
 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.
-==== Milestones Example ====
+To more easily see connections between tasks and milestones, milestones should immediately follow their corresponding tasks in the proposal.
 *Sept 15th 2009 - Fix the all the things broken at competition last year and demonstrate the old rover completing some of the task

@@ Line 79: / Line 79: @@
 ==== 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 it is requesting. This information will be helpful for the officers in budget defenses for the club and when dealing with potential sponsors.
 ==== Personnel ====
@@ Line 108: / Line 108: @@
 #"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 ===

← Older revision		Revision as of 03:34, 15 August 2018
Line 96:		Line 96:

	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.		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 ===		=== New Member Projects ===

@@ Line 25: / Line 25: @@
 ==== Subteam Objective Statements ====
-From there, subteam objective statements should be defined. Subteam objective statements are objectives statements on a subteam level. 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.
+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.

@@ Line 15: / Line 15: @@
 === 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_0.1.png | thumb | right | 600px | The Objectives Pyramid]]
+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 ====

@@ Line 17: / Line 17: @@
 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_0.1.png | thumb | right | 600px | The Objectives Pyramid]]
-==== Objectives Statement ====
+==== Objective Statements ====
-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 desired changes and improvements 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 desired improvements in 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.
+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.
-==== Example ====
+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.
-#Maintaining or improving management, technical, and human resources
+==== Subteam Objective Statements ====
-==== Subteam Objective Statement ====
+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 level.
+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 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 ===

@@ Line 38: / Line 38: @@
 ==== Tasks ====
-The actions that need to be taken to complete the subteam objectives become tasks. A task refers to the set of tasks 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 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. 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 level.
+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 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. 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 level.
 Tasks are the first time where implementation should enter a proposal.