Q&A: Producers Of The Roundtable - Practical Scheduling For Games

[Gamasutra is partnering with GameProducer.net, a game production resource, for a series of Q&As named 'Producers of the Round Table'. The Round Table is a place for producers who work in game industry to present their opinions in response to questions.

In this installment, which deals with scheduling issues in game development, participants include Robbie Edwards, Senior Producer at Red Storm Entertainment/Ubisoft, Peter O'Brien, Producer at Bizarre Creations, Harvard Bonin, Senior Producer last at Electronic Arts, Adrian Crook, Producer at Relic Entertainment, and Frank Rogan, Producer at Gas Powered Games.]

What tools do you use for scheduling, and how do you co-ordinate it with the project leads - do you devolve any responsibility to them?

Robbie Edwards: We use Microsoft Project for scheduling. Each workgroup is responsible for their group’s workload and schedule. The projects serve as a customer for the work groups; requesting work and communicating deadlines for the work.

Frank Rogan: We use eProject for scheduling and project management; eProject also has the capability to import documents from Microsoft Project. Our workgroups differ slightly from project to project, but are generally organized around functional teams devoted to discrete slices of the project. The leads of those functional teams work closely with production and the discipline leads (art, engineering, etc) to properly set and track tasks and schedules.

Red Storm Entertainment and Ubisoft's Ghost Recon Advanced Warfighter 2

Adrian Crook: I used to use Excel & Project, but since we've moved entirely to Agile/Scrum, we now use Scrumworks for our scheduling. And because Scrum is "decentralized" project management to some extent, we place a lot of responsibility on the Scrum teams and ScrumMasters to administer and update Scrumworks during each sprint. Without regularly updated data in Scrumworks, we can't generate a burndown chart in order to plot the trajectory of project completion. So keeping the sprint tasks updated is a big priority for each Scrum team.

Peter O'Brien: For me, the foundation is MS Project. Although simply dismissed as a glorified task list, its still one of the best tools to reveal project visibility from the task through to the cost of development in relationship to resource. Using Project Server empowers people to own their tasks beyond the original estimate with flexibility to alter duration.

The main issue with all of this empowerment is a reduction in human interfacing. To address the balance, bi-monthly reviews of schedules is a must. Each dev area has a schedule owner. Beyond Project we pretty much adapt to the teams' needs; if printouts are required, they get it, if excel versions are needed, they get it, if they want email reminders, they get it. The most important facet is to be adaptable and understand when a schedule isn’t working and why. In practice, toward the end of a project we reject the schedule in favour of a bug database. This allows items, be they tasks or bugs to be validated at the final hurdle instead of a team working to order blindly.

Harvard Bonin: MS Project is pretty standard throughout the business...though it has its own share of issues. It's important to remember that its only a tool - and the tool is only as good as the hand that uses it. When I begin a project I always create a "components list". I try to think about all the elements that encompass the project such as the entire feature set, people, launch plans, post launch plans, externally licenses software, etc. The list goes on and on.

I find that most people, including myself, get daunted at the beginning by the shear magnitude of the undertaking. There are so many unknowns and its easy to worry yourself into inaction. By creating a components list at the start the producer can begin to understand the lay of the land and make these unknowns into tangible knowns. This list doesn't solve the issues listed, it simply attempts to list them. This is a brain exercise that can help you get a grasp on the problem set. Collaboration with the team leads during this exercise is vital.

Coordination with the leads is always critical. Sometimes just getting everyone on the same page as to the overall project goals is challenging. Regular meetings, setting monthly goals, holding people accountable for their schedule, etc. are all ways to keep people in sync.

What's the best way to deal with task dependencies - what bad things have happened based on dependencies, and how have you fixed them?

Robbie Edwards: Ideally, our workgroup structure encourages the workgroups themselves to identify and handle their task dependencies. For example, if a problem in our character pipeline is identified that is dramatically affecting quality or productivity, the character production workgroup is empowered to deal directly with the person to fix the problem, typically resolving it without much fuss. In terms of scheduling, we try to identify areas with a high number of dependencies and ensure they receive focus to prevent costly delays and problems.

Frank Rogan: Like Robbie indicates, above, our functional teams are set up to deal with their own dependencies, but in all cases, dependencies are best dealt with by forward-looking and planning in the pre-production phase. Problems with dependencies are usually the result of communication breakdowns, which is why functional teams exist in the first place – each team has representatives from different disciplines, to bird dog those issues before they become problems.

Adrian Crook: We found that the best way to deal with dependencies is two-fold: First, by organizing into multidisciplinary Scrum teams that contain every team member required to get that team's specific body of work completed, we eliminate virtually all external dependencies. Secondly, for the dependencies that remain, we have a prominently displayed dependency board to which everyone on the team can add items via post-its. The Leads and the scrum teams review the dependency board together several times a week to ensure everything possible is being done to knock dependencies off before they become blockers.

Peter O'Brien: Some tasks are easier than others. The less complex the tasks the easier it is to manage dependencies, no matter how many. With large tasks that appear as a black hole when you look at them as a Producer, you can only really attempt to chunk it up in large milestones. A good place to start is backward from the mastering date. You still end up firefighting a lot but it should be on the smaller issues and allocating resources or improving focus can often alleviate issues. If a task isn’t tracking and having a domino effect, the best action in the short term is to re-prioritize the dependent where possible.

Bizarre Creations' Project Gotham Racing 3

Harvard Bonin: Not keeping track of dependencies is a recipe for disaster on a project. This will result in idle time and team members that seem to always be waiting. Cells (different disciplines working hand in hand on a feature) tend to help make sure everyone is working on the right thing at the right time.

There will always be some form of dependency not accounted for. Also, many team members often feel like they should be working on something more important. Its the producer's job to make sure all team members understand why tasks must be completed in a certain order. Sometimes things just take longer than expected. Its important for the producer to know when to move onto something else. Team members come to the producer for guidance, assuming that you have a road map and know the goings on within other departments. And they are right to expect you to.

How granularly do you schedule your tasks when laying out a project schedule?

Robbie Edwards: This varies depending on the scope, complexity, priority, risk and time available for the task. A complex and high priority task would be scheduled to the day while a shorter, lower risk task would be scheduled just to be completed by. While we would love to schedule every task in units of hours, most tasks, in my opinion, do not warrant that level of scrutiny. I personally feel that game development is so volatile, any efforts to go beyond a “close approximation” are almost futile. Of course, my opinion changes as the project approaches its final weeks and days where detailed scheduling can make a tremendous difference.

Frank Rogan: I like to say that most project management tools are great for projects where all the variables are known ahead of time. If you’re opening yet another branch of Starbucks, you pretty much already know everything you could possibly need to know (construction, permitting, hiring, receiving coffee shipments, etc), and the task is to manage the project against a known model. Game production is no such beast. Design a fight system. How long will that take? There’s no three-ring binder to consult. So, you have to plan around the blue sky development phases.

That being said, the environment changes drastically depending on where you are in the project cycle. The final phases must be planned with far greater detail.

Adrian Crook: Again, since we're using Scrum we map out "user stories" in a prioritized backlog of items that we use to fill up each upcoming sprint. As sprints come up, the granularity of those user stories increases because we know more about them. Really high level user stories - or "epics" as we call them - exist as far into the project as we can map them, but detailed user stories can only exist as we get closer to the sprint they'll belong to.

Relic Entertainment's Warhammer 40,000: Dawn of War

Peter O'Brien: A couple of rules; basically, anything bigger than 5 days gets broken down. It’s not uncommon to have a 30 day tasks at the beginning of the project if you are not sure what the work entails, but as soon as you understand the demands then the task is broken up into smaller, traceable elements. I don’t like going below a day for a task. Micro management at this level is more of a hindrance than a help … it’s the big brother mentality of development.

If you are evaluating estimates consistently then your schedule should become more accurate as time passes. I'm speaking specifically about code or logic scheduling; content can be a different beast. If you know an object takes 20days to model, there is point in breaking that down. What you might add is texturing time, materials time etc.

Harvard Bonin: I prefer within 2-3 days. That is not to say you aren't aware of tasks that will take 1/4 of a day, but I've never found a need to track people that tightly. Its important to remember that your task list is not the same as your schedule. The schedule is simply used to track team members. The task list tries to take into account all activities, even if they aren't broken out in the time line.

If working with a publisher, how do you (or would you like to) set up a milestone schedule? How do you prevent milestone crunches which include wasted work?

Robbie Edwards: In my ideal world, I would like milestones about every other month or every month. I would like to start the first day of each month detailing what we intend to accomplish or test. Then on the last day of each month, review that progress and begin again the next day. Frequent review and communications are critical in my mind and with the speed of change in our industry, it’s very difficult to remain competitive and meet expectations when those expectations are only reviewed every 3-6 months.

When it comes to preventing crunches, I am all for scope changes. I adamantly feel that realistic planning and frequent project evaluations will all but eliminate the need for crunches. Yet, crunches still happen and instead of death marching the staff, I prefer to look for low value and high cost features and start considering their removal. A tired staff is an ineffective staff and quality is greater than quantity. Having a fresh team every day putting forth their best efforts is much better than any of those small features that end up on the chopping block.

Frank Rogan: Milestone schedules should be oriented around usable results. Prototypes delivering XYZ feature, alpha/beta deliveries with clear definitions, etc. This is good for relationships with publishers, because it gives them the real yardsticks they’re looking for. But it’s also good for team dynamics -- the team is working toward something tangible, with a shared sense of mission. Milestones for milestones’ sakes lead only to crunches and frustrations on all sides.

Gas Powered also benefits from the strong sense of mission derived from its “Skate Hard” philosophy, which places an emphasis on health and family. That’s an entirely different subject for future round tables, though. But GPG’s most recent projects have been remarkably crunch-free, relatively speaking.

Gas Powered Games' Supreme Commander

Adrian Crook: Relic is wholly owned by THQ, so there is somewhat less emphasis on formal milestone reviews with our publisher than in a traditional dev/pub relationship. We are still quite strict with our sprint review meetings, however, where we gather the whole team to review the work completed by each scrum team.

At the end of each sprint, there is a bit of a mini-crunch - maybe a few days of more intense work - where each Scrum team is putting extra love into their work for the sprint review. But overall we make it a point to avoid the kind of crunching that has people working weekends or late into the night. You pay a price for that kind of crunching that isn't commensurate with the short term benefit, if any.

Peter O'Brien: I work directly with Microsoft to setup a schedule but the first stage is internal; getting the team leads/management involved at this stage is important. I’ve tended to drive the schedule creation process and then look for publisher sign off. The fact of the industry is that a publisher wants visibility on at least a monthly basis.

However, 4 weeks for a milestone is unrealistic, 6 weeks is tough but manageable. I think it’s important that you are honest and show a strong vision for each milestone. A target definition of what each milestone will contain shows that you understand the project, but if you are not careful it can lock you into unrealistic deliverables if you don’t build a flexible relationship with the publisher.

Harvard Bonin: Milestone structures are pretty standard but it's important not to allocate the entire milestone payment to the entire body of monthly work. The publisher will almost always have some issue and hinging the entire payment on one relatively small thing will put you out of business fast. Remember, the publisher wants to pay you...they want you to be successful. I like to break payments up into smaller buckets so that the developer can get paid portionally. By doing so the publisher can still hold back funds due to noncompliance but still allow the developer enough resources to make payroll!

Wasted work is really about communication. Getting the publisher builds early and often allow for changes. Simply handing a milestone over at the end of the cycle doesn't allow the developer to make course corrections mid-milestone. Communicate every day with the publisher. Every day.

How do you factor demos into scheduling? Is it better not to make a demo before the release of a game at all, and have you managed to persuade other people about that?

Robbie Edwards: We have been fortunate enough to turn our demo production into a mostly data driven effort. This allows us to build our demo with basically no effort and be confident that its quality matches the full version. The demo build is initiated towards Beta and is maintained until it is submitted or released, typically ahead of the full version. As to whether or not a demo is necessary, well, I have my opinions, but ultimately a quality product is not damaged by a demo.

Frank Rogan: These are two very different questions – how to schedule for a demo, and whether to have one at all. The former is a fairly traditional production challenge – a demo should be treated, after all, as yet another milestone with a fixed, tangible result.

The latter question gets into marketing philosophies. Clearly, some demo strategies are huge wins for marketing the product and energizing the fan base. But some demos are so full-featured, I have no desire to purchase the game – it’s like watching a movie trailer that gives away all the best jokes.

We need to think differently about demos, which smack of being done in a certain way simply because “that’s how it’s always been done.” Movies like Shrek and Ratatouille have handled trailer releases quite differently – extended trailers of single, uncut, bravura sequences that a) are great to watch, because they give you a better taste for the overall movie, b) are easy to produce, because they don’t represent significant new work or production hiccups, and c) don’t give away the farm.

