Gear Information and Presentation Towards Your Audience

You will need to present key information with multiple methods (email, meetings, face to face), to make sure that everyone knows about it. This is especially true for critical information such as key deadlines for checking in updates to the build, project review dates, and so on. If you are dealing with sensitive issues, you will want to handle these privately and keep it on a need-to-know basis.

Consider which method of communication will be optimal for the type of information being communicated. For example, if the project schedule is going to be pulled in by two weeks, it is better to initially communicate this information in a team meeting rather than an email. The meeting will give the team an opportunity to get answers to their questions right away. You can then follow-up the meeting with an email containing the key information. If you are providing the regular weekly status report to the team, it is probably fine to email these -- as these are not mission critical.

You also want to tailor the information to your audience. For example, management is more interested in big picture items -- is the project on schedule, what are the key risks, how much money do you need? The team is focused on things that affect their day to day work -- when will the PS3 dev kits arrive, when will the Unreal engine SDK be available, what features have be changed?

So if you are giving a status report on the project, make sure you address the areas that will be of most interest to your audience. The entire design team doesn't need a detailed and technical explanation of scripting -- that's only for the designers who are actually going to use the tool. The other designers only need to know what types of things the tool does.

Central Location for Publishing Team Information

Once you put forth all this effort to improve your communication pipeline, make sure that the information is accessible to everyone. A team wiki is a great place to store meeting notes, track key deadlines and feature changes, and post bios of new team members. If everything is archived in the wiki, people have the luxury of digesting all of the information on their own timetable.

Get Specific

As discussed earlier, provide specific information with all your requests. Make sure people fully understand what is being asked of them. This includes defining specific deadlines, the number of assets needed, details on requested changes (who asked for them, what needs to be changed, when the work is due, etc.) It is a great idea to have people restate what you told them in order to make sure that you are on the same page.

Ask for Feedback

Most importantly, be open to improving your communication skills by asking for feedback from your peers. There is always room for improvement and feedback provides a good gauge on what areas you can improve on. You can do this by casually asking, as you walk around and chat with your team, or you can schedule brief one-on-one sessions to discuss the feedback more privately. In any case, be aware of how people react to you and try to be aware of ways you can improve how you communicate with people. Also, once you have feedback, make changes based on the suggestions. It is pointless to ask for feedback if you don't plan to make any changes.

Conclusion

It is important to note that you should constantly be aware of communication issues on your project, because they will never completely go away. Things are constantly changing on projects -- scope, personnel, priorities, features, deadlines, managers -- and these things all have an effect on the communication pipeline that you work so hard to define. I encourage you to be vigilant on the communication front, as this is an area where small improvements go a long way and have a big impact on the overall project.