Project Management and FIRST?

[crazykid234]

I have a question for any teams that have tried to implement some amount of project management during the six weeks:

Did you find it was worth the time to continually evaluate which portions of the robot were behind schedule and reassign people as needed, or did everyone just work really hard and it got done that way? I had an internship this past year where they used project management extensively and I'd like to try a similar system on 1646, but I worry that with our short schedule it's not worth the effort. Any thoughts?

[Phalanx]

Using project management during build season can be huge benefit to your team. You will see what areas are falling behind, who's lagging, who's dependent on who. Using Gant charts makes an excellent visual representation as well so everyone can see it, especially the time lines.

We have tried to teach project management so we can use it during build season for the reasons above. Unfortunately, most folks involved do not want to invest or spend the time to update their progress and tasks. This is especially true during build season when everyone is pressed for time.

If you can do it and accomplish it, then by all means do. It will be well worth it in the end. Additionally you will learn how and where to improve your teams efficiency, planning and scheduling, not only during build but even for other non build projects now and in the future.

My suggestion would be to assign a "Project Manager" who's job it is to gather the information and feedback from the others and keep the project management tool information up to date, since it is difficult to get the builders, etc.. to update it themselves.

This is how things get done in large organizations that require multiple teams and divisions to work independently and together to reach specific time constrained goals.

If you looking for an excellent open source project management tool check this one out. http://www.dotproject.net/

[David Brinza]

A least some form of "top-level" schedule should be put together before the kick-off. Perhaps you break the robot up into subsystems: chassis/drive train, electronics board, prototype manipulators, etc. and plan parallel work effort in these areas. If the chassis/drive gets done early, you can divert those students to the manipulators or some other portion that's lagging. There's also building of field elements, acquiring game pieces, putting the chairman's, Woodie Flower' awards together. Assigning people to these tasks, assessing progress and "redeploying" labor on a weekly basis is project management.

There's also budget to be managed - cost of spare parts, materials, tools, t-shirts, give-aways, travel,... Establishing the team's budget and making sure one or more of the cost elements isn't getting out of hand is important. That's part of project management too.

