Jennifer Bullard - SCHEDULING CREATIVITY

You knew it was going to happen. The casual games industry is growing up, and what that means is that our processes need to grow up with it. We’re starting to see much bigger development teams and the more sophisticated development practices that come with them.
In the core development space, producers directly manage teams of 50 developers including responsibility for design, development, testing and art. And we can learn a lot from watching how they work.

The CGA asked me to prepare a virtual hands on how-to for getting started in scheduling a game development project based on my experience managing a mid-sized team of approximately 35 developers. I have also included some tips and tricks associated with this seemingly daunting and often inaccurate task.

Estimating Time

A new development project can be in trouble from the outset unless the schedule is based on reasonable time estimates. The trouble is that the realities of the workplace can make time estimates unnecessarily ambiguous. Even common terms such as “months” or “days” can be imprecise and lead to misconceptions. How many days in a month? 30? Wrong! A work-month ranges from 19 to 22 days. And a work-week is typically five days long—not seven—assuming that it isn’t shortened by a holiday.

Thus, from the outset you will be better off if you base your estimates on how time is actually “consumed” in the workplace. For example, if you use “hours” to break down tasks into their smallest increments, you will be better off every time. If someone says a task will take two days, for instance, write down 16 hours. Then, keeping in mind that a typical eight hour day includes maybe only six hours of actual work (what with time spent in meetings, getting coffee, hanging out in cubes or surfing the web), you’ll know that when a programmer tells you “two days” you should expect it to take more like 2¾ days instead.

Similarly, you should use weeks to define key milestones. If you are looking to get paid every month based on a publisher’s schedule, then some of your milestones are going to be five weeks and some will be four. In fact, often it is helpful to not count the fifth week as a working week at all so that you give the schedule some “rest time” to allow the team to clean up work and catch up on details. On average you can count on about four of these bonus weeks a year, which can be a boon when dealing with tight schedules or overstuffed game design documents.

Step One: Anticipating Interruptions

Whenever planning a development schedule, make sure to take note of holidays and vacation days up front. Also pay attention to where each holiday falls in case any of them (like July 4th) is likely to be turned into a 4-day weekend. I also recommend that you note days that are likely to cut into the number of hours people work: Valentine’s Day, Halloween, Easter, Mother’s Day, Passover, Yom Kippur, etc. It also doesn’t hurt to make note of each team member’s birthday.

I also strongly recommend sending out an e-mail asking for vacation plans from each member of the team. The earlier everyone knows about these things the better, especially if it turns out that half of your team is going to be gone the first week in July or that your lead programmer is taking two weeks off in March while his wife is having a baby.

Step Two: Factoring in Key Milestone

On any project there are set lengths of time for each step in the process that you need to allow for. Find out how many weeks need to be dedicated to each step and deduct them from the schedule. When I do this, I like to work backwards:

Manufacturing Time – How long does it take for your manufacturer to print the discs and ship to the retailers? Is time of year a variable? Can you re-slot yourself or is the date set in stone? On average you’ll need to allow about four weeks.

Certification – The certification process depends almost entirely on the shipping hardware. Time and process will vary by manufacturer, but here is a safe rule of thumb: Find out how long it should take and then pad it by at least two weeks. That way if something goes horribly wrong you’ll have time to fix it. On the other hand, who is going to begrudge you two weeks of polish time if all goes well?

Beta to Gold Master – At EA, Beta means the team thinks the game is ready to ship. I recommend leaving two weeks between Beta and Gold Master, during which time no development or bug fixing is expected and the product goes through rigorous certification testing. This two week period is a great fail-safe precaution that gives your team time to polish the game off.

Alpha to Beta – An Alpha at EA means that all of the content and features are in and playable and you can play through the main line of the game without consistent crashes. To be certain, you will still have some crashes and problems and there will be bugs to fix, but for the most part the game is playable. Depending on the project, this period can run anywhere from four to 12 weeks.

Feature Complete to Alpha – Feature Complete generally means all of your features are in, but most likely they don’t work properly and there are crashes. I consider Feature Complete a good gauge of how well the project is going and the appropriate point to determine the final features of the product. Getting feedback from focus testers is key at this point so that you can determine two things: a) which features don’t work at all and ought to be eliminated; and b) what additional features must be added either to fix current problems or to simply make the game more fun. Figure out what you can realistically add and then cut everything else. If the game is seriously buggy, however, don’t add new features at all, but rather fix what is there and polish things up. It is here that you determine whether or not the project can or should be extended to improve game-play, or if an extra month or two really won’t make much of a difference. in the period between Feature Complete and Alpha is typically between four to eight weeks—again, depending on the scope of the project.

