[Experienced game developer and manager Troy Dunniway, a veteran of studios like Microsoft, EA, Insomniac, and Ubisoft, discusses some of the major risks involved in transitioning from a small to large development team and how to identify and avoid them. This second installment tackles the nitty-gritty risks different disciplines will face.]

My earlier Gamasutra article Small Developers: Minimizing Risks in Large Productions - Part I talked about what general risks a small company might face as it tried to expand and take on larger projects. It gave a general overview of these risks: risks in running a game development business, risks in not having adequate or proper game preproduction, game development process risks which occur when you don't have a defined roadmap for how to work, and risks around your team members and staff.

In Part II, we will continue the article and dive into: schedule and project management risks which occur when you fail to properly schedule, risks involved in poor game design, art, testing and programming decisions and the risks involved in outsourcing. This article will focus on more specific problems on your projects which you must look out for.

1. Schedule and Project Management Risks

The risks of improperly scheduling a project are numerous and ongoing throughout. There is no right or wrong answer on how to develop or how to schedule. Some teams utilize a waterfall methodology; some use an agile method. Most use some kind of hybrid methodology.

No matter how you handle it, you will incur a tremendous amount of risk to a project if you don't schedule your projects, and you will also incur a lot of risks if you schedule poorly, fall behind, or make bad decisions in your scheduling.

Many producers just like to add a 20 to 50 percent (or more!) buffer to every task and schedule, allowing for unforeseen problems. While this is a good practice, it can't account for all problems. If you are scheduling the game or a feature you are working on, and know that there is some inherent risk in it, you should account for that from day one. "Plan for the worst; hope for the best," as they say.

The risks and solutions for how to properly schedule your game could fill an entire book. The important thing to keep in mind is that not scheduling your project, or doing it poorly, will usually lead to lots of problems. This is one of the reasons that larger teams usually employ one too many development directors, whose whole job is to manage the schedule for the project, or sometimes even just a team or feature.

The biggest thing you can do to avoid risks in scheduling is to establish a process where your leads are not tasked at 100 percent for the project -- rather, usually at 50 to 75 percent -- and can then safely spend time scheduling, hiring, managing the team, doing status reports, having 1:1 meetings with reports, and so on. Many teams expect their leads to be as productive on the project as everyone else, while also shouldering the additional responsibilities of being a manager. This tends to burn out leads more quickly and is a major source of aggravation for many.

If your team is too busy to stop and schedule, you have a problem.

2. Design Risks

Understanding when and how to make something extremely new and innovative and when to utilize existing technologies is an important decision. Many designers like to do things differently just because they can. Sometimes this can be good, but it usually leads to a project assuming the maximum amount of risk. It is good to understand what risks your game design is going to possibly impose on the project and how to minimize them.

Design risks can come in many shapes and sizes, so it is impossible to categorize them all. Things can be risky because the team has never done them, or because no game has ever done them. Things can be risky because they could require a lot of resources to do correctly, or because there are no tools or processes in place to do them. In the end, only the team can decide if there is a lot of risk or a little risk associated with each feature, and weigh in on how to minimize these risks.

Early on it is good to brainstorm wild and crazy ideas, but it is also good to put some limits on things and try to reduce some of the risk as soon as you can. This can include setting a limit to how many new things you are doing (I usually try and do no more than three to five new things in a project if possible), or putting a time limit on when the new stuff must be proven -- before you go to plan B, or cut it.

The design pipelines must also be identified for risks. You need to take a look at your tools and processes and make sure that they are optimized to let designers create, tweak and balance content as quickly as possible, as well as allow the maximum number of designers to work on the same stuff as possible. The design tools problems are especially amplified for open world, role-playing and other less linear and more complicated games. If your tools pipeline isn't optimized, you run the risk of the design team not being able to start until others have finished, getting behind, and then not being able to catch up -- forcing the game to be delayed.

It's especially important to remember that designers are also majorly at risk from others on the project falling behind and delivering their assets late. Since the designers are usually the last to touch a level, and do most of the assembly, they are much more susceptible to problems faced by the entire team. Designers must try and ensure that the other teams stay on track.

In the end, making the wrong design decisions, and having a game director that is going to force the team to do them regardless of what everyone else thinks, can be a massive risk to the project and should be avoided at all costs.