Producers come in many shapes and sizes, with a wide range of abilities and experience, but strong communication skills are essential for any producer who plans to create a top quality game.
The producer is considered the “mouthpiece” of the project and is expected to daily communicate project status to everyone involved in the project (the “stakeholders”). With all the different stakeholders on a project hammering the producer for answers, having some simple proven processes to follow can seriously minimize the number of communication issues that occur.
The producer must also be able to clearly explain the needs of the project to the development team and to the external stakeholders on the project. Knowing how to get the right information, to the right people, in a quick and efficient manner, will minimize miscommunication and insure a fun project.
Different Types of Producers
There are many types of producers, so this article will not try to define what the “perfect” producer is. There is no one size fits all in this industry; with games ranging from GBA ports, to $20 million multi-platform projects there is no typical game project.
This article focuses on the “top producer”: this is the producer who is running the development team and is responsible for the status of the project. This can range from an Assistant producer running a secondary SKU, to an Executive Producer on a Next Gen game; either way, the top producer is the producer directly responsible for communicating the status of the project to all the stakeholders.
A producer must have many skills in order to manage a team of creative people and create a great game on time and budget. Producers should be good communicators, both verbal, and written. Producers should also be gamers and understand how to tell the difference between fun and not-fun. This is such an important skill, and one that is hard to gauge as it is very subjective.
Producers also need to know how to deal with conflict. Games are a passionate endeavor and passion causes drama and conflict even on the smallest issues. A good producer knows how to encourage the team to take the passion out of problems and funnel that passion towards finding solutions.
There are many more skills that a producer must posses, but the focus of this article is on communication and how that impacts the success of the game.
The Communication Network
The diagram in Figure 1 (below) is a typical communication network for game development. There are two center points for communication: the publisher producer and the developer producer. Publisher and developer producers are similar, but this article focuses mainly on the developer producer.
The main difference between a publishing and a developer producer is a developer producer is directly managing the development team. A publisher producer manages the whole of the project, not just production. Publishing producers coordinate with Sales, Marketing, Ops, Console Manufacture and others to insure an overall good product. The publishing producer will also deal with QA and the final QA team at the console manufacturer. Publishing producers manage the project team through communication with the developer producer.
The developer producer mainly focuses on the production of the project and insures that all the different elements of production (Art, Design, Code, etc) all work together in harmony. It is important to note that if a producer is running an internal development team for a publisher, that producer is really a developer producer, and sometimes has to operate in both roles. This article is mostly about the communication skills needed for a developer producer, but much of this will also be applicable to a publisher producer.
The Main Lines of Communication
The main lines of communication are to the development team, the studio management and the publisher. These three stakeholders are by far the most influential on the production on the game, so creating clean lines of communication with them will help to keep the product on track. The producer will usually have some external resources working on the project as well, but this communication is similar to the communication with the development team as these external resources are usually development talent. These communication lines are used for many reasons, but the most important are needs and status updates.
Needs are defined as anything that a group needs in order to get their part of the game done. The lead programmer will need more resources or new machines, the studio management will need to know how to take $100,000 off the budget. The publishing producer will need art for marketing, code for demos, docs for interviews etc. Every stakeholder in the project has tasks or deliverables that are needed in order to get the project created on time, and those needs are mostly communicated through the producer.
Status updates are just that: an update on the current progress of the project. The development team will want to know how the marketing effort is going, the studio management will want to make sure the project is on track, and the publishing producer will want an update on current bug count. Clean lines of communication will insure that these needs and updates are being clearly explained to the stakeholders so that they can provide the development team with what it needs to succeed.
Clear Communication Lines
With so many different groups involved in the development of a game, having well defined lines of communication is the best way to insure everyone is on the same page. If everyone sees the same view of the game, then everyone can put their best effort to resolving key issues to help the game ship on time. The two main pieces of information that need to be clearly communicated are the projects needs and status updates.
Status updates are the mechanism by which the producer tells everyone what is happening on the project, what the top issues are, and how the project is tracking. Status updates will usually discuss project needs, but project needs can come from many areas. Sometimes people need something from the project, and sometimes the project needs things from other people. If these needs are not clearly and quickly communicated it can cause the project to get behind and/or go off track as the people making the project don’t know what they should be working on! By doing focused status updates on the project, to the people who need to know, the needs of the project can be more clearly identified and handled.
It is also important to make sure the right people get the right information. Producers should send a summary report to all stakeholders as well as individual reports that focus on each stakeholder issues. Most projects will have tons of issues at any given time, so it is up to the producer to filter that information to make sure each resource is sure they have the information that they need.
Keep Communication Focused
When communicating needs and updates make sure to differentiate between “asking” e-mails and “telling” e-mails. Sometimes producers will send out a long status update with a number of questions at the bottom of the mail. This can cause confusion and many times will result in a follow up e-mail anyway, so it is better to separate these two requests.
Try to keep each request e-mail centered on one main point. Sometimes people put all their questions in one long mail which results in the one or two top issues dominating the thread and the lower priority issues slipping through the cracks. Even though it may seem more optimal to put all the issues into one mail, it is much cleaner to send one mail for each issue. Another benefit of using this technique is that replies will come in quicker. Many times people wait until they get every question in a request answered before replying. By separating issues into several different mails, the other party has a chance to handle the simple issues first, and take their time on the more complex ones.
The producer should implement a change control process that encourages change but with oversight and controls in place. One simple way to implement this process is using a sign off form. This form just has a description of the requested change, detail on the impact to cost, quality and time for the project, and signature lines for all project stakeholders. This file (Microsoft Word document, 25kb) is a simple template that can be modified to suit individual project needs.
Whenever a change is requested from any source (publisher, team, studio management), a change control form is created. The producer then meets with the leads to determine the overall impact of the requested change and puts this information on the form. Finally, the form is circulated to all the stakeholders to get their signoff.
Sometimes a meeting is held with all stakeholders to discuss the potential change request to help build a group consensus. Depending on the studio and the structure, everyone who is on the form must sign off in order to approve the change. Other studios may have an “override” system so that as long as people higher up on the sign off list approve, then the lower level signatures don’t need to be there. Both systems have their pros and cons and which one gets used will depend on the studios’ culture.
Once the change is approved, the producer should document the change in a tracking document. A simple excel spreadsheet is sufficient for this task. At a minimum, the tracking form should contain the date of the request, who requested, the change, total impact to TCQ (Time, Cost, Quality), and when the change was approved. Once again, keeping good records of all requests and changes will not only help when issues with the request come up, but it will also be a great tool when doing the projects’ post-mortem.
Communicating Project Status
Doing daily and weekly project updates to all interested parties is a must for a good game producer. One great way to do this is a simple e-mail summary each morning that calls out the hot issues on the project. One simple way is to use bullet points for each issue, and put the high priority issues at the top of the page, usually in red to help call attention to them. After the bullet points, it’s a good idea to add more detail to some of the issues as well as discuss lower priority issues. It is important to call out the issue as well as the IMPACT the issue will have on the project. See the following example:
Project Status Example 1
- Still waiting for Audio files from Publisher.
- “A” bug count is 300
- No response from marketing on manual edits.
Project Status Example 2
- Still waiting on Audio files from publisher: Alpha date in jeopardy if we don’t get files by end of week!
- 500 “A” bugs: need to be at less than 200 by end of week to meet Alpha.
- Marketing has not responded to manual edits sent two weeks ago: cannot go final until they arrive.
The main difference between the two examples is that the second example details how each issue impacts the project. It is important to show the impact of an issue, as that will insure the proper priority is being set. When sending updates always make sure to use as much detail as possible, but only as much detail as is needed to attack the issue. Be careful not to be TOO wordy in project update e-mails; executives don’t like to read more than 1 page. Also, make sure to stick to simple formatting. Everyone uses hand-held e-mail devices now, so using text reports will increase the chance that the status updates actually get read.
When doing the weekly project update, it’s a good idea to summarize the accomplishments of the week, and then the objectives for the next week. Remember: the status updates not only communicate needs, they also communicate project status. By showing what was accomplished each week, progress can be seen by everyone, which will help the confidence level of the team.
Finally, break out separate updates to different groups and filter out the issues that each group needs to focus on. There are 100’s of issues each day on a game project, and artists don’t need to hear about design bugs, and programmers don’t want to see poly counts. By filtering out the noise, a producer can make a clear, concise update to each group and help to keep them focused on just their issues. This also creates separate e-mail chains, which will make is easier to track the communication progress on these issues.
Communicating Project Needs
Communicating needs is somewhat different then communicating status updates. Project needs are usually communicated more then once a day and project needs have delivery dates attached to them i.e. “I need this model by Friday”. It is very important to specify a delivery date with every request. Most of the groups that the producer is making requests to have many other projects they are supporting. This means that each group will set priorities based on when the request needs to be delivered.
A typical case is when dealing with the Legal Department. The producer sends a contract to legal for review. Legal has 20 other contracts they are reviewing. How do they know which one is more important? If the producer does not provide a “need by” date, then the request will go to the bottom of the queue and who knows when it will get done. By clearly specifying when the request needs to be completed much of the guesswork involved can be eliminated, and the producer can get verification from the group that they can meet the request.
If a delivery date is not specified for the request, then it is impossible to determine if something is going to be delivered late! It also makes it impossible to track progress as there is no date being driven towards. Always specify what the “drop dead” date is and get verification from the group the request is going to. When a producer has this verification, hopefully in e-mail, then they have a tool they can use to track progress with.
Producers should make sure to follow up at regular intervals to get the current status of the request that was made. The producer should try to have some communication on a request every 24 hours or less. This usually means some sort of simple e-mail reminder along the lines of “Hey, just checking in on the request for the sales demo. We are still expecting to receive that on Friday the 10th. Are we still on track?” This demonstrates the value of having specified a delivery date when the request was made. It allows the producer to check up on the status of requests by verifying progress is still on track to meet the expected date.
By reminding people of the date something was promised, it encourages them to double check their progress to insure they will still meet the delivery date. It also allows the person to adjust their initial estimates if they now feel that they are not on track and will not be able to make their dates. By checking up on things daily, it helps the producer find items that are sliding quickly, so that a contingency plan can be implemented.
One of the hardest parts of being a producer is figuring out what information to give to the team and what information to hold back till later. Sometimes there are issues that are not fully decided yet, so telling the team too early could cause unnecessary stress if the decision goes the other way later. On the other hand, the more the team can get involved in the decision making process, the more data the producer can collect which can lead to better decisions being made. The producer should get the input and advice of the leads when determining what is the best way to handle sensitive information by evaluating the impact to moral if that information is shared with the team.
Short daily meetings are a great way to update the team on the top issues and make sure everyone is moving in the same direction. As teams get larger, communication becomes more of an issues and finding ways to streamline communication is a key concern. The producer should have a leads meeting first thing every morning. This meeting should last less than 20 minutes and should have a simple agenda focused on going over hot issues and making sure those issues are being addressed. There will be both issues that the producer needs the team to address as well as issues the team needs the producer to address.
A producer will want to get updates on top bugs, tracking of core features, progress towards current milestone, and overall team confidence level. The team will want updates from marketing, sales, and the publisher. Daily meetings are also a good time to discuss any feature requests and how they impact the project. The goal of the meeting is quick information exchange: keeping everyone on the project updated, especially the leads that will then take that information and disseminate it to the team.
It is smart practice to end these meetings with a confidence level check: this is simply asking each lead how confident they are that they will meet the current milestone. This is usually expressed as a percentage chance of success and is an great way to check the pulse of each lead. If confidence levels are going down, it is important for the producer to find out why and start working on solutions to get people confident again.
Producers should also have a team meeting once a week. Fridays are a great time to hold this meeting and the focus should be: what was accomplished during the week and what does the team need to accomplish for the next week. This meeting will be about one hour as there are more people involved and more questions that need answers. For very large teams, it might be best to have a separate meeting for each large group, and then have a full team meeting once a month. It is very important to get the team together often to help encourage team spirit, and remind everyone that many people are working together for the same goal.
Communications with the publisher can be sensitive and needs to be handled with a great deal of tact. The publisher in many cases is paying for the game and has the right to stop paying whenever they are not happy with the state of the project. How the producer handles publisher issues can mean life or death for the project.
Producers should keep records of all project related communications with the publisher. The publisher usually directs the design of the project and the smallest request can have a very large ripple effect on the production of the game. Always keep every e-mail from the publisher, and use a simple organization system to keep things easy to review. One simple system is to build directories in Outlook for each publisher, then project, then SKU and move relevant mails to those directories. The producer should review these e-mails when new requests come in to look for contradictory information so they can communicate any issues to the publisher.
When replying to requests from the publisher the producer should make sure to clearly communicate how the request will impact the project. Sometimes the publisher will ask for something they believe is a “small thing”. The producer must make sure to quickly tell the publisher how much that “small thing” will really cost. When there is clear and honest communication on design requests, it allows the publisher to make choices based on the whole picture. If the publisher really wants a certain feature, they need to make sure they are willing to pay the price. This is a great way to manage the relationship with the publisher and allow them to feel more in control of direction of the game. By creating this open relationship, it will be easier for the publisher and developer to discuss feature changes.
Producers need to be careful not to instantly react when a request from a publisher comes in. Sometimes the publisher is just brainstorming, and will toss a crazy idea they got from marketing. Don’t panic! Take a step back, analyze the impact of the idea, and craft a calm, sweet e-mail to the publisher explaining the impact of the project in a fully objective way. Usually when the publisher sees the price tag of their new idea, they will back off and try a less costly alternative.
Take the passion out of the issue. Creating games is a very passionate endeavor, and it is passion that usually makes games great, but putting too much passion into an issue can cause conflict. It is important to not take things personally: it is just a game after all. Too much passion in a conversation can cloud the true issue and cause people to fight an issue just because the other side is fighting. Taking the emotion out of the issue will simplify the problem and allow cool heads to work out a better solution.
Studio Management Communication
Dealing with studio management can be both fun and challenging! Although studio management is on the same side as the producer, they are also the bosses and this can cause many issues for an unprepared producer. The boss does not want to only hear the good news, and many producers make the mistake of thinking this is the case. Good bosses want to hear how they can help the team: they want to know what is wrong, and what they can do to fix it.
The most important thing to remember when communicating with the studio management is to be honest. When a project has problems the best time to fix them are early, not later. If problems are not communicated to the studio execs in a timely fashion, they will not be able to react in time to help fix the problem. Also, when the studio managers have the same picture of the project that the producer and the team have, it makes it easier for them to communicate that status to others. Nothing is worse than making the boss look uninformed when they give inaccurate information to outside parties!
Each studio has a different structure, so studio management can mean many different things to different groups. Usually this means at least finance, HR, and the studio head. Some studios have their own sales and marketing department meaning even more stakeholders in the project. All of these outside groups exist to support the projects, so proper communication with them will give the project more resources. When communicating with studio management, make sure to be respectful when making requests. Usually the more managers, the more projects they have to deal with, so it is important to respect the managers’ time when making requests.
Finally, like all project communication, remember to keep good records of all requests and replies. Also, make sure to be careful when following up on requests to studio managers as they usually get annoyed with too many requests. Producers should ping studio managers less than once a day if at all possible, and be respectful in the follow up request. Instead of saying “I have not heard from you on this issue in two days”, keep the mails short and sweet with a simple “Hey, sorry to bug you, just checking in on this”.
A typical game producer lives in e-mail and will average over 100 mails a day. This is a lot of communication! Handling this communication in a clear and concise way will insure that everyone on the project knows how the project is going, and what their role in the project is. This will reduce “thrashing”: the back and forth that occurs when information is not clear, causing people to keep asking for “more detail” which slows the whole project down. By following the tips in this article a producer can clean up some of the communication that goes on and reduce the headache of managing so many moving parts. This will allow the producer to focus on what is really important: making a great quality game!