Creating the Schedule | Game Coding Complete

The milestones and milestone descriptions are the goal. You get there by creating a detailed task inventory, assign the tasks to the people on your team, and cutting the result into four to eight week chunks. The result is sent out to the team with instructions to write their own milestone descriptions. It might sound like a redundant task to get your team to write down a description of their work when you just handed them that very thing. After all, why should a programmer describe the details of how the user interface functions are used to select new weapons when the design specification contains an entire section about weapons selection?

The programmer writes down their milestone descriptions and passes them back upstream for three reasons. First, the user interface might not come online in totality in one milestone. The programmer should write his or her own milestone descriptions with the goal of explaining exactly how the user interface will look during each milestone while the task is a work in progress. It's a bad idea to accept a milestone description of "User interface is complete" three milestones after it was started. The second reason every team member composes their own milestone descriptions is to be 100% sure they know what tasks they are expected to complete during each stage of the project. Third, if there any dependent tasks that have been scheduled too late, they'll be identified. It doesn't make any sense for an artist to work on special effects four months after the programmer completes their coding tasks.

Gotcha

Computer game programming is an art. This scheduling stuff bores most people to tears, and to be honest I'm one of them. It's easy to get all glassy-eyed when you look at a schedule or a milestone document, and simply accept it as your lot in life. Don't just accept it. You are the only one in the universe that can stand up and say, "Uh, boss, the renderer can't be written in a week."

Collecting the Task Inventory

The task inventory is an exhaustive list of everything that needs to be done to complete the project. You must have a functional specification that's pretty complete before you can do this. There are two groups of people you should involve in this process: the development team to be, and anyone experienced in the game genre. With any luck these groups will be the same people. If you are missing either group, or even worse you don't have either one and you have to completely wing it to get a deal signed, you're already in a very risky situation.

Different games have vastly different task inventories. Only someone experienced in the genre will have the most accurate idea about what things need to be nailed together to make the game work. If you don't have someone experienced at least in an advisory capacity, you could be in a lot of trouble.

Depending on your game genre, you should have the following experts discuss each feature and subsystem:

Programmers: If it doesn't run through a piece of code, it probably doesn't need to be talked about. Almost every task will have a programming component, even if it only involves a little programmer time to install a piece of media into the game.
Artists: 80% of game features will have an art component. It's usually a bad idea to get programmers (or worse, producers) to create any art for a professional product.
Sound: Many games and game designers forget sound and music, which is funny because sound and music bring an emotional quality to games that nothing else can. Even a simple button click will need a sound effect.
Design: Design time should accompany each major task to keep the look and feel of the game consistent.
Database/Web: If your game is an MMP (massively multiplayer game) you'll likely have backend database or web components for some subsystems.
Writing: This component is often lumped into the design group, and includes things like character script, help, or even web content.

Grab copies of the functional specification and drag all these experts into a meeting room for an extended stay. Go over each subsystem of the game and break it down into tasks that are no longer than one week but no shorter than a single day. There may be occasions to lump some trivial tasks together in a day or two of work. Don't fall into the trap of detailing every minute of the day. The time you will spend creating and maintaining this level of detail will smother anyone tasked with that duty, and it will also annoy the team.

A Tale from the Pixel Mines

When Origin Systems started using Microsoft Project to perform scheduling tasks, the Project Manager for Ultima VII fell into this trap. It was hoped that listing every minute task in exhaustive detail was the solution to consistently late projects. When the schedule was complete the printout of the task dependency chart covered a conference room wall floor to ceiling. For those of you who remember, Ultima VII shipped months later than expected. Clearly the detailed schedule wasn't the solution to our scheduling woes.

I suggest using a project scheduling tool to create the schedule instead of something like a word processor or spreadsheet program. Most spreadsheets are incredibly bad at handling calendars elegantly. The difference between calendars and simple date mathematics is that calendars can specify things like holidays, vacations, and the like. Word processors such as Microsoft Word are great at outlining but don't handle dates at all.

As the exhaustive interviews with your experts continue, remember to gather the following information about each task:

Time estimates for each task component (programming, art, design, sound, and so on).
Whether the time estimate is dependant on a particular individual's special skills.
Whether the task depends on the completion of other tasks.
Whether the completion of this task is critical to beginning work on other areas of the project.

This process is incredibly tedious and you'll find that most of the development team will become impatient after the first hour. These meetings will go on for multiple days, or at least they should. They'll be anxious to begin "real" work instead of just talking about it. Try to have breaks during the day or perhaps only meet in the mornings; do whatever it takes to get them through it.