The SCRRF workshops held at CSUN in early-November had a very good session on project management given by Ian Cannon of Pratt-Whitney (formerly known as Rocketdyne, the builder's of rocket engines). His concluding remark was:

"Fail to plan and you can plan to fail!"

You don't need a super-detailed network schedule to build a robot that is tracked hour-by-hour, but you need something to gauge your progress. Otherwise, you may realize in the last week that you're in big trouble.

BTW at last night's team meeting our students (only 5 were there) were tasked with putting together the week-by-week top-level schedule. They finished it in an hour. It was only a half-page long, but it was adequate for a starting point. Students and mentors agreed it was a worthwhile exercise. Is it realistic and achievable? Perhaps the fact that the students created this will give them a sense of ownership and motivate them to "do what they said"!

[technoL]

We tried to implement Gantt charts last year, but eventually it was impossible to stay on track. Everything was planned out before the season started, and then the chart was adjusted and customized once we had a robot design (which ended up being a problem because the design was changed several times). It was rather effective up to week 3.

I have been thinking of ways to revise last year's organizational system to make sure that it will actually be effective. Some of my priorities are:
1. Cover all tasks according to level of significance
2. Assign people to specific tasks
3. Demonstrating progress/ show completed or unfinished tasks and percentage done
4. Make sure that the system is regularly updated and the team actually refers back to it

I think project management can work in FIRST and is worth the effort if it can be used effectively because it'll definitely make things run smoother. It requires dedication from the entire team, as it is too easy just to give it up and revert back to old methods. Evaluate your biggest challenge with organization during the season, and create a system that works for you from there.

[StephLee]

We had a Gant chart last year, but we ended up not looking at it after we made it. It was helpful for prioritizing since everyone knew which systems we were putting the most emphasis on, but we didn't stick to it very well.

What ends up happening on our team is, all the mentors and some of the students have individual mental timelines for when things should be finished; if things aren't getting finished, then someone talks to the group working on that system, or steps in and helps them if that's what's needed. It gets a little confusing, but I think last year's attempt at making an official chart plus the experiences of the previous two years helped keep us on track (somewhat).

[piper]

From a teacher/coach point of view, I consider project management one of the most important elements of the build season. We get a little bit better at it each year and have a designated Project Manager and Systems Engineer that handles these responsibilites. As a result of this increase in planning management our build season has lost the sense of panic and desperation that characterized our first couple years of involvement with FIRST. We've also gained some valuable skills and insights as to how it's really done in the real world. This year we'll utilize a gantt chart/design matrix and regular design reviews to make sure we are staying on track. It may seem that these are added extra things that take up more time, but believe me they end up saving hours in the end.

[EricH]

We do have a schedule. However, sometimes it isn't formalized. We decide early what we want to do during the match, then what to focus on. For example, last year, rings won out over ramps. We spent two to three weeks on a prototype that could have ramps added if needed. Once the kinks were being ironed out, we started on ramp design.

If something is coming along late, or we aren't sure it'll work, a "tiger team" will form to evaluate options and make a reserve decision. One of those was responsible for the decision to have ramps on the sides last year; then the engineers started doing the design.

In general, we know about where we should be at any given point, but we are somewhat flexible due to possible delays in parts arriving.

[Liz Smith]

There has been some great feedback of where teams have and have not had success with the implementation of project management. I think there are some important aspects of the original post which should be brought up.

I had an internship this past year where they used project management extensively...

Project management is used in many industries. I think that should play a part into the answer to your question. You utilized and maybe learned about project management in your internship, that knowledge could probably benefit some of the students on the team. Whether or not a strict schedule you create and update is followed during the build season, I think an introduction to project management could prove to be beneficial learning experience.

I worry that with our short schedule it's not worth the effort.

As brought up in previous posts, maybe a simplified schedule could be useful. With tools like Gantt Charts I think they can been a useful resource. In one of my engineering courses my freshman year in college I learned how to use MS Project. I introduced it to one of the teams I was helping with last summer. It was a completely new thing for them. They used them, at least in the beginning of the season and even though they weren't used religiously the team now knows what Gantt Charts are, how they work, how they can be useful, how to use them, and have knowledge they didn't have before. I think even just that makes it worth it.

[RyanCahoon]

Our team last year attempted to use a deadline system, but it was not formalized to enough detail, only including such coarse deadlines as drive-base finished, and so we still ran into the typical problem of programmers got 2 days to write their code. While I agree that too much red tape inhibits efficiency, some subdividing of the process is needed to be effective.

This year, the team has moved to using a wiki. While it doesn't have a defined structure, we've found it actually works better for our subteam leaders as they are able to create their own displays that are customized to their needs, while still staying simple to use. From there, it just becomes management issue for the mentors and upper leadership to make sure the leaders are keeping the wiki pages up to date.

--Ryan

[IndySam]

You have to have one person devoted to making sure needed tasks get accomplished and that the overall project stays on track. It’s the only way to manage a project and keep it on task. It’s amazing how much time can be wasted at the beginning of a meeting just trying to figure out what needs to be done.

Last year I kept it all in my head and I used a system of punch charts to show what needed to be accomplished. It was easy for the sub-team leaders and crews to look at these lists at see what work needed to be done. It worked well.

This year I’m going to use Gantt charts so people can see what’s rolling around in my head. I am going to require the student leaders to keep me posted on progress and this year we will produce the daily lists together. I am hoping that by the end of the second week the leaders are doing most of the work themselves. I think it’s going to be a great learning experience for us all.

[Tim Delles]

Hrmmm finally a discussion about my minor...

Project Management is a huge part of having a successful build season. With proper implementation and use of Management a robot can be designed, built, programmed, etc within the more strict timelines (im pretty sure that if this year Dean said you had to build a robot in 4 weeks instead of 6, we could all do it... and for some we could tell which teams had good management)

Did you find it was worth the time to continually evaluate which portions of the robot were behind schedule and reassign people as needed, or did everyone just work really hard and it got done that way?

Yes this is very mcuh worth your time. We have found that with good management you can go from the design (after everything has been designed, put into detailed drawings) to an actual robot in about 4 days... THIS IS NO JOKE.. With about 15 kids working on the robot for 5 hours a day (each one pre-assigned to fit there best skills) you have plenty of time as long as you have all other resources necessary. (we had about 4 kids laying out all the parts, about 9 machining, and 2 kids assembling)

Not only are we going to be making sure we have a Project Manager, we will also be having:

Layouts Head - This person is in charge of making sure there are detailed designs of all parts and that these designs are put on a story board for the manufacturers.

Manufacturing Head - This person is in charge of making sure parts are manufactured in a way that will increase productivity and decrease overall machining time

Assembly Head - This person oversees the entire assembly process. Works with the manufacturing head to make sure parts are made that are needed in the assembly of certain parts on specified days.

Project Manager - Responsible for the overall management of the Production Process in the Spring.

Let me know if you have any more questions

[ChrisH]

We tried to implement Gantt charts last year, but eventually it was impossible to stay on track. Everything was planned out before the season started, and then the chart was adjusted and customized once we had a robot design (which ended up being a problem because the design was changed several times).

Emphasis mine

There's your biggest problem right there. It is better to spend a few extra days figuring out what you REALLY want to build then go at it full bore, then to dance around trying to get one of three or four ideas to work.

We have learned that we can build a robot in two weeks or less IF we know exactly what we want to build. So we spend a lot of time prototyping and figuring out details before we start cutting metal. We actually build our practice robot first and apply the lessons learned to the "real" robot.

[Michael Sperber]

FRC is a case-study in Project Management.... it has a clearly defined goal (even multiple goals), a clearly defined budget, a clearly defined end date and a defined set of resources (facilities and people)... Everything that you need to have a successful project.

However, one of the most important things in managing and executing ANY project is not any of the things I touched on... The single most important thing that defines the success of ANY project is COMMUNICATION.

Good communication is not a guarantee of success, but bad communication is almost a guarantee of failure. (OK, a very strong statement, but I hope you understand what I am trying to say.)

No matter how you and your team choose to manage things, make sure everyone on the team buys into the process and communicate. In your communication, think of the following: clear, concise, open, frequent and honest.

-mike

[crazykid234]

wow, thanks everyone! This is way more response than I was hoping for, not to mention very positive responses! I'm very excited to see how the build season works out this year. On a side note, has anyone ever made a formal white paper laying out some kind of project management template specifically for FIRST teams? If nobody has before, I'd like to create one, I just don't want to duplicate somebody else's work.

Thanks again!

[Stephen Kowski]

I have a question for any teams that have tried to implement some amount of project management during the six weeks:

Did you find it was worth the time to continually evaluate which portions of the robot were behind schedule and reassign people as needed, or did everyone just work really hard and it got done that way? I had an internship this past year where they used project management extensively and I'd like to try a similar system on 1646, but I worry that with our short schedule it's not worth the effort. Any thoughts?

Normally I setup a schedule and try to keep up with it. This year we were only a day or two off, but everything turned out fine. Since we were doing a collaboration it was understood what group was working on what and there was no real need to reassign people.

I would say it is definitely worth it so you don't lose perspective on the big picture. Knowing you are behind in week two or three is HUGE!!! At that point you still have a good amount of time to fix it. If you didn't have a schedule you wouldn't know where you were time-wise.

Also, we used google spreadsheets to map out our timeline here: http://spreadsheets.google.com/pub?key=p_rQxpoP_xrcxlwnbQN-bJA (if you like it, feel free to pilfer, just let me know I'd love to see improvements)

Good luck I DEFINITELY think it helps!!

[Andrew Rudolph]

One huge thing thats hard for inexperience people and teams when pertaining to first is actually knowing weather or not your schedule is even doable. Its easy for a mechanical team member to say, oh yeah they need 1 day to program the robot, when in actuality they neeed much more.
Thats one of the reasons looking at other peoples schedules might not help, becuase say one team has 8 machinists who can make parts for them can fabricate a drivetrain in 2 days, as where a team with a jigsaw and dremel can't work that fast. With that said, our team is broken down into many subteams, each subteam has a knowledgable student or mentor incharge. That person reports back to the overall project manager. The PM is the one who keeps everyone moving in the right direction. Thankfully our team has been truely blessed with having one of the best PMs ever. Not everyone will be so lucky, the secret to his magic is that he takes the time to understand what everyone is doing and can help motivate the team and direct the team. A huge part of his sucess is that the team respects him. In our case he is a programmer, but when he comes over to the mechanical area, even if he has no idea what we are doing we respect his opinion in moving in the apropriate directions. With that said, pretty much all he does for the team is bounce around making sure things are working towards the same goal. We also have meetings often seeing what everyone else is doing in case anyone has an idea that can help with issues.

Finally, the biggest point that already has been brought up is its better (in our case, as with other teams) to spend an extra couple days early making finalized design decisions and making good drawings. This goes with much of my education in school, basically you draw it up, then build what you drew. Its pretty easy to make a mistake in the rush of things, "whats 1 + 2?....4 right, ok *****SZZZZZzzzzzaw*** oh my bad." it goes back to the old addage of measure twice cut once, if you have it in front of you, cut it 3" long, then you save alot of time and mistakes rather than just saying to someone, "ok make that thing" and point to a whiteboard drawing. It saves alot of headaches.

[Doug Leppard]

Key secret to 1902s last two years of success has been a loose but working project management.

I was so proud of the hardware guys, they committed to having hardware done by week 5 and held themselves to it. They put pressure on themselves to get it done on time even in the midst of some outside venders not delivering. They had a Gantt chart and followed it. See Stephen Kowski's post a few messages back (1369 partnered with 1902).

The programmers didn't wait until the bot was done and worked every week and all Saturdays to get proto types done. They had their goals and used Vex kits to work out a lot of the programming issues.

You can not afford with the 6 week schedule to do things serially, meaning complete hardware, then electrical then software then driving. They must work in parallel each getting things done so in the final weeks it comes together in a complete robotics system. This last year the robot base and arm were built in separate locations and done at the same time and then assembled together.

It is good to have someone that overlooks all of it and makes sure things are coordinated, needs not to be a master of any of the disciplines but have a feel for all of it. For if hardware is changed it may mean software must be change to adjust for it.

[David Brinza]

Key secret to 1902s last two years of success has been a loose but working project management.

<snip>

You can not afford with the 6 week schedule to do things serially, meaning complete hardware, then electrical then software then driving. They must work in parallel each getting things done so in the final weeks it comes together in a complete robotics system. This last year the robot base and arm were built in separate locations and done at the same time and then assembled together.

It is good to have someone that overlooks all of it and makes sure things are coordinated, needs not to be a master of any of the disciplines but have a feel for all of it. For if hardware is changed it may mean software must be change to adjust for it.Being able to build the "subsystems" (arm, base, electronics, etc,) separately and have them come together requires some good systems engineering practices. You can think of this as the technical part of project management. The interfaces between the various robot assemblies need to be correct (and understood) otherwise the final week can be miserable...

[Kyle]

Project Management in my opinion is a very important thing in FIRST. It teaches the students how to sit down and set up a plan then act upon it and when problems occur how to change the plan, just like in real life situations.
Check out MOE's MOEmentum page (http://www.fsrobotics.org/moe365//moementum.php) that is all about a time line and management during build season for rookie, or any team.

[Doug Leppard]

Being able to build the "subsystems" (arm, base, electronics, etc,) separately and have them come together requires some good systems engineering practices. You can think of this as the technical part of project management. The interfaces between the various robot assemblies need to be correct (and understood) otherwise the final week can be miserable...

It was a scary thing for the team, but it worked and was one of the reasons we made it to Einstein.

Let me say most of the work was done by high school students and college mentors.

What I have learned in FIRST managing the process, is the great wealth of knowledge there is in the college mentors many of whom have been in it for 10+ years. So it is coming up with a good plan and getting out of their way to implement it.

[Tom Bottiglieri]

Even if a team does not pursue a fully projected managed system, there are some valuable things that can be taken away from it.

1) Analysis of the Triple Constraint (Time vs. Cost vs. Scope) - There is probably nothing more important to do before jumping into design. This analysis will dictate almost everything about your build season. Rank what is the most important to you. This will dictate how the other 2 roll out. For example, our team has decided on a ranking of Time, Scope, Cost. The reason for this is we would rather have a completed robot that "does" a bit less, and we have a little fluff in our budget. This also forces simple design and allocating of time resources, something that might not be done if you are given free range over scope.

