Team schedule

I am wondering how other teams have created schedules for build and how much time they usually allocate for certain parts (design, manufacturing, code)

2 Likes

This was last year’s schedule.

We do try to start code on sort of a parallel path so that we are ready when handed off.

We also had some practice milestones and stuff for media/awards. We didn’t make everything on time, but it is helpful to lay something out to aim towards.

You can sort of see when you compete and work backwards to see how much time. Some things like time to have parts ordered and delivered must be considered. If you can stagger in what to work on you can avoid too much a slow down waiting for parts.

We try to build sooner than later, but some might want more CAD done. We wanted to practice sooner this last year, but had more build experience, so we may have to adjust expectations some. We also look at how we are meeting and what days are best for major decisions, so that more can be there for them.

But again we don’t strictly follow the schedule and have to sometimes change, drop practice, or add more work time, etc.

2 Likes

To be honest, if you’re looking to make a schedule, looking at other team’s schedules might not be very helpful. You might be able to pick some events off another team’s schedule, but when you want to get those done is all about your teams goal, abilities, competition schedule etc. I would start be trying to create a schedule of what your team did last year picking our important milestones, then tweaking that schedule to align with your goals for the upcoming season.

We build 2-3 robots per season (not all complete robots), we do all fab in-house so that CAD can release a system and we can immediately start build a software while CAD goes on to the next system. A few years ago we had to outsource all CNC work so our schedule revolved around deadlines for sending batches of parts to the laser. Anything can make a huge difference in your scheduling so start by understanding what you already do, then try to improve on it.

1 Like

We do M-W-Sa

It’s probably not enough time but it is as much as I am willing to do as a mentor, my drive being the biggest reason for that. 1hr 15m each way

Once it comes down to crunch time, we will have optional meetings to help make more progress. Last year we stuck to our schedule pretty decent and had a lot of good driving practice before W1 comp

Of course, we’re always looking to improve

1 Like

My team just did this today. I like the method we used.

We started by listing all the things that needed to be done to get a robot competition ready. For us, this was: Manufacturing & Assembly, Wiring, Programming, Design, and Driver Practice.

We then sorted them based on a quality we called “time elasticity”, which describes how flexible the time commitment we want to plan for for that section would be. For example, to us, our #1 priority for this coming season is getting driver practice, so when making our schedule, we want to do everything we can to prioritize getting however many weeks of driver practice we desire. The higher an item is on the elasticity list, the less we can modify the time requirements we set for it. The lower it is, the more malleable it is.

We then set an ideal amount of time for each item on the list. Obviously the ideal amount of time is infinite, but we tried to base it off of how much work we reasonably expect in a season, with the unspoken rule of no one item getting more than 2-3 weeks worth of time. From here, we start putting the items into the schedule at the points where they’d fit in in the order of our time elasticity list from highest to lowest. For us, this started with drive practice, and we moved down our list from there.

Now at this point, more often than not, you begin to realize your ideal time schedule does not fit within the time you have between kickoff and your first competition, at which point for us we went back to our list and re-evaluated the “ideal” times to fit the schedule better, starting adjustments from the bottom of the time elasticity list and moving up. At the end, we were left with a schedule containing each action item in chronological order, and a comparison of the “ideal” amount of time we would put into an item and the real amount of time we ended up allocating. One of the important takeaways for our team after balancing the schedule was that for the items we removed time from, we were also telling ourselves to remove complexity and functionality. While we could not point to specifics, removing half a week from design, for example, told us to limit the scope of the robot design in-season by about half a week’s worth of work. Removing some time from manufacturing set the requirement of using less custom components. We made it clear that giving ourselves less time meant that we were removing functionality from the robot, not removing the time we had to get the same amount of work done.

While this schedule isn’t perfect, it reflects our priorities going into build season and will serve as a guide on kickoff for determining our robot scope.

2 Likes

our team goes with a gantt chart. We met M-Th + Sat/Sun last year. Here’s our timeline if you’d want to take a look at it. It was a little bit scuffed last year so we’re hoping to get a more accurate + efficient schedule for this year – Build Season Timeline '22 - Google Sheets

Our schedule is:
Monday thru Friday 1630 to 2030
Saturday 0900 to 1700
The first week is prototyping. Week two through whenever is build. Programming parallels build.
We have a white board where we keep post-its of what needs to be done. Once an item is done, it is moved to another part of the board.

I like Gannt charts because they give the team a sense of when something should be finished.

I also like to create a chart working backwards, starting with when do you want the robot finished and listing the steps which doesn’t have to be detailed.

The reverse order would be:

Drive team practice
Programming
Electrical
Build
Fabrication
CAD
Prototyping

The other thing to note is that a project very rarely exactly follows the schedule. Some things get done faster and other things take longer. It’s when things take longer you have to come up with a recovery plan and hope you don’t go to your first competition without any drive team practice.

Like I said in my earlier post, I don’t think copying another team’s time line is a good idea as every team operates differently. But we set a bunch of deadlines on a big calendar on the wall, when we make the deadline it gets a smiley face when we miss, it gets a sad face and if we miss by more than a day or two we cut the scope of the robot.

Our deadlines are when a CAD, Build, or Software completes a system to the point that goes to the next subteam. For our team we assume the systems are: drivebase, intake, shooting/placement, climb/endgame, other game element. We adjust exactly what systems we schedule for after kickoff, and each system gets deadlines for CAD, Build, and Software. Initially deadlines are for a practice/prototype robot, and additional deadlines are made for the competition robot as well as reveal video and any mid season upgrades.

We run 25-30 hours a week with 3 technical sub teams and so we need a lot of deadlines to make sure we are on track and no one starts procrastinating because they have 2 weeks before their next deadline. A team that meets less often and builds simpler robots wouldn’t need nearly as many deadlines. A team with a lot of student crossover between subteams wouldn’t be able to parallel track systems in the same way we do, and a team with more students than us might be able to run multiple systems in parallel within each subteam releasing multiple systems at once. If you send out batches of parts to be cut once a week that will affect your schedule versus teams who do everything in house. My advice to anyone making a build season schedule is to make a schedule of what happened last year with important milestones and use that as a starting point for the year to come.

If I am not mistaken, this means @Andrew_L chose to design a less complicated and less capable robot and/or found simpler ways to implement the robot functions.

1 Like

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.