Best Practice

Experienced teams are very careful about drastically over or underestimating the time each task will take. The problems of underestimating are easy to see; the team will end up working too hard to achieve an impossible goal. Star Trek's engineer, Montgomery Scott, would disagree, but arbitrarily doubling or tripling time estimates will put your team at risk of losing the project altogether. When someone tells everyone that it will take them two days to attach one button to one screen, the team should call them on the carpet.

If everyone drastically overestimates everything, a project's estimated schedule and budget will be horribly bloated. If more than one company is bidding on the same project, and you have to assume that that's true, you might get to watch another development team get the gig.

A Few Words about Estimating Time

A famous experiment conducted on a group of programmers rated their speed and quality of a particular assignment. It turned out that some programmers literally took 100 times as long to complete the assignment. That's a frightening ratio. If John Carmack takes one week to write a new 3D engine that means it might take me one hundred weeks! That sounds about right, actually.

This finding is depressing to anyone counting on getting a game finished in time for next Christmas season. How is it possible to estimate schedules when there's such an incredible delta of productivity from one programmer to another? One clear piece of insurance is to make sure your programmers are all qualified to be on your team by conducting brutal interviews. Another good practice is to make sure everyone has some measure of experience in their problem domain. Programmers love working on new things, I know I do. Try to balance the new and the old when everyone's grabbing tasks.

Best Practice

The most accurate time estimates always come from someone who's got experience in the problem domain. The experienced programmer remembers many details of a task, which can't be communicated: APIs for custom libraries, algorithms, gotchas, and dead ends. If you have a task that no one on your team has ever done before, go find someone who can lend some advice. Ask another programmer on another team or perhaps even at a different company.

I've mentioned this before but it's important enough to mention it again: The minimum time estimate for any task is one day. I know it doesn't take one day to perform some trivial task like hooking up a new "OK" button to a dialog box. Instead of estimating this task at ten minutes, lump this task with some other trivial user interface jobs and give it a day. The over estimate of a few hours here and there will come in handy as certain tasks slip.

Assigning Tasks and Balancing the Schedule

Before you go any further, determine if you have the time and resources to finish your task inventory, even if it were perfectly balanced. Add up all the time for programming, art, sound, design, and other disciplines and get a total for each in weeks. You've probably got some expectation of hitting a certain code and content completion date. Take those dates and find out how many linear weeks there are between that date and your project start date. Divide that number by the number of development team members in each area and you'll know how much (or little) slack time there is in your schedule for a given team size:

Formula: ( Actual weeks ) * ( Developers ) = ( Developer Weeks )
Example: 10 weeks * 4 developers = 40 developer weeks
Use that formula to calculate the number of developers you'll need to complete your tasks by a certain date, or perhaps the number of actual weeks it will take for a given number of developers.

Gotcha

Don't assume that you can add developers without limit. A working group of developers can only reach a certain size before you have to bring a higher order or hierarchy into play to manage it. A good rule of thumb is that no manager can be effective with any more than seven reports. Four to five reports is a good number.

Managers (like technical leads or art directors) can perform tasks from the schedule, but not at the same rate as the rest of the team. Don't assign a manager any more than 30 hours of task load per week.

With the entire task list in hand, take a look at each task and assign it to a particular team member or group. Group assignments work well if your art or audio department works as a service center and the tasks are easily communicated. Sometimes the assignments are done in a group, with the entire development team present. Getting everyone to volunteer for tasks is a good idea.

Try to keep the following things in mind while the task inventory is getting split up amongst the development team:

Type Casting: Some people end up doing the same type of task on every project because they are good at it. Don't assume they want to continue this trend until they retire. Try to save something new for them while getting the best person to perform each job.

On the Job Training: Never assign a critical piece of technology to someone who has no experience in the area. This induces a high degree of risk.

A Tale from the Pixel Mines

Ultima IX was supposed to be the first Ultima in 3D. The problem was that no one in Lord British Productions (our producer group within Origin Systems) had any 3D experience whatsoever. We thought, "How hard could it be—we're all pretty smart." What a horrible mistake! Back then we had to write our own software rasterizers, polygon sorting algorithms, mesh optimizers, and object culling. This was not a job for inexperienced programmers, even if we were somewhat brilliant. It certainly wasn't a job that had a specific ship date; and the project ran late. Ultimately, all the code we wrote was thrown out because DirectX and hardware acceleration finally caught up with our efforts.

