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