Nice feedback, Michaël. I'd like to add in some more.
First of all, my first advice would be to treat the design doc as more of a vision document that's just a couple pages long. You can't create a design document before you start designing, unless your design is derivative of something else that's playable.
Second, when it comes to scoping your project, you'll have no idea how long things will take you, so you're almost guaranteed to underestimate how long it'll take. I'd go even further and scope your design to a game that your team could comfortably make in 2 months, especially since you won't be doing this full-time. Personally, I think something like The Graveyard would be a perfect scope for your team and timeline. This isn't because it would take 6 months to make one The Graveyard, but because it would take 6 months to make several The Graveyards and throw most of them away, if you know what I mean.
Prototyping is definitely the key.If your game design is game logic-focused, it'd lend itself to a paper-based prototype (RPG, RTS, strategy, puzzle, possibly platformer). Shoot for having a rough version of it in 1-2 days.
Otherwise, you'll want to be working on the digital prototype. Work with the programmers to get something playable as soon as possible while the modeler and animator are concepting. The modeler and animator should be executing your vision for the art direction by first either coming up with designs themselves or finding designs that represent your vision. They should also be finding music/sound design since no one else has that role. Your role as Director should be to meet with them and guide the art direction so that the designs fit the vision for the game.
Your role as Designer should be to work with the programmers to make sure you have a successful playable prototype of the design. Since your timeframe is 2 months, you'll want to have a playable digital prototype around the end of week 1. If that doesn't sound like enough time, reduce the scope until you think you can get something playable in a week. So depending on the skill level of your programmers, this could involve them doing simple script work in Torque/Unity/UDK/whatever or lower level using a game engine. The key for the prototype is to explore your intended experience.
Most likely, after the first few days of getting something going, you'll realize that your idea doesn't really work. So the next couple days are spent iterating and refining the idea to try to get to something that
does work. I have no idea what your game is about, but you want to judge the success of the prototype on how well it represents the core essence of the game. This could be the fun of using a mechanic, or in the atmosphere, or an emotion, or in the storytelling. This essence should be captivating in a sense, even in the prototype after your first week. It should be like a glimmer of hope in the darkness. If you don't see this essence, then you have the tough decision of continuing to work at it or to make more major changes. Don't go forward if you're not feeling it, though. Starting over now is much safer than later.
Here's a good example of a (polished) prototype that has the essence of an atmosphere:
http://ian.janasnyder.com/snowfield_2.htmlIMO, this atmosphere is established primarily through the environment design, character animation, weather effects, and sound, all of which are aesthetic in nature. A good test is that you can just let your character stand there and the scene is still pretty interesting.
Hopefully you'll have a prototype with that essence along with some established art direction. Now you want to flesh out the prototype while testing the asset pipeline. The modeler and animator should be making mock-ups to test the whole pipeline of getting assets into the game using tech features that accomplish your art direction. By tech features I mean things like normal mapping, cel shading, a day-night cycle, physically-dynamic objects, and so on. I'd suggest one of the programmers should be devoted to streamlining this pipeline and coding supporting systems, while the other programmer focuses on the core elements of the game like movement, collision, and any game logic.
One thing you could do to test the art direction in the game itself is to create a static scene without much thought to performance, including a non-skinned character that could be moved around and not animated. As Michaël said, texturing usually needs to be done after animating, which needs to be done after modeling and skinning (unless you're advanced enough to know how to get around those limitations already).
Lastly, you should be careful with team dynamics. Your goal as Designer & Director is to have a completed, successful experience for your portfolio. In a way, this can conflict with the other team members' goals for their portfolios. A programmer might want to code a fancy effects system or an elegant design pattern. An animator might want to use a new IK technique or use in-game physics to improve walking on a slope. Some of these goals can work against having a finished game. Your team will need to work together to come up with a balance so that each member has something interesting for his/her portfolio while still being able to get the game done. Don't forget, having the humility to sacrifice some sexy feature in order to get the game done is a valuable thing for a portfolio, too. On the other hand, you want to scope the game down enough that it can be really polished.
