Project Based Game Development Structure
Mar 28th, 2007 by Charles Ferguson
With rising costs in developing video games, project management practices are becoming more and more important. Games are becoming more complex and demanding especially with MMORPGs forcing development teams to expand in order to release in a reasonable time frame. But as teams grow, so do the many issues surrounding organizing, planning, communication, performance and so forth. To counter these issues, overall structure needs to adapt to this new reality as to not suffer from the same failings of rigid organizational practices.
This is the first in a series of articles on Project Management in Game Development. I’ll be covering many different aspects of project management based on theories, research and applied practice. Before we continue, a short reminder, there is no perfect system or miracle solution, each project is unique even if it’s done by the same team. Methods evolve, structures adapt and our approach changes to reflect the reality of a project and to obtain better performance from a team. So these articles need to be read with this in mind, adjusting the concepts to fit your unique situations.
Defining Structures and Teams
Before delving into heart of the subject, a few terms and notions need to be defined.
Traditional Structures are your typical hierarchical top down management organizations that we’ve seen for the last few decades especially in the government. Their main advantages are better technical and managerial control along with good mass production capabilities and good top down communication. Main flaws are slow response time and adaptation, coordination issues between different branches and lower motivation and innovation due to inherited politics.
Pure Product Structures are much closer to the current form found in most gaming companies as it takes the previous structure to the next level creating new for each new project. The main advantages are faster response time, better personnel moral due to greater impact and one manager responsible for an entire project. On the flip side, cost for this form of management within a company that has multiple products is high due to duplication of efforts, technology and personnel. In addition, there is a tendency to retain personnel longer than needed, fewer opportunities for technical interchange between product lines and lack of career advancement opportunities due to limited amount of projects.
Project Matrix Structures are a mix of a traditional vertical structure and horizontal collaborative initiatives which makes use of resources from each branch on diverse projects effectively creating shared resources between the vertical section management and the horizontal project management. Advantages for this type of organization are rapid response to change, sharing of key personnel across multiple projects, sharing of technology and knowledge between projects, easier career advancement opportunities and better functional structure supports for projects (lower stress, available personnel, etc.). Disadvantages are multiple work flow and information flow, dual reporting (project and functional managers), possible conflicts between both managers (priority conflicts, power struggles, loyalties, etc.) and possible increase in administrative personnel to manage structure. (Modified Project Matrix help solve these issues)
Star Teams or to a lesser degree effective teams are defined by H. Dudley Dewhirst as:
A small group of people with complementary skills committed to a common purpose, with shared performance goals and a common approach, holding themselves mutually accountable.
While this can describe many existing teams, the key words for us are accountability and complementary skills. He proposes that the most effective team size is between 4 and 12 members since above that number, “the closeness, ease of communication and ability of each member to contribute declines” which in turn causes accountability to be much harder to uphold.
He does concede that teams of 25 or more can be effective in some instances, but like other managers have already witnessed, after a certain point, adding additional bodies to a problem yields an expediential decline in return on investment. In such case, project management almost becomes an art in finding the ideal balance between cost and performance.
Groupthink is a phenomenon that happens when a team becomes too cohesive and too like minded causing them to become stagnate and ignore critical thinking. There are many famous examples of this from the Bay of Pigs invasion to the Challenger shuttle disaster of 86. There is a lot of literature on the subject, but I suggest starting with the wikipedia article. One of the easiest ways to encourage critical thinking is creating diversity within a group, which also helps prevent isolation of a group from the rest of the overall project team.
Great Groups are what we all ideally strive for; they are teams whom accomplish greatness, usually something that has never been done, who mesh beyond expectations and that people who have participated in remember always as something almost magical. Examples of great groups would be Disney, Apple, Xerox, the Manhattan Project and quite a few more.
Now that these notions are out of the way, I can delve into development structure and management roles.
Project Based Game Development
Ideally in any development environment we want to use a modified Project Matrix structure that encompasses a portion of the entire company in order to be able to share rare resources across various projects. Most gaming companies already operate following part of this principal to some extent (mostly with their publisher). The best example here would be marketing working closely with a developing team to provide resources one way (research and customer feedback) while responding to request the other way (promotional material and feature changes). I’ve heard of technical matrix being used successfully as well in certain companies, but in such a case, the same engine is used for multiple titles permitting the sharing of the programming resources across multiple projects.
But this article isn’t about company wide organization changes as those are always much harder to implement. Instead, I will be concentrating on large scale development teams to help maximize efficiency by looking at certain project matrix structures practices that can be implemented with less hassle.
Foundation Development
As stated before in the previous section, each structure has its advantages and disadvantages; one should not discard past practices for flashy new methods without looking at what they lose in exchange. A traditional structure has its place in game development especially when having to coordinate with so many employees. Its biggest advantage though is in world content creation namely code optimization, bug hunting, dialogues, scripting, art assets, traditional Q&A, etc. Top-down management also makes it easier to evaluate work done as lead managers have greater experience in their respective fields than the project manager (or producer in our case) who is by nature more of a generalist.
When creating game play content (mostly features, but primary content such as the main character can be included), a project matrix becomes much more interesting to optimize resource usage, skill sets and development time. Each new feature becomes a project within the overall product with its own schedule, team structure and resource allocation. This makes it easier to estimate and balance time, cost and performance as well as quickly respond to changes in priorities as the scope of the work. Non critical features also become much easier to cancel if they slip from their planned milestones. In addition, as you are working with people with different fields of expertise, Groupthink becomes less of a factor. Another advantage not mentioned in the previous section is the creation of new lines of communications and the added educational benefits as feature personnel return to their original group with the knowledge gain from their collaborative projects.
For example, adding a new combat engine feature might require resources such as a designer, programmers, artists, an animator, a Q&A member and an assistant producer to oversee the work. As the team interacts they discuss and agree on the best approach for this new feature taking in the input from each party. As each member works on their respective part, they know what the others are working on, how everything fits together and the best approach for the agreed upon end result. The assistant producer coordinates everyone’s effort and can work with the various leads to optimize time spent on the feature by his team members. The deliverable could end up being the combat engine, with its animation, a few models to test it, particle effects, and new tools to make it easy to implement this engine with other characters and modify combinations, effects and results.
I can think of one company that used a similar mentality in one of their upcoming game: Spores by Maxis. Creating small teams like this makes it easier to prototype new ideas and then implement them onto your existing engine, a bit like combining building blocks. So long as you have a solid foundation which you are constantly improving through your vertical structure, stubborn features should not cause any major delays to the overall project.
Roles & Responsibilities
To help minimize potential conflicts, there needs to be a person with overall authority on the entire project. This person is responsible for scheduling, budgeting, resources allocation, conflicts, relations with publishers, etc. As you can already guess, this person already exists.
Producer are tasked with releasing the best product they can while balancing time, cost and resources. They are often the keeper of the Vision and have many additional hats to wear in order to get through a day. In large development teams, the producer might not be the one that pushes the global vision of the game, but he still gives final approval due to his other responsibilities. This is mostly due to the increased in interruptions, planning and responsibilities that come with larger teams which makes it difficult for him to also be responsible for the creative coordination.
Creative Directors have already made an appearance in certain companies to help producers with centralizing the game’s vision. While opinions are still mix on their actual necessity, we need only look at the movie industry where the director and producer are two different entities. In Great Groups we also see a tendency for two people at the top of any project, one that has the vision and the other that makes certain that it happens. Some might say that lead designers are the equivalent and currently, I would have to agree, but most current management structures do not give him enough authority to adequately assume the full spectrum of this responsibility.
Section Directors is how I describe top managers directly beneath the Creative Director such as the Art Director, Editorial Director, Technical Director, Quality Assurance and so forth. In larger structures, high level administrative management becomes almost essential in order to obtain optimal performance out of the entire team. Responsibilities include assigning tasks, ensuring production quality, supporting their various teams and team leads, working closely with the creative director, producer and production staff on overall design, evaluation, scheduling and so forth for the overall project and for specific features.
Associate & Assistant Producers in this model are directly beneath the producer but cut through the organizational structure to gather personnel from different branches to work on various new features. Assistant Producers, Team Leads and Section Directors work closely together to best determine which personnel should be used on each feature task and also to what capacity are they shared.
In some cases, you might want to assign a member of the overall team as an assistant producer to manage the creation of a minor feature. This gives the studio a chance to train future producers and associate producers. Another approach is to assign a person as Project Champion instead to act like a motivator and an inspirational force especially if the assigned Assistant Producer is more technically inclined than behavioral.
Team Leads fall under their respective directors and can be structured in quite a few different ways. One, they can be more managerial, coordinating with multiple team clusters to distribute workload and verify work done. Two, they can be more of a Champion, encouraging groups or individuals to surpass expectations and helping people on their career path. Three, they can be specialists, coordinating with a small team to accomplishing tasks. Four, they can be the mouth piece of a group of individuals working together on content.
There are more ways to structure a group than these four and there can also be Sub-leads under a Lead to fragment into addition sub-clusters. It really depends on the skills of the person in the position and the way how the members of a team interact together.
Beneath the Team Leads and the Sub-leads you finally arrive at the team members. As stated with the modified project matrix, they can be shared between their usual team and multiple feature projects at any one time, working on multiple tasks and having more than one line of communication available to best understand their project.
One group that are a bit special would be the design team. Depending on development studios some people might want to place them directly beneath the Creative Director to give the most support while others might want to place them under the Editorial Director. Some people might want to try and dual task Designers as Assistant Producers to lower the amount of required personnel. It’s all a matter of how your design team is structured and what are their responsibilities.
Team Clusters
The last thing I’d like to touch upon while is team size. As described in the previous section, Star Teams are usually teams of 4 to 12 people, but as other documentation will also state, the larger the team, the less productive the team leader becomes as he mostly takes care of managerial work. When considering team leads, this is something that should be kept in the back of your mind. The military found that the ideal size is about 4 or 5 (including the lead) if you wish to have a very productive team leader. More than that, you run the risk of having to deal with potential personality conflicts.
When you fall into project initiatives (like features), you need someone to handle the balance between cost, time and performance. Since that person is already focused on managerial duties anyways, Star Teams of 4 to 12 become ideally suited. If a feature is especially demanding, you can always have sub-teams within this structure in order to take advantage of small clusters performance boost.
Final Thought
I can literally go on for many more pages, but I’ll stop here. The next article in this series will most likely be about collaboration and communication. I plan on releasing one such article monthly or bi-monthly depending on my schedules. I hope you’ve enjoy reading this article and I look forward to your feedback.