We need to support marketing efforts, but I’d like to see something new under the sun, and I think the customers would react positively both to the merits of the game itself and because it would stand out in stark contrast from the crowd. Does anyone really want to play yet another tutorial level? ‘Nuff said.

Adrian Crook: Well the nice thing about console demos these days is that because of the decreased lead time for electronic distribution (i.e. Xbox Live) vs old school magazine disc distribution (i.e. OXM), you can usually wait until the code is locked for submission before generating the demo. Putting together a demo is relatively easy after you've submitted to first party, as you're mostly sitting around and waiting anyway. But putting together a demo for E3 or another trade show has to be scheduled.

Sometimes it's worth creating a separate code branch and small demo team specifically for the demo, other times the demo goals are aligned enough with the project goal that almost the entire team can focus solely on the demo. So I'd say for end-of-production demos, don't schedule them - do them during submission. But for middle-of-production demos you definitely need to carve out sufficient time/resources to complete something solid.

Re: whether or not demos are worth it, I think it depends on how confident you are in your product and how your product's buzz (or lack thereof) is trending. If your product is "flying under the radar" but you think it's strong, do a solid demo and surprise people. If Marketing/PR has done a killer job and has your product top-of-mind, but you have concerns about the level of polish you could implement in a demo, then don't do one. Pretty simple.