2) "Fluff" time - Always Always Always allow yourself a bit more time than what you initially expected. If you think manufacturing will take 2 weeks, allow yourself 2 weeks and 2 days. There are ALWAYS unforeseen problems that pop up.

3) Interteam trust - When working in a managed project, it is imperative that each team member delivers on time, or the project may be ruined. Therefore, team members must trust each other to deliver on time. It is not a one man show. If you spend all of your time looking over others, you will not get your own work done, and the team will go down.

[Doug Leppard]

Even if a team does not pursue a fully projected managed system, there are some valuable things that can be taken away from it.

1) Analysis of the Triple Constraint (Time vs. Cost vs. Scope)
2) "Fluff" time
3) Interteam trust

These are great points. Most teams try to do to much and often it is a one man or small group show.

Often the robot is seen as the hardware and so often the software people don't get time on it.

[Alan Anderson]

2) "Fluff" time - Always Always Always allow yourself a bit more time than what you initially expected. If you think manufacturing will take 2 weeks, allow yourself 2 weeks and 2 days. There are ALWAYS unforeseen problems that pop up.

If you explicitly pad the schedule and expect it to take 2 weeks and 2 days, it'll expand again and take 2 weeks and a half. Dealing with this apparent law of nature is difficult. Try fooling the schedule gremlin and officially allot only the original 2 weeks, while not starting anything else that depends on its being done until a couple of days afterward.