Spread the Love: The fun stuff and unpopular tasks shouldn't land anywhere in high concentrations.
Unfactorable Technology: Some tasks are large and are difficult to break up.

A Tale from the Pixel Mines

On Ultima VII the combat system was broken up into two parts and handed off to two different programmers. One programmer was responsible for the "core" of the combat system while the other programmer was responsible for everything else. The two programmers had a difficult time working through all the combat related issues and especially who was responsible for what. On Ultima VIII, one of the original Ultima VII combat programmers took the entire combat system under his wing. This solution worked much better from almost every angle, as the system was much better and everyone on the team knew who was responsible for combat.

The first problem you'll see with your first pass on task assignment is that one or more people will have drastically more work assigned to them than others. I tend to balance these loads by moving the task to another person, usually the person who has the smallest task load. If you find that the tasks cannot be moved because of special skills, you'd better start combing the websites for a good contractor, which is another good solution if you have a little budget to spare. If neither of these is a workable solution you should consider moving the date or cutting features.

Gotcha

If someone has a long vacation or even a sabbatical you'd be wise to put that in your schedule! Microsoft Project allows you to use individual calendars where you can mark days, weeks, or even months as non-working time. Don't forget to include company holidays too, or any time your team will spend away from the project (is your company going to move offices?)

Similar to cooking a huge dinner with multiple courses, you'll have to make sure every team member finishes their tasks close to the appropriate date. This date for programmers will become your code complete milestone, and the dates for art, audio, and everything else will become the content complete milestone. You don't want to schedule some programmer to finish anything after code complete, and you may have to jump through some hoops to get that to happen.

A Tale from the Pixel Mines

On the Microsoft Card project I worked on the folks in Redmond wanted us to hit a particular code complete date. Their test department had a heavy schedule that summer and if the product was late it wouldn't have enough test time. We were five programmer months over the date, and we negotiated with Microsoft to add a few contractors, at their expense, to hit our code complete date on time. We did this before the contract was signed, of course, and there were no surprises in the middle of the project. If you need to hit a specific date with a particular feature set, the only thing you can do is add developers; and in our case we hired a contractor for five months.

When you're done assigning tasks and balancing the schedule, double check that you didn't screw up some task dependencies. Look for anything that expects the code to be written before the design work is complete, for example. Some of these dependencies will be too subtle to catch on your own, and you'll have to depend on your development team to identify them when they are writing their own milestone descriptions.

When you're done you'll have an exhaustive task inventory with time estimates and perhaps they'll even be assigned to development team members. Some teams make the mistake of stopping here, handing out this huge task list, and begin working. Some teams will even draw some lines in arbitrary points in the schedule and call them milestones. That's still not enough.

For one thing there isn't any time set aside for milestone acceptance. If your schedule omits this, your development team will have a harder and harder time making their milestone dates and the bug count will skyrocket out of control. Plan on spending about one week per production milestone on nothing but fixing bugs and getting the milestone accepted. Code complete is the last milestone that should need this week of acceptance, since programmers get 90% of the bugs. Solve this problem ahead of time—put real milestones in your schedule and set aside time for them.

Production Black Holes

While were thinking about inserting time in the schedule for milestone acceptance, it's a good idea to recognize that other events during the year bring production on your project to a complete halt. I've listed these in ascending order of disruption. You'd be wise to consider them:

Annual performance reviews
Moving to new offices
Religious holidays
Trade shows (E3, ECTS, GDC, and so on)

Companies like Electronic Arts schedule annual performance reviews for everyone at the same time. This is a serious distraction from production and deserves a few days of non-working time on the part of the staff and perhaps a week for each middle manager.

If your group or your entire company is moving to new digs, you should definitely schedule three to four days of downtime. Every time I've moved, the plan was to have everyone shut down work after lunch on the day of the move and pack. The move would happen and everything would magically appear in the new office. Unpacking was a short affair that would put everyone back into high gear with only a few hours of lost time. Crazy talk! Count on two or three days of lost time from the staff and one additional day or two from each manager.

All religious holidays of any faith can and should take a backseat to work. This can be particularly difficult with members of the game industry who tend to worship at the altar of EA Sports and Sony rather than more traditional venues. Still, it's wise to study your development team and determine, as I usually do, that the entire month of December is an off month (if you haven't shipped by now you're not making Christmas!). Don't get me wrong, I almost always plan for a milestone due one week before the company holidays kick in, but it's not overly aggressive.

