[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.

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.