This represents the "fluff" as unscheduled time, so it looks bad from an efficiency point of view, but I think it's better than giving in to the urge to put running late on a task into the original schedule.

[Tom Bottiglieri]

If you explicitly pad the schedule and expect it to take 2 weeks and 2 days, it'll expand again and take 2 weeks and a half. Dealing with this apparent law of nature is difficult. Try fooling the schedule gremlin and officially allot only the original 2 weeks, while not starting anything else that depends on its being done until a couple of days afterward.

This represents the "fluff" as unscheduled time, so it looks bad from an efficiency point of view, but I think it's better than giving in to the urge to put running late on a task into the original schedule.
Of course. As Alan said, never publish that extra time per task is being given. Just schedule deadlines with this fact in the back of your mind. Obviously, the bigger the component, the longer it will take, and the more importance it holds to the overall completion of the project.

[Bomberofdoom]

I must say, as the CEO (Student Leader/captain/PM/etc.) of my team, I just find this topic unbelivablly resourceful to me.

This will be my first year as the CEO (if you take out the small issue we had that I was "charged" to be the CEO for the last days of build, and in the competition I was the robot driver, so I didn't really do any of the CEO works till now). I wanted to be the CEO because of many reasons, which some are following and related to other reasons...

I explored FIRST to a bigger extent and I explored my team's project that we were doing. I was interested in being invloved, in the team, in the company, knownig what's being done, when and how. I wanted to move the project forward as much as possible.

There are many things I don't know as a CEO, in the terms of the project knowledge: I was the head of programming last year and expect mabye for electricity, I didn't know much about how the other sub-teams worked. But I did my best last year to learn that, and I'm doing the same now, before the Kick off with some planned lectures for the all subteams.

Andrew's post gave me some motivation to not let those flaws hold me back.

I read everyone's post fully and carefully and use these tips to build the plan for my team.

Thanks for the posts and keep 'em coming. :)

[Doug Leppard]

I must say, as the CEO (Student Leader/captain/PM/etc.) of my team, I just find this topic unbelivablly resourceful to me.

Congratulations.

Another important point I forgot. Humility. Must stay humble throughout the whole process and listen to everyone. I don;t know how many kids communicated on chief delphi that they felt that those in charge didn;t listen.

Also be prepared to work out the human problems, the disagreements and such.

Summing up several items said here. Keep the design simple, well within your teams ability to deliver. We had a simple six wheel two speed transmission that was off the shelf and a simple arm, both we could build. And we worked on making sure it was dependable.

We have a whole series of suggestions for the game itself.

[Chris Fultz]

A few of the keys to successful Project Management are capturing / defining the requirements, agreeing the schedule, and communicating continually. And, someone has to be 'in charge' (ie project manager) and willing to push people to meet their agreed dates and technical performance.

If you define your robot requirements up front, taking 3 or 4 days to do this, then you will find it much easier to stick to a schedule. The schedule impact of making late changes to the design or capabilities is exponential to calandar time when the change is made - meaning changes in week one are easy to deal with, changes in week four are tougher to absorb.

Someone needs to be in charge to be sure the design doesn't suddenly change based on a single person's new / better idea and to make sure the team keeps progressing through the six weeks of build.

[Chris Fultz]

On a side note, has anyone ever made a formal white paper laying out some kind of project management template specifically for FIRST teams? If nobody has before, I'd like to create one, I just don't want to duplicate somebody else's work.

I did a presentation for the Purdue FIRST class in late 2006 about project management. I will find it and add it to the white papers.

[JaneYoung]

No matter how you and your team choose to manage things, make sure everyone on the team buys into the process and communicate. In your communication, think of the following: clear, concise, open, frequent and honest.


418 has been working with Project Management seriously for 2 years. It has shown a significant (understatement) increase in efficient use of time and resources. It is also a good system for students to learn, understand, and implement - training the new students as they enter the team.

One thing that I've noticed is that not all students 'get it' at the time they are going through the build process. Having to be accountable for having their part of the build ready, according to the time line when attending the weekly meeting, is not necessarily something everyone likes, respects, or wants to do. Sometimes, it isn't until after the build and the robot is shipped, that some students 'get it'. Our technical mentor, Danny Diaz, has done an extraordinary job of working with the team in this area. We can only improve and get better using this system.

[Bomberofdoom]

This year, the Mangment team (the leaders - Mentor, CEO, XO etc.) will be using MS Project to help us create our gant that should give us the main idea how we're going to work this year.
We plan to make a template for our work this year, that once this year's game and rules will come out and will be understood we'll be able to fit the gant to the game and our goals for this season.

I must say, I find project mangment right now, before the kick-off, a headache reliefer. I feel I have something that I can grab on to in case I fail to lead properly and it helps me have a better tool of how to do things.

It really is a pro-tool. We tried to do alot last year, but we got into the mistake that we planned too much and found very little time to build, realize mistakes and fix them.
Now that we're manging the build season schedule, I feel that we can work more safley now and receive the best results we can give, because we did a dang of a good job last year, even with all the mistakes we had, and because of this I feel we can do way more, now that thing will be a bit more clearer than before.

[seanwitte]

www.dotproject.com is an a link to an open source project management tool. It will allow you to enter tasks and task dependencies. It also generates Gantt charts.

Part of project management that would be beneficial to address is risk management. For each requirement or set of dependent tasks, maintain a risk list and try to mitigate them. High risk tasks should be pushed earlier in the schedule.

A task like "produce drive module code" has very clear risks:
1) If the task is not completed before the drive train is completed you will hold up testing of the rest of the robot and driver training.
2) If the task is not complete before ship date you can't compete.

