Rein in enthusiasm? Now why would we ever want to do that? Isn't keeping the team motivated one of the most important factors of game development? Doesn't every management book you've ever read stress how important it is to keep the team motivated?

The thing is, almost by definition, videogame developers are motivated. I've never seen a videogame where the developers didn't want to put more features and content into the game than they could possibly have time for. Motivation and enthusiasm, in this industry, is just about a given. Where this hurts us is when:

• We do a bunch of things halfway and don't have time to take them all to completion: we might have been able to finish one whole level in the time it took to do those two levels halfway.
• We save bug-fixing for later, and the cost of fixing those bugs goes up.
• We cut corners and work inefficiently.
• We do the wrong things: our pet features, or the publisher's pet features, instead of what's important for the game.

We need to rein ourselves in. We could tell everyone on the team that they suck and their ideas are valueless, but that may be going too far in the other direction. Here are a few good ways to apply reins without turning the entire team into a bunch of listless zombies who just phone it in.

Schedule Well

Finally my column gets to schedules. Why did I wait so long? Given a choice between doing something right and doing it on time I'll take doing it right, and schedules can create the wrong kind of mentality, encouraging people to rush crap out the door. Still, although I don't place the priority on schedules that others do, if we want to do things right and on time they are a useful tool.

One thing we almost always see in the "What Went Wrong" column of a lot of postmortems, even ones for successful games, is "we had an impossibly aggressive schedule that led to much crunch-time and cutting of half-assed features." Let me play devil's advocate for a second: maybe this aggressive goal setting is actually making these projects more successful, because everybody's putting in 110%, and nobody is gold plating? Steve McConnell would shoot me for saying that. Aggressive schedules make projects later, not earlier, he claims, because the cut corners reduce efficiency.

There is one team that backs up McConnell, that has successfully shipped two great games on time in reasonable timeframes that does effectively schedule: Monolith, with their No One Lives Forever series. I'd like to believe that if everyone followed their example we'd see more great games.

But in Monolith's postmortem they did not go into detail in the techniques they used to schedule their project. The best technique I've used for scheduling programming comes from Joel Spolsky. We've used his system to schedule coders with great success. It's always surprising when you implement it, and you realize just how few features you're going to be actually able to finish before your code complete date. That realization is when you begin to know you're being realistic for the first time.

But having a system in place does not guarantee success. I've seen teams using the schedule system fail, and the reason seems to be because it was not maintained. Just making sure everyone reports their progress every day is not enough; when unplanned features rear their ugly heads, they have to be added to the schedule. And when dependencies exist, they have to be reflected in people's priorities.

Some people, such as Erik Bethke and Mike McShaffry, use MS Project to track their schedules. That's fine, as long as you maintain it. I've tried working with it and it wasn't for me.

One thing Spolsky, Bethke, McShaffry and myself agree on is this: the people doing the work must estimate their own schedules. We can coach them on how to do this; we can help them break a task down into subtasks; we can even - very rarely - ask, "Why is this going to take so long?" when our intuition tells us to. (Usually it's because the developer wants to do a better job than they have to.) But the buck stops with the individual developer. They know the systems they're working with; they know their capabilities; and they need to buy in to the schedule they're going to be working under.

Avoid Multitasking

When you can avoid it, don't let a developer switch from one task to another until the first task is complete. It sounds obvious, but the temptation is extremely hard to resist in practice. When you're working on a videogame, everybody wants everything done yesterday. "When are the drop shadows going to come on line? Why isn't combat fun yet? We need to get the beginning of the game done, because that's the hook that sucks the player in! We need to get the end of the game done, because that's the climactic finale! We need to get the middle of the game done, because Noah Falstein says so! (See Noah Falstein's Begin at the Middle.) In this kind of chaos, priorities shift before tasks are complete, people are moved off task, and you end up with a lot of half-assed features and nothing fully-assed. This is compounded by requiring multiple people to work on features. When the feature gets handed to person B, he either needs to go off-task to work on it (gasp!) or he needs to let it sit idle (gasp!)

So how do we do it? Just Say No. Educate all the people on your team about why they shouldn't be switching tasks, and when you see somebody who seems to be task-switching, call them on it. Look through the schedule for people who have a few tasks that are all partially complete. Usually there's a good reason for why they were unable to complete the original tasks, but it's worth looking into. When asking for a small unplanned feature or a bug report, make it understood that you don't need it immediately. "When you get to a good stopping point, can you do this for me?"

Have A Focus

More than a few successful projects in the Gamasutra postmortem files mention having a "focus" or a "vision" or a "mission statement", including No One Lives Forever ("We drafted a clear, concise mission statement to make sure we wouldn't lose sight of our goals."), Ratchet and Clank ("There's a solid structure in place to ensure that we adhere to the macro design and remain consistent with the game's "flavor."), Rainbow Six ("We established early on a vision of what the final game would be and we maintained that vision right through to the end."), and Deus Ex (Their vision is printed in their postmortem.). A friend of a friend (isn't everybody in this industry a friend of a friend?) said one of the first things they did when designing The Two Towers was ask, "What is the 'it' of this game going to be?"

There are many reasons to have a focus, but the one we care about here is this: feature creep is easily curtailed when people - either on the team or from the publisher or marketing department - suggest features that are nonessential to your core gameplay. "That's not what our game is about," you say, and you move on.

Scott Adams has made a joke out of it: when Dilbert answers the phone at the company without a mission, he says, "I don't know if we do that." When he answers the phone at the company with a mission, he says, "We don't do that." It's no joke. You want to be able to say, "We don't do that," for as many features as you can.

For what it's worth, the vision for the yet-to-be-completed Spider-Man 2--which creative director Tomo Moriwaki explained to the team in shifts because we can't fit the entire team in one meeting room--is focused on the way Spider-Man moves, with combat playing a mere supporting role to that central actor. Other traditional elements of Spider-Man, such as his photography, his spider-trackers, and his alter-ego as Peter Parker, are almost ignored so we can focus on One Thing. We'll see how it goes.

What Jake Was Doing In Chinatown

The pressure to add new features and keep half-assed features and not cut people's pet ideas is immense. They'll imply that you are lazy. They'll ask you, "How much time will it take?" (Eric Bethke's correct answer to, "How much time will it take?" is "Let me get back to you." Don't just get back to them with how much time it will take. Get back to them with a list of other features you can cut to make the feature they want happen. It helps for people to see the real trade-off.) They'll ask you, "What are the risks?" Push back against these forces. Remind people what Greg John, my producer, has posted on the wall of his office:

Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take away.