Take Two/Rockstar's popular Grand Theft Auto series succeeds without demos

Peter O'Brien: Creating a demo is all about having a flexible development environment that allows a demo to be siphoned off the main project. The aim is always to reduce resource impact. Ultimately, a demo is a standalone product which goes through its own dev process and therefore has bugs. If a demo has to be come out before the full game it can become a focus for the team which benefits the rest of the project. As for the validity of demo’s.., I haven’t seen data to convince me they are a required part of marketing and selling your game. I always cite GTA as an example of a product which never has a demo and uses other marketing tools to deliver, what, a 30+ million selling product? Hmm …

Harvard Bonin: I've done both. At the end of the day making games is just plain hard. The demo will take time away from other efforts but they can be worth it. Schedule it in from the beginning. This will allow you to scope the project around it. Its essentially like finaling twice. That said, NEVER release a poor demo. The demo is a promotional tool and I've seen projects suffer by delivering rotten demo experiences.

Towards the end of any project, how do you build in gameplay iteration and polish into the schedule alongside testing? Are they separate phases, or integrated to some extent?

Robbie Edwards: We typically handle gameplay revisions in parallel to the development. Features and tasks that have a dramatic impact are usually completed first so that we can begin gameplay reviews very early. Where possible, the gameplay evaluations may even be done where there final tech and content isn’t available.

