Team Structure Plus Stages Of Development

---

Preparing For The Inevitable

The process we’ve described here is designed to create an environment where everyone on the team has the opportunity to do the best work they are capable of. The schedule is sound, the budget is fair, and the deliverables are achievable. If the world were a perfect place, all game designers who followed this process would go home at a decent hour every night and have happy, stressfree lives. Inevitably, though, no matter how well you prepare, something will either go wrong, or turn out to take longer than you thought.

How you deal with a slipping schedule is as important as setting up a good process in the first place. First, understand that most software schedules slip. Usually, this comes from a combination of aggressive estimations up front and additions and changes to features during development. The question isn’t how can you keep your schedule from slipping—it will—the question is, what should you do about it when it happens?

Jim McCarthy, Microsoft team leader for Visual C++ among other products, has written a book on this problem called the Dynamics of Software Development. McCarthy describes many of the critical moments that a development team will face, including the inevitable slipping schedule. “When you slip, don’t fall,” he says, recognizing that slipping is a natural part of the process, but that good management of the situation can keep the team from falling, and from failing.

Some of the points that McCarthy makes include:

• Try to anticipate slips as soon as possible and communicate them to the team and the publisher. Re-define milestones before you slip.

• Keep the team psyche up—slipping is not failure; don’t let it infect the rest of the process.

• If necessary, prioritize outstanding features and cut those that are not critical to its operation.

Recognizing that you are slipping and being honest about it with the publisher is a tough problem. On the one hand, you don’t want them to lose confidence in you, so you want to put up a good front. On the other hand, if you completely blow a milestone, you really will lose their confidence. McCarthy’s policy advocates honesty—only you can know the limits of your relationship with your publisher and whether this policy will work for you. If possible however, an open and honest relationship with the publisher will save you the heartache of driving your team into the ground to meet a deadline, missing it anyway, and having both a pissed-off publisher and a burned-out team.

Keeping the team psyche up is one of the benefits to re-defining milestones with the publisher before they are missed. It’s true that working hard and achieving the impossible together will bring a team together like nothing else. But by going this route you risk not achieving the impossible together. Defeat and exhaustion are a killer combination. If you can find a way to redefine milestones before they are missed, so that your team is able to achieve the possible, it will keep the morale up and keep everyone focused on the next milestone, instead of reliving the last one.

Having to cut features in order to make a milestone can be a hard, emotional process. One way to avoid cutting core features is to prioritize them early on—before you start slipping—and make sure the most important ones are implemented early. Another way is to design the program modularly, in groups of features. So, for instance, if you just don’t get to the multiplayer components, your entire single-player game is still playable. If it does come down to cutting, make sure you involve the entire team, including the publisher and the marketing team. Features are the basis of how games are sold—you may wind up cutting a feature that could be responsible for a big percentage of projected sales.

The take-away from all of this is: be sure to put a good process in place, but when the project slips, be prepared to react quickly and efficiently to solve the problems and keep the project moving forward.

---