Robot Design: If there isn't a vote, who makes the decisions?

[Akash Rastogi]

Hey Nick,

Great question and I'm glad this is something being asked before the 2014 season. I believe the best way to learn about other decision making and consensus generating techniques is to read JVN's build journal from 2010.

http://www.chiefdelphi.com/media/papers/2360

Best of luck!

-Akash

.

[cadandcookies]

Originally Posted by Akash Rastogi

Hey Nick,

Great question and I'm glad this is something being asked before the 2014 season. I believe the best way to learn about other decision making and consensus generating techniques is to read JVN's build journal from 2010.

http://www.chiefdelphi.com/media/papers/2360

Best of luck!

-Akash

.

Thank you, this was a very interesting and informative read. I think remember reading something similar from 2009.

There have been some great and informative answers so far-- I think it's interesting how teams seem to gravitate towards the "consensus" decision method.

On a personal note, this thread has vindicated a lot of the ideas I had floating around about running a decision making process.

I figure I'll also share how my team is planning to approach design this year-- I'm from a very large team (70+ students and 30+ mentors), so getting together the entire team for discussion isn't exactly a good idea (trust me, we've tried- and failed), so we're splitting into small groups that each have a "lead" student. These groups basically go through the process of selecting a strategy individually-- with emphasis on using predictive math (expected values, etc) and logical decision making (decision matrices, QFD). After they've come to individual consensus, we gather up all the leads, who do essentially the same thing, but taking input and calculations from all the individual subteams. The idea is to cast our net as wide as possible while still keeping it manageable with so many people.

[Akash Rastogi]

Originally Posted by cadandcookies

Thank you, this was a very interesting and informative read. I think remember reading something similar from 2009.

There have been some great and informative answers so far-- I think it's interesting how teams seem to gravitate towards the "consensus" decision method.

On a personal note, this thread has vindicated a lot of the ideas I had floating around about running a decision making process.

I figure I'll also share how my team is planning to approach design this year-- I'm from a very large team (70+ students and 30+ mentors), so getting together the entire team for discussion isn't exactly a good idea (trust me, we've tried- and failed), so we're splitting into small groups that each have a "lead" student. These groups basically go through the process of selecting a strategy individually-- with emphasis on using predictive math (expected values, etc) and logical decision making (decision matrices, QFD). After they've come to individual consensus, we gather up all the leads, who do essentially the same thing, but taking input and calculations from all the individual subteams. The idea is to cast our net as wide as possible while still keeping it manageable with so many people.

I'm from the school of thought that, while everyone from the team should have a chance at giving their input on concepts and what to prototype, the cold hard decision making portion ultimately falls on the core leadership group of mentors and (usually) upperclassmen subteam captains, or a Design Team. This smaller core group is the one that debates strategies, shows off prototypes, and fairly evaluates each one. On a large team, this is a lot harder.

Like you said, gathering team leads is a good idea, but sometimes you ought to let one or two others that the lead picks out from his/her group join the discussion as well.

Lots of ways to go about doing this, and a lot of it depends on your team structure. Always good to evaluate if your large team is structured in a way that might even allow the use of some of the techniques JVN discusses.