All of the production black holes I mentioned so far are nothing compared to the burden placed on the team by trade shows. This is especially true of E3 (Electronic Entertainment Expo), when teams are invariably asked at the very last minute if they can throw a demo together.

It won't matter that many promises were made early on that the game won't be shown at E3 this year and that the team won't have to make a demo. Never believe it for a minute. Always assume that your game will need a demo, even if you only show it internally. You may be asked to go to E3 and show the game on the floor of the convention center, which will take a week out of your schedule. Other industry trade shows like GDC (Game Developer's Conference), SIGGRAPH, and ECTS (European Computer Trade Show) can also suck some development bandwidth from your team.

Each of these distractions isn't a schedule killer on its own. Well, maybe an exception should be made for the E3 demo. Still, if you attempt to make reasonable allowances for these "black holes" you'll end up with a more realistic schedule.

Breaking the Schedule into Milestones

Production milestones should be scheduled for every four to eight weeks of production time. Adding one week for milestone acceptance will put your actual milestones five to nine weeks apart. There are a few things in addition to this you should keep in mind when inserting milestones into your schedule:

Try to put milestone due dates at a convenient time during the week. If you'd rather get some feedback from the test team quickly, don't schedule your milestones on Fridays. Mondays are bad too, because your development team will usually crunch on the weekend to make their date. I prefer Wednesdays as a good compromise.
Don't schedule a milestone on the last day of work before an extended holiday like Christmas; try to make it at least a week before.

I usually like to schedule short milestones (four weeks of development and one week of acceptance) over longer ones, but sometimes a longer milestone is better if a significant body of work is going to complete during that time. For example, lets assume that one of your programmers is working on a new tool designed to compute visible objects, but isn't scheduled to complete it until November 1^st. Your original cut placed a milestone date one week earlier. You could expect a nice increase in the framerate and smoother gameplay if you could push back the milestone to November 5^th or so. Since the work will demonstrate a huge improvement to the production staff and the test department, it's a good idea to change the milestone date.

Gotcha

If your game signs off on December 24^th, I'm sorry but you didn't make Christmas. Your game needs time to be manufactured and shipped to all the retail outlets. This can take four to six weeks and in some cases it could take a lot longer. The Microsoft Casino project had to be finished by October 5^th to make its schedule slot in the manufacturing pipeline. If we missed that, that game would not have shipped before Christmas.

When the dates for your milestones are set, put the acceptance time in your schedule and find out what tasks should be counted in that milestone. If a task completes very close to the due date, I usually put the task in that milestone. It's an aggressive practice but I never compress the actual task time any more than 10% or so. If the compression is too much to take, it will wash out when the individual milestones get written. You should always expect some push back from the development team; if they don't push back at all they probably aren't carefully considering their task load.

Best Practice

Everything else being equal, you can't compress the actual time it takes to perform a task more than 20%. This compression usually comes in the form of simply working overtime.

It turns out that most people can accomplish tasks in aggregate more efficiently than if they tackle each task one at a time. Because the time estimates were done in a team setting, they should be relatively accurate if weighted perhaps a bit on the conservative side. That means the task will likely take a little less time to accomplish than the team estimates. When you add all of the component tasks of a particular subsystem together, you'll probably think that there's a little too much pork in the estimate. That's normal. Bring the estimate back a bit by scheduling the milestone dates aggressively and get the team to sign up for it. If you're being an ogre, they'll come at you with torches and pitchforks. Instead of being an ogre, consider being a football coach and push your team 10% harder than they think they can be pushed.

Writing the Project Milestones Document

You should have your milestone dates and a complete task inventory that gets completed during each milestone. Summarize each person's contribution to the milestone and summarize it in paragraph form. This might seem smarmy, but don't include the original time estimates in this document. You are doing this to double check the team's estimates of task groups instead of each task as a discrete unit. This might seem like a lot of extra work for whoever has control over the schedule; in truth it is an amazing amount of work.

Instead of going through this exercise some decide to stop here and simply hand out the entire task inventory to the team. One look at it and you'll watch their eyes glaze right over lost in the magnitude of the next eighteen to thirty six months of their professional lives. When these tasks are converted into summaries that describe the goal of their work, things begin to take on a clear focus.

Gotcha

The milestone descriptions should focus on the functional goal of the work instead of the details of a particular implementation. If the timeline for a milestone begins to run tight one of the best strategies is to cut to a simpler solution rather than force a difficult solution into a smaller timeframe. Never forget that programmers really enjoy solving difficult problems and will sometimes choose them over stock solutions that have been written by everyone else.

