Video Games website Gamasutra proposes a brief on schedule, time and team management, a crux issue in software/video game development.

The Mythical Man-Month is a seminal work on not just software engineering but the psychology of human interaction inside a team environment. (...) Creating a schedule first requires building a task list, which is in fact an expression of your design document. Are you building a racing game? Do you need a four-point suspension system? Do you need a flight control model? Is water surface dynamics critical to the boat level? Do you need a custom lightmapper? These game features need to be filtered into independent engineering, art, and level-construction tasks. The resolution of these tasks is dependent on where you are in the timeline of your project. We begin with system-level tasks during pre-production and constantly refine these as milestones are started, progressed, and completed. By the time you reach production with the major unknowns resolved, you should be able to make a valiant effort to refine the entire schedule down to days, but don't. Tasks should initially be timed at a resolution of about a week. Anything that needs to be completed in the next two months should be resolved down to days. Refining the resolution too much, too soon will be work wasted since the dynamic nature of a schedule will lead you to redo it anyway. (...) The next stage is understanding your team's manpower. You should begin by identifying the type of developer (any team member including programmers, artists, level designers, and so forth) each person on your team is. One simple way to do this is to analyze how they fall into four basic types, based on combinations of skill and dedication. These types can be represented on a simple 232 matrix with their skill level on one axis and their dedication on the other. (...) Once you understand your team, you can successfully begin to assign people from your pool of talent to the task list you have built. Assign the highly skilled but poorly motivated people first. Give them the systems their skills match and they are interested in building. If you run into conflicts such as too many physics programmers all wanting to own the system, try to exchange these resources with other teams. You do not want highly skilled, poorly-motivated people working on systems they don't want to. If you do this they will most likely start dragging their feet or sending out resumes. Next, layer in the superstars who most likely can do almost any system you assign to them. These people have written graphics, physics, sound, AI, and most everything else so skill matching should be less important. After they have been placed, the first two groups of developers should cover every major system, leaving the eager rookies to round out the corners and fill in the gaps.