When it comes to polish though, we strictly focus on polish post Beta. At beta, all features are complete and we spend our remaining cycles addressing bugs and adding polish where feasible. During our polish phases, we regularly have great strides in performance improvement and visual quality.

Frank Rogan: On this, I’m a big fan of productions that heavily front-load mechanics and character, camera and controls into prototyping and long-ish pre-production phases (a la the Cerny Method), so iteration and polish is essentially built into the entire development cycle.

Adrian Crook: First off, gameplay refinement is done throughout development. Scrum focuses on taking features to completion before moving on to additional work. But it's always nice to have some time at the end to tweak. To do this, you'll need to have managed the project's scope shrewdly. Often you'll have a hard ship date to hit - there are very few companies that can take the "we'll ship it when it's ready" attitude - so any slippage along the way steals time from a pre-established polish period at the end.

And every project slips their milestone dates at least a bit during development. So be prepared to refocus scope along the way, trimming lower value features in order to retain your polish period. When the final bell rings, I'd sooner have 5 features at 100% complete than 10 things at 50% complete.

Re: whether or not polish and testing are concurrent, I think they are. Fixing bugs goes hand in hand with polishing and balancing a game.

Building design in Project Gotham Racing 3

Peter O'Brien: We aim to build gameplay iteration into the project much earlier than at the end, note the words aim to. In some cases, gameplay is your primer so you can be iterating from month one. Depending on the gameplay component it will either run in parallel with content (circuits design when creating the cities in PGR for example) or sit within its own area. It really depends on the goals.

