Author: by Heather Maxwell Chandler

As veteran producer, I have first-hand experience with development teams viewing me as the “enemy,” more intent on following some schedule rather than making a great game. While this is not the case, it is hard to overcome the team’s perception because I am often trying to motivate the team to work harder and/or faster to ensure the game meets its scheduled ship date.

Producers don’t want to be the bad guy (or gal) who is only focused on the bottom-line, but when they are trying to manage a chaotic project with a shifting schedule, increasing scope, and variable resources, they often have to resort to doing what is best for the schedule in order to meet the demanding deadlines common in game development.

Add to this a team of creative people who are reluctant to concretely define game features or implement any formal project management processes, for fear of stifling creative energy or losing the ability to change major features, and the chances of putting out a great game on time, without crunch, start to diminish.

As games increase in scope and the teams increase in size, producers need to implement more formal project management methods in order to keep track of what’s going on. Formal methods have met with resistance in the past because there are a lot of things that simply won’t work well in game development (such as the waterfall method).

Schadenfreude Interactive shows how chaotic game planning can be.

Also, some developers feel that a cookie-cutter process stifles the creative environment of game development, or that people will get bogged down in filling in paperwork, instead of working on the game. However, there are many valuable methods and processes that can be modified for use in game development and won’t require the team to dramatically change their day to day working methods. In some cases, the team or individuals may choose to change their methods once they learn how helpful some of these processes can be.

In order to successfully implement some type of formal methodology, the producer must explain to the team why the method is necessary and get buy-in from them, otherwise the process will fail and further convince the team that formal project management won’t work for game development.

Getting team buy-in is something that won’t happen overnight, and the producer should focus on incremental changes in order to get make the team comfortable with the changes and to achieve the best results. So, what are some elements to change and how can the producer get the team enthusiastic about these changes?

Listen To What People Need

One of the most important things a producer does is listen to his or her team. The team wants to have a say in how the game is developed, since they are the ones who must actually code the AI, create the character models, design the multiplayer features, and test the game.

If the producer tries to force the team to comply with a new way of doing something, and cannot explain why the change is being made, the team will resist the change and become frustrated and less productive. Therefore, it is important for the producer to create an open environment where people can discuss why they prefer to work the way they do, and how they think their working conditions can be improved.

For example, an artist may prefer to work late because he is constantly asked questions or going to meetings during the day, and is most productive after everyone has gone home. In reality, his work load is probably normal, but he can’t use his working time wisely because of the constant interruptions.

So if producers are able to identify specific issues that impact people’s working time and discuss these with the team, it is likely the team will come up with some new processes that will improve the work flow of everyone on the team. This way, the team is an active participant in solving the issue, with the producer acting as a facilitator, instead of a dictator.

Educate People On How Using A Formal Process Can Help Them

I’ve found that taking time during pre-production to briefly explain basic principles of project management gets the team excited about the possibilities of spending less time working and enthusiastic about trying something that will help them do this. This also allows the team to get a better idea of what a producer does on a daily basis, and may help the team to overcome the attitude that producers are “suits” in disguise.

Because most game developers are suspicious of formal processes it is natural for them to be wary of any procedures the “suits” want to impose on them. So if the team views the producer as a vital part of the of the development team, the more willing they are to listen to the producer’s ideas how to improve the working conditions through project management techniques.

The producer has to be flexible and willing to educate people on the why certain processes are necessary and demonstrate the benefit it will have for the overall production cycle. The producer must also listen to people’s complaints (and praises) about project management. For example, if devs have to fill in a change request form (CRF) to add a new feature, they are less likely to do so, and it’s possible the suggestion would have been easy to implement and provide a huge benefit to the game. That’s not to say that CRFs shouldn’t be used, but the producer must also be flexible as to when a change request form gets used.

For example, during the prototyping and early production phases, the game goes through so many changes that using a CRF is counter-productive. However, during the last month of game development, when everything is locked down – it may be prudent fill in a CRF depending on what change is requested (new color scheme for the UI) and who makes the request (senior management).

Focus On Basic Project Management Techniques That Have The Biggest Impact

When trying to select which project management methods to employ, select ones that will be easy to implement and have a big (and positive) impact for the team. For example, one thing that can be applied immediately and doesn’t require a lot of extra work is the way meetings are run.

Everyone has spent time in meetings where no one knows what the meeting is really about, and afterwards no action is taken on anything discussed, which negates the purpose of having a meeting in the first place.

If the producer establishes an agenda beforehand, takes notes, defines and assigns action items (with deadlines), and follows up on the action items, people are very surprised at how useful meetings suddenly become. It only takes a few extra minutes and is well worth the overall working time saved on a project.

Because of the chaotic nature of game development, techniques focusing on project definition can also be easily implemented. For example, work breakdown structures (WBS) are useful in educating the team on how each individual’s tasks affects the work of others. An engineer might not realize that completing the lighting tool one week later than planned will negatively impact the art schedule, or a designer may not understand why taking an extra day to script a level impacts the QA work flow.

The producer can use the WBS as another educational opportunity, by selecting a game feature, gathering everyone who works to this feature, and creating the WBS structure with their input. People will see first hand how their work impacts others, and will have a better appreciation for how everyone is truly working together to get the game finished on time.

The same type of technique can also be used for defining people’s roles on the team. How many times have you walked by someone’s desk and wondered what they really did all day? In cases like this, it is helpful for each team member to take a few minutes to define what they do on the project and share this with the rest of the team. Something like this can be very simple, such as “I am coding the vehicle AI,” or “I am creating the UI art,” or “I am prototyping new game types,” but be extremely beneficial to building team rapport.

Demonstrate How Schedules Offer Flexibility

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.

Show The Team How Project Management Has Improved The Working Conditions

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.

Use Weekly Meetings As A Forum For Change

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.

Conclusion

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.