Making a Schedule

Scheduling game production is like herding cats, snakes and artists.  I'll leave it up to you to determine who is more insulted in that last sentence.

Scheduling comes down to putting the doers with the planners.  There are levels of decision makers that must be consulted when you have large teams.  I know of few products that shipped exactly according to their initial schedule.  While most of my products have shipped on time, I can't say they fit exactly to the first schedule.

Often the higher ups decide that a product must ship at a specific date and that requires you to constrict the features in order to ship.  Remembering time for QA, it always takes longer than expected, can be the key to shipping your title with high quality even if you have to trim features.

The best advice I can give you, small or large tam, is to conduct experiments.  If you make a schedule that has 15 levels, and each level is scheduled to take 4 weeks, that's 60 weeks just for levels.  While your tam is making this first level, monitor their progress closely.  If they take 8 weeks to make level 1, level 2 isn't going to take 4 weeks as planned.  Even if the entire team tells you that the next levels will go faster now that they've finished one.

Always identify those features that can be removed for time constraints.  Better to know a the start that you can remove features that have to kill something you love farther on in development.

Dive head down into the first chucks of development and watch closely the team interactions.  If the team is staying weekends or working 14 hour days, you need to remember this when you review the schedule.

Even with SCRUM, reviewing what you are developing as a whole is paramount to shipping with feature complete at the quality the market demands.  Remember that with waterfall or SCRUM, you should never bite off more than you can chew.

Making your schedule is as much a team effort as is the game development.  Building the schedule with your team gives them a sense of ownership that doesn't happen when you make the schedule and present it to them.  While it's fine to put required milestones up, and then work backwards, the teams respond better if they build it with your requirements in mind.

In the future I'll post about part two, maintaining the schedule.

Mac