Keeping an Eye on the Big Picture

[AllenGregoryIV]

Sanddrag, that's very similar to how we run our team as well. I think we have about 2 all hands meetings during build season and one of those might go away this year. Everything else happens over email or in small groups.

[Aren_Hill]

Originally Posted by sanddrag

This seems to be a good point in the discussion where I can add something JVN posted a while back in a similar thread. It was something to the effect of "We will never vote on a design. Voting is not an engineering decision making process."

I agree completely with that, and not everyone should have an equal say, or even a say at all.

If you look at how some of the most successful teams operate, you'll notice that they often have one person driving the design, from big picture to minute detail. They can delegate the work, but they are beginning with the end in mind, and know what the whole thing should look like before any of it is CAD modeled or built. These individuals are often mentors with many years experience in FIRST, and they have often closely studied the successes of others.

This is how the teams I've been on/mentored operated, I was typically that person, or it was a "brain trust" of 2-3 people fulfilling that role.

I think the mentor leading up this role also has the responsibility of keeping an eye out for students capable of assisting in his/her duties though a capable/motivated student may not exist every year so it tends to require flexbility/awareness in the role.

[MichaelBick]

Originally Posted by DampRobot

I don't deny that having a mentor be the "team tsar" detracts from student involvement and learning, but on some teams it's part of their culture. Frankly, I hardly find it surprising that high performing teams tend to have a mentor fill this role. It's extremely hard to find a student with enough dedication, let alone experience and political ability, to fill that role in a way a mentor could. If winning is a high team priority, a mentor almost needs to fill that role. (Now, before to all jump down my throat, winning isn't a bad goal...)

I've been the "build master" for the past couple of years on my team. It really is very hard. For one there is a lot of work that needs to be done. What I've concluded is that it is really hard to build a competitive robot by a) 100% students and by b) 100% mentors. The best solution in my opinions is a bit of both. You really need an active mentor base to help train your students and you need a good group of students who are willing to take initiative. To any student trying to manage being the "build master" on their team, the biggest recommendation I can give you is to spread out the work as much as possible.

[Kims Robot]

What 1538, 254, and any teams that seem to have that "Big Picture oversite team" have is a Systems Engineering Group. In Madison & Allen's case, they are the Systems Engineer for the team.

I posted a while back on the topic, and I think its perfectly relevant here.

Whether you have a team or a person, its incredibly important to have someone filling the Systems Engineering Role, and I guarantee that all of the teams that perform well and meet their goals have incorporated Systems Engineering, whether they call it that or not.

[ttldomination]

Originally Posted by Kims Robot

What 1538, 254, and any teams that seem to have that "Big Picture oversite team" have is a Systems Engineering Group. In Madison & Allen's case, they are the Systems Engineer for the team.

I posted a while back on the topic, and I think its perfectly relevant here.

Whether you have a team or a person, its incredibly important to have someone filling the Systems Engineering Role, and I guarantee that all of the teams that perform well and meet their goals have incorporated Systems Engineering, whether they call it that or not.

I think...I think this may be it.

- Sunny G.

[Rynocorn]

Originally Posted by MICHAELABICK

We have a mechanical director(me) who handles all of the coordination of the robot build. We start with a general picture of what we want the robot to look like based on our game strategy. This year we came up with a design almost exactly like 1986's robot. We then start prototyping while adjusting our original design based on our prototypes. This year by week 2 we realized a climber was out of our resources. Additionally, we thought that we could build an overall better robot by focusing on cycling, though we left an easy spot for our intake to attach(based on our prototypes). I coordinate this with the design team(which I also head).

My team does basically the exact same thing. The only difference is our team set our expectations lower and never considered making a 30 point climber and actually decided to make a 10 pt hanger only in the last week. We usually don't work on the subsystem until we can fit it into the whole design. I act as the "mechanical director" and communicate with the different groups and help/take over the projects that are falling behind.

But for the rest of the process, it is the same. This process and structure has worked well for us in this past year as it is different than in 2011 and 2012 for us. And we look of continue this method next year and beyond.

Just wanted to put in another teams info, seems like this method is the general consensus.

[DonRotolo]

Originally Posted by Gdeaver

If you don't what a rugby scum is that would be a start.

Yeah, those are the guys who cheat.

But back to the point: We call it brainstorming, but then we take a vote. And year after year, we see that people who have no idea of what they are doing get a vote, and sometimes bring the design in a bad direction.

Originally Posted by Kims Robot

Whether you have a team or a person, its incredibly important to have someone filling the Systems Engineering Role, and I guarantee that all of the teams that perform well and meet their goals have incorporated Systems Engineering, whether they call it that or not.

Yes. This IS it. What I will try to implement* is a systems engineering role, but comprised of a mentor and 2-3 talented students. Brainstorming still works, but the SE group makes the final decisions and irons out the details.

If we then also keep everyone reporting to the SE group, that will solve our problem of trying to integrate five different teams' output into a single product.

I like this thread.

*I am not the one in charge, I need to use my powers of persuasion, Again.

[Ian Curtis]

Originally Posted by Kims Robot

What 1538, 254, and any teams that seem to have that "Big Picture oversite team" have is a Systems Engineering Group. In Madison & Allen's case, they are the Systems Engineer for the team.

I posted a while back on the topic, and I think its perfectly relevant here.

Whether you have a team or a person, its incredibly important to have someone filling the Systems Engineering Role, and I guarantee that all of the teams that perform well and meet their goals have incorporated Systems Engineering, whether they call it that or not.

