Good Schedules, Bad Schedules | Game Coding Complete

Everyone I know uses milestones, but not everyone I know uses them correctly. Most of what I learned about defining and working with project milestones was from (can you believe it) Microsoft. For as much as Microsoft gets panned in the industry at large, I think they do many things right and one of those is planning around milestones. As a point of comparison, Origin used a more naive approach when I was there, mostly because we thought we were pioneers in the development of games and we didn't have to look elsewhere for a better way. I attribute a lot of wasted weekends (or should I say entire summers) to this sophomoric approach.

You can tell if your scheduling process is a little off by looking for these warning signs:

Your project has a critical "Alpha" and "Beta" stage, and these stages only define what the game is supposed to be like instead of defining how the team changes their work habits.
Even worse, you can't get a consistent answer from anyone exactly what "Alpha" and "Beta" are supposed to be.
There isn't any time specifically allocated for fixing bugs during each milestone.
The schedule doesn't take personal time, holidays, or other non-working time into account.
The smallest defined task on a schedule is one week.
You can't see if other assets from the art or sound department are going to be ready when the programmers need them.
You can't break each major task down into specific programming, art, audio, design, testing, web, database, or other components.
You can't verify that every team member knows exactly what is expected of them each and every milestone.
The time estimates or task inventory were assembled by "outsiders."
Your entire project schedule can be printed out in a smallish grid of boxes in Microsoft Excel.

I can already hear some of you screaming, "Somebody save me because every single one of those things is true about my game project!" Put your personal affairs in order and bring your sleeping bag to work because I can almost guarantee what's going to happen to your project—the dreaded crunch mode.

Gotcha

Why is it called crunch mode, anyway? I always thought a mode was by definition something that was a temporary transition destined to come to an end. I believe that every company's management makes a choice about allowing semi-permanent crunch modes, and I sincerely believe that crunch modes are the single most destructive practice in our industry today.

Don't get me wrong, I'm not some academic elitist pretending that Murphy is some fictional character. Murphy is alive and well in the gaming industry and bad things happen to the best planners and the most careful development teams. My point is why start the project off with a plan that isn't completely thought through? Murphy doesn't need a red carpet and someone to hold the door open.

Before you can learn how to create the bullet-proof schedule, you need to learn about milestones.