In my experience, teams who are reluctant to impose any type of schedule on the game development process normally have little understanding of how schedules are created. People assume it is just more paperwork to make their lives difficult – that they will be forced to learn Microsoft Project and will spend more time tracking tasks than actually doing them.
They’ve also had negative experiences in the past with out-of-control schedules and feature creep that caused the last few months of game development to become a blur of eighty-hour work weeks, and it seems impossible that situations like this can be scheduled.
So when people are asked to provide a schedule, they may counter this request with “why bother, the schedule is going to change by tomorrow anyway,” or “what’s the point, crunch time is inevitable, especially with all the last minute features that people want to include.” This is a golden opportunity to start educating the team about how schedules can actually be helpful.
The basic components of a useful schedule are tasks, estimates on how long each task will take, who is doing the task, and dependencies between tasks. While a specific deadline may be set in stone (the game must ship by Thanksgiving 2007), the schedule components usually offer a lot of flexibility so that this ultimate deadline can actually be met.
In other words, the schedule can be used to determine which features should be prioritized, which resources should be reallocated, which feature should be added/removed, etc.
If there is already a basic schedule in writing, and it is created with the idea of quickly plugging in different scenarios (such as what happens if we add an artist, cut a feature, or reduce rendering time), these types of decisions are much easier and less time consuming to make. Instead of thinking of the schedule as a rigid set of tasks and deadlines that is constantly changing (and therefore a worthless piece of paper), think of it as a guideline for what can be accomplished in a given time frame and as a tool for what adjustments can be made in order to meet the ship date.
As new project management methods are implemented, the producer keeps the team informed of the positive impact these changes are having. Once people experience the benefits of tracking feedback, following up on action items, and focusing on key tasks, they will appreciate the new processes and possibly be willing to try new, more involved techniques.
Hopefully, they will also realize that by establishing some order to the game development cycle, that they now have more time to actually work on the game—they can tweak and polish the game, prototype new ideas, and fix bugs.
Weekly team meetings are a great way to introduce project management changes, especially when the project is already in full swing and starting to get out of control. First, the team meetings are an established forum for distributing information and answering questions about the project. Second, everyone is in the same room at once, making it easy to discuss new ideas and receive feedback. Third, this guarantees at least one meeting a week where everyone is thinking about the project as a whole and the impact their work has on other people.
The producer must establish an agenda for each team meeting and decide in advance which project management methods will be discussed. A great initial topic is having people describe what they do on the project. If the team is really large, this may take place over the course of a few meetings, and limits will need to be imposed so someone doesn’t spend 15 minutes discussing the minute details of the job.
Convincing game developers that project management can help them is not difficult, if time is taken to educate them on the basic principles and they are involved in any changes made on the project.
Keep in mind that the ideas presented in this article are not magic bullets that make all the problems go away—there will still be chaotic schedules, scope changes, and varying resources. However, these problems can be minimized if the team works together as whole on making small changes in the process that will bring order to some of this uncertainty.