Balancing Creativity with a Schedule

Recognizing and dancing with the factors of creativity and timeliness requires a delicate balancing act on the part of management. Knowing when to put a lid on creativity to maintain a schedule (because time is money in the business of online games , in the form of salaries, overhead, and missed sales) is a management skill comparable to defusing a bomb or playing high-stakes poker. An appreciation of the technical aspects involved with the decision can be a lifesaver. A delay of a year means additional costs of somewhere between $1 million and $3 million; capping any possible unnecessary delay becomes a matter of profit versus loss.

The other side of that coin is that you can't be sure when a designer's crackpot idea might not be the next big thing that makes the company filthy rich. Not very many companies would have taken a chance on a game like The Sims , for example; the idea is just too "out there" for many of us to grasp as a design concept. In most companies, the design proposal would have been laughed out the door. Yet the game has sold more units than any other PC game in history since it shipped in 1999, and the expansion packs continue to sell like there is no tomorrow.

The question becomes, then, how to balance creativity to a schedule. Unfortunately, there is no hard and fast rule; if there was, there would rarely be production delays. However, there are some things you can do to limit the risk.

The Importance of a CCP

The front line in controlling potential production delays is the CCP, making all additions and changes to the design go through a vetting process to make sure you aren't breaking something or adding inordinate amounts of time to the schedule. Establishing and, more importantly, enforcing a CCP will cause developers to think in-depth about a change or addition before it is brought up seriously as a proposal. Once such a proposal is run through the process and other team members get to respond to it, you'll often find hidden traps that prohibit its addition or, conversely, convince the team and management that the change is worthwhile, even if it costs more time. The important thing is that the process is controlled and structured, instead of getting the team into a situation where designers or developers are throwing features at a wall to see which ones stick.

Enforcement will be an issue. You can take it as a given that most of your team will loathe the very idea of a CCP until they see how it works and recognize the benefits of less wasted time and a more stable product. The opposition will probably take the form of just ignoring it, with one or more of your people figuring they'll slip in a feature or change and no one will be the wiser. Besides, when people see how utterly cool it is, no one will care, right?

Most times, the bad side-effects of this kind of activity will be apparent, and it will be relatively easy to point out to the offender just what was broken or delayed by skipping the CCP. Sometimes, the feature will be very useful and popular, adding to the game without breaking or delaying anything. What do you do then? The answer is: You keep the feature and reprimand the offender for bypassing the process, and then you have a talk with the team about the process. It doesn't matter how good the feature is or how valuable the team member; without enforcing the CCP through both reward and punishment , you might as well not have one and accept that there will definitely be delays, not that there might be delays. Everyone has to know that the ultimate penalty for violating the CCP can and may be termination.

And what about the reward? How about bonus checks, or something else special and unique to the team, when milestones are hit on time and the CCP has not been violated?

Do You Know What Your People Can Do?

Another part of controlling delays is knowing what each of your people can accomplish in a given period of time. You start by understanding that game developers almost always overestimate their own productivity, and then ratchet down on their expectations and assertions based on your experience with them specifically and your experience in the industry in general. That may sound callous and jaded, but it has also been the experience of the industry to date. To be perfectly blunt, most developers are pretty arrogant about their own abilities , whether that arrogance is warranted or not. It comes with the territory, and you need to understand and be aware of it. It doesn't make game developers bad people; it just makes them game developers.

For a scratch team composed mostly of people you haven't worked with before, this can be hairy until you've seen what the people can do. It can be a nail-biting exercise as you try to limit the amount of work the team member is responsible for until he/she shows his/her capabilities, balanced against the need to keep the project moving forward. The only advice that can be given here is: Make sure your team leads are highly experienced , can recognize chronic non-productivity, and are willing to pull the trigger on a non-productive team member early. The longer you wait, the worse the damage. Pulling the trigger may take the form of a private conversation to make sure everything is all right at home, or worst case, replacing the team member if there is no good explanation. Much as we hate to face it, some people just don't fit with a team and sometimes have to be fired . No one likes to do it, but it is necessary, sometimes.

For a hand-picked team, basic non-productivity or inability to do the work probably won't be an issue; you've worked with them before and know what they can do. Any lack of productivity or delays are probably due to outside factors and can likely be remedied just by talking through it and perhaps giving the team member some time to get things worked out.

Task Slippage: Who Really Controls the Project Timeline?

This is as much a command and control issue as anything else. Depending on the composition of your team, either the producer or project manager controls the milestone timeline. This includes the responsibility of keeping the task completions, progress, and dependencies on the tracking sheet fully updated and keeping the leadership and team informed of where the blocks and potential blocks are or are likely to be.

If this responsibility is being fulfilled, even a casual glance at a Gantt or PERT chart will clearly show what tasks have been finished, which are delayed, and what other dependent tasks those delays are slowing or halting . The whole purpose here is to provide ongoing tracking and accountability and prevent sudden surprises . There's nothing worse than reaching the first Alpha test and realizing that the developer who was supposed to spend two weeks writing the login server code wasn't able to because other small delays slowed down his/her other tasks. With a properly maintained and tracked timeline, this kind of surprise won't happen.

This also assumes that the producer or project manager is actually in control of the timeline. All too often, one or more of the leads is allowed to informally control what is actually worked on or is a current priority, regardless of the plan or CCP. The responsibility and authority remains with the producer or project manager, but the accountability factor becomes skewed. Individuals remain accountable for their own tasks, but the overall accountability for tracking and planning is now in question.

Nothing can rip a team apart faster than fuzziness or lack of control in the command chain. If an individual feels that the accountability and responsibility are being unofficially shunted sideways , it becomes tempting to realign the workload to the more "fun" stuff with an equally informal, "Hey, I thought I'd work on this instead; is that okay with you?" to the "informal" leader. It doesn't take much of this to undermine the integrity of the timeline altogether.

Game development teams are notorious for this, based on the theory that everyone is friends with everyone else and it is (or should be) an egalitarian system. There may be the occasional team that can work this way, but not often and not many. It is nearly impossible for 30 people to decide on what to have for lunch , much less come to a consensus on priorities and work tasks.

Hammer-Time: Does Crunch Mode Really Make Up Time?

Inevitably, for a variety of reasons, work on milestones slips. As the date to deliver the slipping milestone approaches, teams try to make up for lost time by going into crunch mode. To go into crunch mode means to work more days per week and longer hours on each of those days. It is the game industry's answer to the question, "How do we make up the time we lost fiddling around with neat stuff three months ago?" It has become so endemic that producers actually plan crunch mode time into the schedule. This is akin to the old saw of losing money on each transaction but making it up in volume; it doesn't work very often.

No one ever wants to go into crunch mode; it is a debilitating exercise that, at its peak, sees developers sleeping on the floor of their office for days on end, gulping chips and Jolt at the keyboard, and staring at the monitor with exhausted, baggy eyes. On a personal level, the exhaustion leads to more bugs that need to be fixed, wasting even more time. It also takes days to fully recover from crunch mode ”days of lower productivity that add up to more crunch mode time at the end of the next milestone.

On a team and project level, more time spent in crunch mode tends to lead to more time in the test-fix-test cycle, which means ”you got it ”more delays.

Crunch mode can be useful if used in moderation , and it may be necessary at the end of the development and test cycle just to clean up unanticipated problems. Planning crunch mode time for every milestone, however, or being forced into it continually to make your milestones should tell you something about your design, planning, work load, or team culture/team psychology. If you're in the middle of development and in crunch mode continually, it is time to step back and take another look at your plan and design.