Managing Risk in a Team Environment

Team work is an inherently risky endeavour. Leading a team can be challenging, whether it’s mistaken ideas or a communication mix-up. Team members present a risk to each other, as well. What should happen if someone disappears? If they have to leave the project, what will happen with their work? Would the project continue if they left? Knowing the risk your teammates provide to the project as a whole can mean you will make smarter management decisions and prepare for the worst to happen.

Documentation

Documentation is critical. If someone disappears and is replaced, what will you show the newbie to acquaint them with their predecessor’s work? All of your teammates should provide up-to-date and comprehensive documentation for their work. We all mostly think of the GDD when considering this, obviously a comprehensive document will explain the design of the project, and touch on everything else, but your artists, programmers and level designers (etc.) are each responsible for solid and comprehensive documentation for their work, and their parts in the project as a whole. Artists will create an Art Bible to detail each of the design decisions that lead to their final product, and define the scope and features of their art. Programmers will create a Technical Design Document to define the scope of their work, the specific functions and breakdowns of their systems – enough that anyone can figure out how their systems work and can acquaint a newbie as quickly as possible. Level Designers will do the same, each of their levels must have a detailed paper trail of their ideas, concepts and changes. By keeping comprehensive documentation, it’s easier for newer people to pick up and get going on top of their predecessor’s work.

Buddy System

Another practice that programmer’s use for complex systems is the buddy system. Each programmer will explain their exact system and implementation to another programmer. Just like you would get others to proofread your written work, having another person proofread your code will allow them to share ideas, or find mistakes that you’d miss. The phrase for this in Industry is that if someone get’s “hit by a bus” there is someone else who knows how that person’s system works, and can continue their work.

Prioritising Features

Another way to preserve a project’s development is to ensure that the core features are the highest priority. Core features of your game should be the most critical ones to complete, and by creating a Minimum Viable Product, you can ensure that you can still ship something if things to awry. When defining the backlog of your project, ensure that the most critical features are scheduled first.

These three systems can help teams manage the risk associated with teamwork while developing a product. In the end, you cannot predict everything that happens on your team, but by preparing for the worst, you can ensure that your projects will survive whatever happens along the way.

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

w

Connecting to %s