Demos – Make sure you know early on when the game is going to be demoed and how much time your team is willing to put into each demo. If demos are extremely important to your team, company or publisher, make sure to put at least two weeks for each show into your schedule. If your title is going to be a big hit at a big show such as E3 then create an entire milestone (four to six weeks) to create content and polish just for that.

Creating a Final Time Estimate

Once you have all of the information you need—calendar considerations, milestone allowances, and the all-important fudge factors, creating a time estimate and schedule is primarily an exercise in arithmetic. The concept is to start with a whole number of available weeks (Step One above) and then subtract the standard time allowances for each milestone (Step Two above). That leaves you with the actual amount of time for the project. Allow me to illustrate:

Let’s say the total time between your start date and your launch/shelf date is 56 weeks. Now subtract the following:

2 weeks of holidays
3 weeks PTO
4 weeks of manufacturing
2 weeks of certification
2 weeks Beta to Gold Master
6 weeks Alpha to Beta
4 weeks Feature Complete to Alpha
2 weeks for E3

Total: 25 weeks of non-development work, which leaves you with 31 weeks for research and development.

Write down these backend dates on your calendar and see where you have overlaps with holidays and vacations. If you have Alpha due the day before Christmas, for example, you should probably consider moving it—or at least warn everyone they’ve got to get their work done before leaving for the holidays.

Conclusion

Of course, there is much more to managing a production schedule than simply working out a reasonable time estimate and getting it onto a calendar, but if you start with reasonable and accurate assumptions, everyone—the engineers, the artists, the QA team, you name it—will be happier. What’s more, your project will run more smoothly every time. As our industry continues to grow, that can only be a good thing.

Jennifer Bullard has worked in the game industry since 1998. She has worked her way from QA, through Design, into Production, and now is a Senior Producer at Aspyr Media where she manages a team of 25 game developers. Her background in management was of great help and has provided a strong foundation for managing projects large and small. With over 40 titles in their portfolio, Aspyr Media is a developer and publisher of original and localized game content. Jennifer can be reached at jbullard@aspyr.com.