The mitigation is easy:
1) Incrementally code/test/verify starting with the most basic code needed to move. Once that's working then add bells and whistles to fill out the schedule.

[ayeckley]

Also be prepared to work out the human problems, the disagreements and such.

This is key.

One big difference between professional PM'ing and FIRST is that FIRST is essentially a volunteer effort. Being a PM on a volunteer effort is very much like herding cats. Doing it professionally can be too, but to a somewhat smaller degree. A good FIRST PM (or leader in any capacity) is characterized more by how they deal with "human" challenges, rather than by how well they assign slack time in MS Project.

Case in point: project deadlines. Volunteers don't always accept or internalize deadlines, especially at the start of a project. Successful PMs/leaders are those who can get the team to deliver *even if there is no apparent penalty for not delivering*.

I suspect most everybody understands that already...

[Doug Leppard]

One big difference between professional PM'ing and FIRST is that FIRST is essentially a volunteer effort.

I so agree, with your agreeing with me :). I have seen so many teams self destruct because of human issues. Such a short time to build and tensions are high and many on the team are young and some immature.

You need to have PM but it needs to be a light version and you main leaders need to own the goals.

[Chris Fultz]

I did a presentation for the Purdue FIRST class in late 2006 about project management. I will find it and add it to the white papers.

Paper is uploaded. It is a Power Point presentation.
Search for "Project Management".

