Re: Keeping an Eye on the Big Picture
 

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.

Re: Keeping an Eye on the Big Picture
 

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.

Re: Keeping an Eye on the Big Picture
 

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.

Re: Keeping an Eye on the Big Picture
 

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.

Re: Keeping an Eye on the Big Picture
 

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

- Sunny G.

Re: Keeping an Eye on the Big Picture
 

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.

Re: Keeping an Eye on the Big Picture
 

Yeah, those are the guys who cheat.:rolleyes:

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.

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.

Re: Keeping an Eye on the Big Picture
 

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.

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.

Re: Keeping an Eye on the Big Picture
 

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.

Re: Keeping an Eye on the Big Picture
 

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.

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.

Re: Keeping an Eye on the Big Picture
 

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)

Re: Keeping an Eye on the Big Picture
 

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!