A question that I wish to pose to the community is, since being project lead (hopefully I'm not being too obnoxious taking that title) I've attempted to recreate an actual company feel through creating divisions within the group, based on each of my team member's strength's and weakness, is this an effective method of development? Would it be more effective on this small scale development to have everyone do a bit of everything? Feedback would be very appreciated!
What do you mean exactly. What is the average day like? What is your process? How do you get to review what's been done and what needs to be done from there on?
What everyone's average day looks like? Are they secluded focusing on their work, or do they interact with others in order to define how to shape things up?
I think you can't reasonably demand that every engineer on the team makes art, but its not impossible for an engineer to help out with art.
The general pro you can have by determining core roles is that you can ensure a core balance: if 50% of your members are engineers, you can expect about 50% of the team to deliver technical stuff. This doesn't mean none of them can make art, but common sense implies people will perform better if they do what they do best.
On the other hand, if you do have people proficient with more than one thing, then, what they do best is simply different.
I'd recommend to build your team around the people you have, identifying everyone's strengths and weaknesses.
Let me give you an example of what I mean:
On a recent project, I was given 3 programmers. What I was told by higher management is that one of them was kickass, another average, and the last, borderline ok. These were judgments based off a very restrictive grid analysis of their performance in terms of logic. Basically, it reflected whether they could make good code or not.
What they left out unintentionally, is what each of their strengths and weaknesses were.
The Good Programmer was kickass, but he needed very strict requirements. He could only work by making an analysis of a formal and detailed Technical Design Document (TDD). On a project where requirements are known, not subject to change, and the output quality is not "guessed", you'd want to clone this guy and use him wherever possible.
The average guy was more of a frontend programmer with a strong ascendant for art. His code was decent, but he's really more the kind of guy you'd want to make sure things make sense. He had a keen sense of figuring out design flaws that would make the game irrelevant. This guy actually helped me out identify design flaws back when they were still in design. As you might know, the later you figure out the flaw, the more it ends up costing. So he was a big help.
The borderline ok coder was actually the one I relied the most on. This guy was what I like to call a gameplay programmer: he's a gamer first, with some technical knowledge. Chances are the kickass coder will have to tell him his errors, help refactor his stuff, etc, but his input is invaluable, and he'll be the one with the patience to fine-tune feedbacks and timings to make the difference between a game "as designed" and a kickass product. It really added a lot that he was also part of the target audience of the project, so he made extra researches, etc. In the end, while his input as a programmer was "ok", his general contribution made him a necessary component of the project's success.
If you divide people formally by department, you might miss on this, then again, if you don't give a more or less formal line, you'll end up creating chaos.
Define roles, not professions. Make people owners of specific modules/features, not tasks. You'd be amazed at how many times I've shipped a title with prog-art just because someone felt involved in the project and decided he'd deliver his absolute best. Give the people some freedom, but keep the line straight. Everyone needs to understand the vision, and how to get there.
Then again, know your team. Some team-member's weakness is that they just don't work that way. They need to be told what they need to do, and they'll do it remarkably well. Not everyone is a visionary, and that's ok. Once you've identified who's a "soldier" and who's a "visionary", make them understand they are the same team. No one is bossing each other out. The temptation of a visionary to boss soldiers is a constant pressure that you need to diffuse. Make them work together, but insure you keep that fine balance. Understand that everyone's thrill and challenge doesn't necessarily lie at the same step. Some people are thrilled by creating the idea, others by developing it from A to Z, and others yet by polishing it to A+.
