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

[waialua359]

I would like to start by saying, for our team, the kickoff starts at the beginning of the school year!

[newton418]

In pervious years we've consistently faced setbacks which have thrown our schedule off. One thing that has almost always killed us is weight. Another, the electronics, since most of the members usually think they can just be thrown on in a matter of minutes.

Last year we really emphasized a weight chart. There's a big blackboard in our shop, divided into different assemblies of the robot. In each row, individual parts are listed with their weight in parentheses. On the right there is a total for each assembly. Keeping up with this has allowed us to make hard decisions sooner rather than later, when we've had to. It also keeps everyone thinking about how to reduce weight.

This year our team went from ~20 to over 30 students. With so many students we decided we needed to improve communication and figure out how to effectively train the new kids (about half the team), while still ensuring we get everything done on time. To accomplish this we've divided the team into eight sub teams (such as drive train, manipulator, ramps, field build, CADD, etc.). Each sub team has a captain, and there is an overall project manager.

Every week, each captain emails the project manager a "status report" listing everything that was accomplished that week. Each captain is also required to email a "weekly goals" sheet, listing out every little thing they expect to accomplish. This has had several effects. First of all, since our team only has one technical mentor and one coach, it has specified who is responsible when things don't get done. Since nobody wants to be the one holding the team back, each captain has done everything in his/her power to stay on track. Secondly, the specific list of goals has made each captain realize how much there is to do, and has allowed them to effectively divide the work.

In addition to these lists, every other day the project manager has called a "stand in" meeting with all the captains. It's a quick 10 minute meeting where, standing up, each captain quickly states what their team has accomplished, and what they will do in the next couple of days. This allows all the captains to have an idea of how everything is going overall, and gives each captain a little while to stop thinking about their specific tasks and think about how they have been, and should, lead their team. It has also improved communication, especially when one team is waiting on another for a specific part.

The project manager has also made an effort to go around to each team, ask them how they've been doing, and make sure every team has everything they need. It's easy to put something off, but a little comment about how you're waiting for this or that will get the project manager on the job, doing what he can to keep everything running smoothly.

This overall structure has proven very effective for our team this year. I remember my freshman year we were proud of the idea that we were a team of leaders; since then the team has grown so much that communication was becoming an issue, and this has allowed us to cope with the wave of newcomers.

[Dan Petrovic]

We have something we call "The Wall". It's 3 boards that get hung on the wall during the day and it has all of the tasks that need to be finished, when they need to be finished by, and who is doing them. Also, we create a list of what people are doing at the beginning of every day. This is so we know that everyone has a job.

A lot of things, however, can cause setbacks. You can never really assume your schedule will be perfect. This year, the manipulator took a bit of testing, now with the new BB carrier plate problems, that will slow things down a bit as well.

We also have periodic reviews to make sure certain sub-groups are getting their things done on time.

[Jared Russell]

We have a private team forum (much like this one, but only for our team members and VIPs) on our site. Throughout build, it is updated several times daily by any and all members. This way, not only can you keep track of what's happening, you also make sure that people on different parts of the team know what everyone else is doing.

Plus, having who is supposed to do what online for all to see is a great motivator! When you are held personally accountable for a project, then 9 times out of 10 it gets done on time.

[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.