Engineering management 101
Dear managers, please don't listen to this pilloc, listen to an anonymous coward on elReg instead!.
When tackling large projects always break them down. You'll just have people tripping over each other otherwise. You only need to manage the interfaces between people, not the internal choices within their work.
Don't think consensus is better than individual opinion. In any team you'll get people with different knowledge of a part of a problem, the person working on it, is the expert. Perhaps he knows 80%, the others 50%, 30%. Don't think you'll get 100% knowledge from consensus, the strongest voices often know the least, and you're more likely to get (50+30+80)/3 = 53% at best.
If you ever think you know better than the people doing the actual work, take a vallium and go sit in a corner, you are an idiot.
When coders choose not to talk to you, reflect carefully on previous decisions. Have you ever found yourself listening to what they say then making a choice different from their choice? Why do you imagine your choice is better? You've only got a tiny fraction of the info in their head, they communicated as best they could, you understood as best you could, but ultimately talk is a crap bandwidth transfer!
There is nothing wrong with exploring different solutions to a problem, it is important in learning, especially for students, especially in areas where technology changes fast.
IBM will never make an iPod. They have money, talent, yet somehow the management just can't coordinate that into successful commercial products. But yet they give out certificates!
http://www-03.ibm.com/certify/certs/dm_index.shtml
Donald Knuth didn't take the IBM Certified developer course. You can put him in a team with other programmers and tell him the team knows best, but it's unlikely to be true.