[Bomberofdoom]

I've just received the notice about PTC sponsership to FIRST.

I checked out the review clip about their windchill program and I think it's great.


Another opinion that came to my mind:

If you want the project to be mostly educational, you should try not to use project mangement, because project mangement is quite ristrictional (which is required for sirious projects). If you want to plan how the learning and education progress will go, you can use the method of PM for that.

But if your a student leader and want to do things professionaly and in the best way you can, my opinion is that you'd probablly want to use PM.

[Maggie27]

We did have some management, but at the end everyone just came together and worked on whatever they could.

[seanwitte]

If you want the project to be mostly educational, you should try not to use project mangement, because project mangement is quite ristrictional (which is required for sirious projects). If you want to plan how the learning and education progress will go, you can use the method of PM for that.

Project Management methods are tools to manage time and resources (students, money, material, etc.). It's not restrictive unless you make it so. It would be very difficult to make sure everything needed to build a FRC robot is finished without some planning. A tool like Windchill allows you to make a list of everything you need to do and organize it to fit the time and resources available. This includes administrative tasks like arranging travel, shipping, and payments, as well as designing, building, and testing the robot. A very handy and effective way to analyze a project is with a Gantt chart. It will be very obvious, even to a novice, when things are going South. If you're running two weeks behind is it worth starting to work on something that will take 3 weeks, knowing there is almost no chance you'll finish? When tasks start to slip you need to adjust because those 6 weeks will pass in a blink. Unless you have a plan you won't even know you're behind.

[dpc131]

As some have stated Systems Engineering and Project Management are extremely effective in the build season. We implemented a Systems Engineering course for the student leaders last year and it helped them in running the team's design and build period. Although not directly project management, we still showed them how to schedule the season and hold design reviews at critical checkpoints of the buiild.

There was a few comments on how the schedule was thrown out when they needed to redesign. Although sometimes that is inevitable, using Systems Engineering will minimize the chances of a total redesign. For example, last year we had a subsystem redesign; but we identified up front how it interfaced with the other systems. The redesign had to maintain those interfaces so that the rest of the robot could continue to get built during the design change. It allowed us to stay on schedule and re-direct extra resources to the redesign.

Moral of the story, as you begin your build season, think of how subsystems will interface to each other, talk about them, write them down and if you need to change a subsystem make sure that the interfaces change as little as possible.