Project Management and FIRST?

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

Originally Posted by Doug Leppard

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 that is all about a time line and management during build season for rookie, or any team.

[Doug Leppard]

Originally Posted by David Brinza

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]

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

Originally Posted by Tom Bottiglieri

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]

Originally Posted by Alan Anderson

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]

Originally Posted by Bomberofdoom

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]

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.

[JaneYoung]

Originally Posted by Michael Sperber

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.