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.

[ChrisH]

Originally Posted by 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).

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!

[Chris Fultz]

Originally Posted by crazykid234

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.

[Chris Fultz]

Originally Posted by 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.

[seanwitte]

Originally Posted by Bomberofdoom

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.