Do you actually set up formal requirements or use some kind of DOORS-esque tracking tool? Some FRC robot are definitely complicated enough to warrant it. I have thought that writing up actual requirements on Day 1 and 2 would be a fun exercise, but I am not sure we could stick to them.

Originally Posted by DonRotolo

Yes. This IS it. What I will try to implement* is a systems engineering role, but comprised of a mentor and 2-3 talented students. Brainstorming still works, but the SE group makes the final decisions and irons out the details.

In my day job, the systems group does not make that decision. Systems tracks your compliance to requirements, but if you have a non-compliance then that is brought to the attention of other affected owners. If you can't agree on your own, then it is elevated up through the program management, who has the final say (and of course has to weigh the advice of all the affected owners). The equivalent of program management for FRC would be your wizard student or engineer that chooses to serve as Chief Designer/Engineer/Wizard/etc.

[ttldomination]

Originally Posted by Ian Curtis

In my day job, the systems group does not make that decision. Systems tracks your compliance to requirements, but if you have a non-compliance then that is brought to the attention of other affected owners. If you can't agree on your own, then it is elevated up through the program management, who has the final say (and of course has to weigh the advice of all the affected owners). The equivalent of program management for FRC would be your wizard student or engineer that chooses to serve as Chief Designer/Engineer/Wizard/etc.

That's interesting. In the scope of FRC, I believe that the SE group would probably be composed of of the chief designer/engineer/wizard/etc. to begin with.

To talk about System Engineering in general, some documentation (read: wikipedia) seems to imply that the SE folks are involved in design and managing of complex projects. I suppose the specific role tends to vary from company to company.

- Sunny G.

[Kims Robot]

Originally Posted by Ian Curtis

Do you actually set up formal requirements or use some kind of DOORS-esque tracking tool? Some FRC robot are definitely complicated enough to warrant it. I have thought that writing up actual requirements on Day 1 and 2 would be a fun exercise, but I am not sure we could stick to them.

I use DOORs in my job all the time, but never figured on using it with a team. Sure you could, but honestly defining tracking multiple levels of requirements can take a single person or small group weeks upon weeks, and as you mention, things change too fast to really make this a worthwhile tool in a 6 week build. DOORs is all about traceability to the customer requirements, and FIRST is more about defining a strategy - you are your own customer in this case. It may be a fun exercise to do for a summer project... to trace all aspects of a design to the FIRST rules, but Im not convinced there is value in a $6,000 piece of software to track a level or two worth of FIRST Robot requirements.

Its more important for this group to define something like the top 10 requirements for the robot (and even some non requirements). Many teams do this, but fail to stick with it, and that is where they fail. They see something they can add on, or they define requirements that are way out of their means. I would bet if all teams compared what they built in the end to what they said they were going to build at the end of the first weekend, that MAYBE only 10% of them would have achieved their goals, and many would have fallen far short because they ran off on some tangent.

Originally Posted by ttldomination

To talk about System Engineering in general, some documentation (read: wikipedia) seems to imply that the SE folks are involved in design and managing of complex projects. I suppose the specific role tends to vary from company to company.

I've now worked at 3 different companies, and every one of them had a different role/view for SE's. I've been everything from a Project Manager/Engineer as an SE, to a Technical Lead, to a Documentation Monkey, to a Requirements Engineer, to a Subject Matter Expert. You will also see SE associated highly with the IT world, but that's not exactly the role I am talking about.

Realistically every team needs a Technical Lead - one who not only understands the integration of the CAD, but what the electrical team can do to drive it, how the programming team needs it to work, and how everything can come together in the end. This Technical Lead can lead an SE team or Integration team or whatever you want to call it to ensure that everything meets the team's initial requirements, that all designs are following along the path of the team's requirements, and that all components are going to work together in the end. The biggest job for the SE team is Keeping the End Goal in mind... always thinking 5 steps ahead of where the design or build is at, and catching any issues before they happen.

[DonRotolo]

Originally Posted by Ian Curtis

In my day job, the systems group does not make that decision. Systems tracks your compliance to requirements, but if you have a non-compliance then that is brought to the attention of other affected owners.

Good insight Ian, thank you.

And looking at your signature, I fully agree with the Atlas lathe...but a 618 please, not a MK2!
(Proud owner of a nice 10F (TH42) and an even nicer MFC...financed by selling my 618. Worst Mistake Ever)

[wireties]

Originally Posted by ttldomination

To talk about System Engineering in general, some documentation (read: wikipedia) seems to imply that the SE folks are involved in design and managing of complex projects. I suppose the specific role tends to vary from company to company.

Definitely so - I consult with a number of companies and my experience is that the SE roles are very different. In some companies, the SEs are the best and brightest. In other companies the SEs are folks the EE/ME leads did not want. SEs in some companies do nothing but track requirements and advise the PMs but in others the SEs drive the design and dictate to the EE/ME leads. I kinda like environments where the SEs are skilled and experienced big-picture experts - integration seems to go more smoothly.

Our team had a problem with too much input a few years ago. So we adopted a hybrid approach. Our team is very student-run and any student can (still) pitch a design (or a design change) but now they must convince a member of the "design committee" (instead of a single mentor or student) to get it considered. This design committee (a very small group of student SEs) make all key design decisions. I advise them as necessary but primarily I stick to making sure CAD makes sense before fabrication (so we don't tick off our sheet metal sponsors), spending sponsor monies wisely, double checking the physics etc. Some years are still tough but things seem better with a structured and focused decision-making process. I too got older and could not put in the crazy hours! Along with this decision making processs we now prioritize modularity in the design to make integration easier.

Now if we only had better tools and more money... <working on it>

Great thread!