Can Veteran Teams post tips on ensuring that they are ON SCHEDULE!

[EricH]

Email loop, brown paper, and a CVS. Most team documents find their way to the CVS. The brown paper is for team meetings--What needs doing, who's doing it, completed or not. Throw in meeting every night and that's about it.

[Bongle]

Another idea for scheduling is to do it NASA-style with built in holds.

Say:
Day 1-13: Design Robot
Day 14-15: Build in hold
Day 16-20: Drivetrain
Day 21-22: Hold
Day 23-40: Drivetrain testing, gamepiece construction
41-42: Hold

This way, a single setback doesn't carry through and ruin the rest of your schedule. It gets absorbed in the buffer.

[meaubry]

There is some really great advice posted so far for you to consider, much of which we do also.
The thing you need to try and understand though is that "on schedule" can have as many different meanings as there are teams.
To be "on schedule" you first must have a "schedule" - what I mean is that even though we are all given 6 weeks to complete a task, it doesn't mean that there is a single one best schedule to accomplish it.
Why? Because each team has to first decide what it is that they wnat to do, in that 6 weeks.
Build a robot - you say.
Okay, to do what? Drive around? Shift gears? Climb ramps? go sideways? Just that one element alone could take teams all 6 weeks.
I will tell you what I have found important ,relative to the 6 week design and build time frame, is this.
1) Start brainstorming on day one (kickoff) but, set a time limit - we call ours D5 day (Design Decision Drop Dead Date). That is targetted for day 4 or 5.

2) Use the Divide and Conquer concept - much like others have indicated, break up the robot into sub-systems and allocate resources and set targets to make sure you do not exceed weight, size, and cost limits.

3) Set a target date for drive train chassis rough completion - test the drive system to validate it does what you thought it would (after a few years of experience this can be pushed up in the schedule, once you are using "tried and true" chassis and drive systems that worked well in previous years).

4) Set a target date for completing all other subsystems - including weekly target weight verification and re-allocation

5) Try to give the programmers as much time with the real machine as possible - this will depend on how well you stick to your schedule.

6) Nothing is more important than "drive time" for the drivers to learn just what the robot is capable of doing and how to get the most out of it. Try to set aside the last week for this. Yes, this means forcing the robot to be built in 5 - NOT 6 weeks.

Remember that there isn't one "best" schedule - the best schdule is the one that your team creates to achieve what ever goals that it sets for your own team.

I'd also like to add that it is best to keep things simple - including the schedule - don't list every little thing on the schedule itself. Create a seperate "task" list for that.

Sorry about the length of the post - I hope it helps,
Coach Mike - Team 47

[technoL]

For the first time we have incorporated the use of a gantt chart into our team. They are great because they display tasks to be accomplished, the time duration of the tasks, and then progress, so you can see all in one chart if you are on schedule and what needs to be done next. Each object in the chart is color coded and dependent of other objects preceding it. There are some programs out there to create fancier gantt charts, but one can be generated quickly with excel.

You can also use a gantt chart for long or short term task to be completed, such as for an individual subteam, the whole 6 week build season, for the whole year, or just combine them all into one massive chart.

I like to use gantt charts because you don't have to know exactly what you want to do when creating the initial chart, but you can simply see that you should be a certain point along by a certain point in time, and they can be further detailed as time goes on. Its nice to be able to show the team the day of kickoff exactly what needs to be done and when, even though we haven't the slightest idea of what our robot will look like.

**One downside of the gantt chart, as with any scheduling system, is that you cannot compensate for all possible setbacks, but as a general scheduling tip, if you add extra time for mishaps or setbacks, it won't be as difficult to pull it all together in the end.

PM if you would like to see some samples that I have created.

[waialua359]

I think deciding on what type of drive system (prototype) you want can more or less be created with very little or no revisions once kickoff starts.
For example, look at the cheesypoofs drive system, team 254. How many years has it been where their basic drivetrain and chassis is the "same."
That alone saved us two weeks so far in rebuilding our actual DT and allowed us to finish our basic robot already at this point.
Last year, because we couldnt decide what we wanted during the build season, we barely finished with zero drivetime for our students.
That certainly showed at our regional and the driving got better at championships.

[65_Xero_Huskie]

Hehe, we always go with the same plan.

Week 1 : brainstorm
Week 2-6 Build

We dont really have a set schedule, just that we build the drive and the controls ASAP.

[Brian C]

We have found that we like to fall behind in our schedule early as it gives us more time to play "catch-up" ;-)

[waialua359]

that's pretty funny!!!!
We used to like to play like that also every year in the past.