The result of all this work is a milestone document that describes the following things:

The major accomplishments expected of the team during the production dates and a risk assessment.
A due date that takes into account enough time for milestone acceptance.
A list of deliverables.
Non-subjective tests that the deliverables must pass to gain acceptance.
A list of contributors to the production work and a paragraph or bullet list summary of what they need to finish before the milestone due date.

Writing the Individual Milestones Document

Now comes the hardest part. You've just finished what has seemed like interminable hours of meetings where the entire team has questioned and re-questioned each microscopic task of the project. If there was ever a time they wanted to get away from Microsoft Word and start typing curly braces and semicolons this is it. Enthusiasm for more planning is going to be at an all time low, because your team wants to be let loose on the first milestone. Whatever you do, don't let them. Not yet!

The last and by far the most critical part of the planning phase is still coming: The team must write their detailed milestone descriptions using the project milestone document as a guide. Their job is to provide one or perhaps two more levels of detail to what they see in the project milestone document.

Yours truly included, programmers are some of the worst writers and communicators on the planet. I couldn't have written this book without my editors and you certainly couldn't have read it. Be prepared to push on them to give you the detailed milestone descriptions. It is the last chance the team has to catch huge mistakes in the schedule and hopefully save some of those potential lost weekends. As they write about each goal, everyone should keep some things in mind:

Does the amount of work in the milestone seem too light or too onerous? If a milestone seems light they should double check what's expected in the following milestone.
What about dependent tasks? Everyone should double check that anything that must be complete before they begin is described in the milestone document.
Does the task match the skills of the person? Sometimes as a schedule is balanced to end work on or about a particular date, a person might be mistakenly assigned something they shouldn't.
Does the order of work seem right? It is sometimes possible that ordering the work differently is more efficient.
Do the detailed descriptions explain a development goal? Goals say nothing of a particular implementation, and this gives the team more freedom.
Are the detailed descriptions actually detailed enough? They shouldn't gloss over features with a simple sentence. Even button clicks should be mentioned or at least referenced by citing a particular section of the functional specification.

You'll find that some team members will want to review the original task inventory as they double check their milestone assignments. That's fine, of course. You don't want to hide anything or attempt to fool the development team into believing they can do the impossible. They'll hang you for pulling tricks like that, and you'll deserve it.

There's a subtle thing going on here as you might begin to suspect. Trust me. As the team writes verbal descriptions of what they hope to accomplish on each milestone, they realize that they are making a commitment to themselves and their team. They'll study their promises carefully before submitting it to the team at large for final approval. So far I haven't seen anyone take this process lightly. I believe that you never achieve this level of seriousness until you get everyone on the team to write his or her own milestones.

There's another benefit: When someone explains in their own words what they will accomplish for each milestone you can be sure that everyone is on the same page. How many post mortems have you read that put "team communications" at the top of the big problems? I'm not telling you that this process will remove any and all communications problems, but it will make a huge dent in them.

One More Thing Before You Release the Hounds

As painful as this sounds, you have one more planning meeting to attend. Luckily it's a short one. Drag the experts back into the conference room to review the entire milestones document as a group, including the individual milestone descriptions. Hold the plan up to the light and see if anything shines though. Everyone should make sure that someone didn't gloss over something that deserves more attention. Make sure that everyone understands that once everyone signs off on the milestones document it is considered a team commitment. It usually helps if everyone understands that company milestones are serious business and missed milestones should shake everyone down to their foundations.

A Tale from the Pixel Mines

A dear friend of mine, Ellen Guon Beeman, had a hard line policy at her company, Illusion Machines, an independent third-party development studio in Austin, Texas. Anyone who caused the company to miss any two project milestones was sent packing. This might seem cruel and unusual, but in truth it was put in place because missing a milestone usually meant missing payroll. Most game company employees I know live paycheck to paycheck and a delayed paycheck meant no food on the table. When that happens it further hurts productivity which means longer hours to make up for that which is a vicious cycle. If more employees treated project schedules and milestones with that level of seriousness, our industry would be an amazing place to work. Oh, Ellen's company never missed a milestone.

You'll finally cover the tasks in content complete, the last milestone with new tasks, and everyone will look around the conference table and wonder if all that planning was worth it. They'll find out when they hit that content complete date with a reasonable bug count and an easy glide all the way to release.

So what are you waiting for? Release the hounds. Wait, I mean release the programmers!