HOME \| LECTURES & ARTICLES \| PRODUCTION & DEVELOPMENT \| SCHEDULING CREATIVITY Scheduling Creativity Each time we say this time will be different. And each time it is—just not the way we want it to be. Jennifer Bullard Casual Connect Magazine, Fall 2006 You knew it was going to happen. The casual games industry is growing up, and what that means is that our processes need to grow up with it. We’re starting to see much bigger development teams and the more sophisticated development practices that come with them. In the core development space, producers directly manage teams of 50 developers including responsibility for design, development, testing and art. And we can learn a lot from watching how they work. The CGA asked me to prepare a virtual hands on how-to for getting started in scheduling a game development project based on my experience managing a mid-sized team of approximately 35 developers. I have also included some tips and tricks associated with this seemingly daunting and often inaccurate task. Estimating Time A new development project can be in trouble from the outset unless the schedule is based on reasonable time estimates. The trouble is that the realities of the workplace can make time estimates unnecessarily ambiguous. Even common terms such as “months” or “days” can be imprecise and lead to misconceptions. How many days in a month? 30? Wrong! A work-month ranges from 19 to 22 days. And a work-week is typically five days long—not seven—assuming that it isn’t shortened by a holiday. Thus, from the outset you will be better off if you base your estimates on how time is actually “consumed” in the workplace. For example, if you use “hours” to break down tasks into their smallest increments, you will be better off every time. If someone says a task will take two days, for instance, write down 16 hours. Then, keeping in mind that a typical eight hour day includes maybe only six hours of actual work (what with time spent in meetings, getting coffee, hanging out in cubes or surfing the web), you’ll know that when a programmer tells you “two days” you should expect it to take more like 2¾ days instead. Similarly, you should use weeks to define key milestones. If you are looking to get paid every month based on a publisher’s schedule, then some of your milestones are going to be five weeks and some will be four. In fact, often it is helpful to not count the fifth week as a working week at all so that you give the schedule some “rest time” to allow the team to clean up work and catch up on details. On average you can count on about four of these bonus weeks a year, which can be a boon when dealing with tight schedules or overstuffed game design documents. Step One: Anticipating Interruptions Whenever planning a development schedule, make sure to take note of holidays and vacation days up front. Also pay attention to where each holiday falls in case any of them (like July 4th) is likely to be turned into a 4-day weekend. I also recommend that you note days that are likely to cut into the number of hours people work: Valentine’s Day, Halloween, Easter, Mother’s Day, Passover, Yom Kippur, etc. It also doesn’t hurt to make note of each team member’s birthday. I also strongly recommend sending out an e-mail asking for vacation plans from each member of the team. The earlier everyone knows about these things the better, especially if it turns out that half of your team is going to be gone the first week in July or that your lead programmer is taking two weeks off in March while his wife is having a baby. Step Two: Factoring in Key Milestone On any project there are set lengths of time for each step in the process that you need to allow for. Find out how many weeks need to be dedicated to each step and deduct them from the schedule. When I do this, I like to work backwards: Manufacturing Time – How long does it take for your manufacturer to print the discs and ship to the retailers? Is time of year a variable? Can you re-slot yourself or is the date set in stone? On average you’ll need to allow about four weeks. Certification – The certification process depends almost entirely on the shipping hardware. Time and process will vary by manufacturer, but here is a safe rule of thumb: Find out how long it should take and then pad it by at least two weeks. That way if something goes horribly wrong you’ll have time to fix it. On the other hand, who is going to begrudge you two weeks of polish time if all goes well? Beta to Gold Master – At EA, Beta means the team thinks the game is ready to ship. I recommend leaving two weeks between Beta and Gold Master, during which time no development or bug fixing is expected and the product goes through rigorous certification testing. This two week period is a great fail-safe precaution that gives your team time to polish the game off. Alpha to Beta – An Alpha at EA means that all of the content and features are in and playable and you can play through the main line of the game without consistent crashes. To be certain, you will still have some crashes and problems and there will be bugs to fix, but for the most part the game is playable. Depending on the project, this period can run anywhere from four to 12 weeks. Feature Complete to Alpha – Feature Complete generally means all of your features are in, but most likely they don’t work properly and there are crashes. I consider Feature Complete a good gauge of how well the project is going and the appropriate point to determine the final features of the product. Getting feedback from focus testers is key at this point so that you can determine two things: a) which features don’t work at all and ought to be eliminated; and b) what additional features must be added either to fix current problems or to simply make the game more fun. Figure out what you can realistically add and then cut everything else. If the game is seriously buggy, however, don’t add new features at all, but rather fix what is there and polish things up. It is here that you determine whether or not the project can or should be extended to improve game-play, or if an extra month or two really won’t make much of a difference. in the period between Feature Complete and Alpha is typically between four to eight weeks—again, depending on the scope of the project. Demos – Make sure you know early on when the game is going to be demoed and how much time your team is willing to put into each demo. If demos are extremely important to your team, company or publisher, make sure to put at least two weeks for each show into your schedule. If your title is going to be a big hit at a big show such as E3 then create an entire milestone (four to six weeks) to create content and polish just for that. Creating a Final Time Estimate Once you have all of the information you need—calendar considerations, milestone allowances, and the all-important fudge factors, creating a time estimate and schedule is primarily an exercise in arithmetic. The concept is to start with a whole number of available weeks (Step One above) and then subtract the standard time allowances for each milestone (Step Two above). That leaves you with the actual amount of time for the project. Allow me to illustrate: Let’s say the total time between your start date and your launch/shelf date is 56 weeks. Now subtract the following: 2 weeks of holidays 3 weeks PTO 4 weeks of manufacturing 2 weeks of certification 2 weeks Beta to Gold Master 6 weeks Alpha to Beta 4 weeks Feature Complete to Alpha 2 weeks for E3 Total: 25 weeks of non-development work, which leaves you with 31 weeks for research and development. Write down these backend dates on your calendar and see where you have overlaps with holidays and vacations. If you have Alpha due the day before Christmas, for example, you should probably consider moving it—or at least warn everyone they’ve got to get their work done before leaving for the holidays. Conclusion Of course, there is much more to managing a production schedule than simply working out a reasonable time estimate and getting it onto a calendar, but if you start with reasonable and accurate assumptions, everyone—the engineers, the artists, the QA team, you name it—will be happier. What’s more, your project will run more smoothly every time. As our industry continues to grow, that can only be a good thing. Jennifer Bullard has worked in the game industry since 1998. She has worked her way from QA, through Design, into Production, and now is a Senior Producer at Aspyr Media where she manages a team of 25 game developers. Her background in management was of great help and has provided a strong foundation for managing projects large and small. With over 40 titles in their portfolio, Aspyr Media is a developer and publisher of original and localized game content. Jennifer can be reached at jbullard@aspyr.com.