Harvard Bonin: I believe they are integrated - but it takes a disciplined producer to recognize when its just time to be done. Build in the polish phase and be very greedy about giving it up. Create specific goals for bug counts, type of bugs to fix and when, etc. Work and partner with your QA manager and also make sure the team if very aware of polish cut off dates.

Do you have any overarching tips for how to successfully schedule a game so that it finishes on time and on budget?

Robbie Edwards: As mentioned previously, knowing where you are and where you want to go are critical in making sure you get there. Have a good vision for your game. Be able to identify what features are critical to your game. Then, as production moves forward, constantly evaluate your progress against your vision. Know where to focus your efforts and be willing to cut your losses. I think many people get attached to particular ideas or features and lose sight of the bigger picture. This attachment leads them to make costly choices that ultimate damage their product as a whole.

Frank Rogan: About the best overarching advice is to take a page from Peter Drucker and recognize “they’re not employees, they’re people.” Analog world, not digital. Make your plans with that in mind. But at the risk of sounding even more glib, there’s no magic bullet here. You will always make mistakes. The project will be a constant compare-and-contrast effort with where you are and where you want to be, and what you’re doing with that others have found to be useful.

Adrian Crook: Yes. My tips are:

A) Identify the core vision of your game early, so your team knows what 3-5 features/game areas must be finished to 100%. If you're using Scrum, give these items high priority and work on them first so they get done as awesomely as humanly possible.

B) Be ruthless about cutting non-core features whenever you need to keep the team on track. Cut these features before any effort is applied to them so you can redirect efforts to higher ROI areas.

C) Have a hard ship date. An immovable ship date provides great clarity and efficiency for the creative decision makers on the team. As a result, issues that might normally get discussed for weeks are often solved in a day.

Peter O'Brien: Plan without your team, plan with your team. Project a realistic spec against your time line. Respect your team’s knowledge but don’t fail to question them if estimates or definitions are ‘woolly’. No one project is the same, no one process if perfect … change and adapt your project plans – be ready at any stage to do this. Develop a priority system and make the schedule visible in as many ways as you can – a wiki, a forum, calendar reminders, paper lists, white boards, wall planners; reinforce the importance of targets. Prepare to lose features. Be objective when it counts.

Try not to forget to remind the team they are a team and they are making a game; a good way to do this is to provide a platform where the team can share and/or discuss their work in various ways. Finally, don’t ever forget that a team is made up of individuals.

Electronic Arts' long running Madden NFL

Harvard Bonin: Too many developers try to throw in the kitchen sink when creating a game. It's important to scope accordingly. A focused, polished game is far better than a sprawling, half done game. Put the features under the micoscope. Is everything really required? If you drop a feature can you spend time polishing and focusing on the important stuff? Is the feature you really want ever going to get the care and feeding it deserves? Better to cut things and improve the overall quality.

The opinions expressed by these producers are their own and do not necessarily reflect the opinions, plans or positions of the companies where they work at. If you are interested in being added to the interviewees for Producer Of The Round Table, please contact GameProducer.net.