Project Realities

Beyond just plain number- crunching and estimating, there are intangibles that management should be aware of and plan for. Most developers are already aware intellectually or emotionally of these intangible issues, but few work them into development before works begins, feeling they can be addressed if and when they become problems.

Of course, most of these intangible issues become active at some point in the development cycle and can have a significant effect on budget and timeline.

We've already discussed basic budgeting and costs. If you're building a major PW from scratch, you know you must plan for between $5 million and $10 million in a development budget and between $2 and $5 million for the launch. Those are just the basics; what else is involved here?

Budget for Shortfalls, Time Crunches, and Morale Perks

It is almost a given that your project will cost more than you budgeted for. We've seen shortfalls ranging between 5% for well-organized projects to a full 100% from the planned budget for disorganized projects, usually involving inexperienced teams . This is an unusually wide range and the reasons for it are many; if you're just skimming the text, see the rest of this chapter for some examples having to do with the inexperience and culture of the industry as a whole.

You also have to plan for the regular budget-busters that any industry or business can experience: losing key personnel, "crunch" times that require huge amounts of overtime pay, finding out someone lied to the stakeholders, morale perks to keep the team's attitude up, and ridiculously low funding levels from the start.

Have Backup Plans for Your Personnel

If you work in any part of the computer industry, it will come as no surprise to learn that the game sector has more than its fair share of unusual people and personalities. The folks who create spreadsheets and word processors can be rather nontraditional. The people who build software games are like them in many ways, except that game developers are in a sense creating entire new number systems and languages to go along with their products. They are motivated by a need to creatively express themselves through the left-brain activities of designing games and producing elegant art through design and source code, and they have spent time and energy to acquire the right-brain discipline and rigor that is necessary to actually produce that code. There seems to be something about managing/balancing the competing demands on the two hemispheres when operating at a high enough level to deliver the quality that is demanded by today's PW game subscribers that tends to produce half-mad, flaky, iconoclastic geniuses in what would be alarming numbers for any other industry.

Ask any CEO or manager in this business and he/she will have a story that demonstrates how this can work against you. You might hear a story about a key person on a development team who disappeared for days during a critical portion of the project, only to return as mysteriously as he/she vanished, with little or no explanation about where he/she was or what he/she was doing. You might hear about a lead programmer grabbing the only complete copy of the source code and simply disappearing for weeks. That one happened to CEO Brian Fargo of Interplay in the mid-1980s, when the lead programmer on Meantime , the sequel to the popular Wasteland computer role-playing game (RPG), disappeared with the code. Fargo had to hire a private investigator to locate the man and retrieve the source code. There was no explanation from the lead; it just happened. It took so long to find him and get the code back that Meantime basically died as a project. Other stories run the full range of flakiness. On one end, there are the more or less normal tales of critical personnel being arrested for a variety of reasons and the company not finding out for days or weeks. At the other end of the spectrum, there are strange sagas of programmers not leaving their offices for weeks on end and coding 24 hours a day, in the end emerging with code that had little or no bearing on the game and so mentally burned out that they were useless for days or weeks afterward.

Then there is the more normal attrition, such as another company hiring away a key person at exactly the wrong time or someone just plain burning out from overwork. People working in computer games, and the technology industry as a whole, are notoriously mobile; good people receive offers on a regular basis and change jobs often. This often happens in conjunction with burnout; people convince themselves they are burned out because they work too hard for people who don't respect them or their work.

All of this is not at all unusual in the game industry; it happens to most teams. You need to plan redundancy into the team for the key personnel. This is not something most development teams plan for, and it usually comes back to haunt them. Redundancy is expensive. In this business, though, it is also expensive to lose someone at the wrong time and have everyone below them in the organizational chart getting paid for doing less than they would otherwise do while you locate a replacement and bring that replacement up to speed.

You saved money by designing early, waited until the right time to hire the right amount of expensive coding talent, got everybody to document their work, and the one person you have who is competent enough to manage the proper testing that you spent your savings on just joined a cult that preaches against the evils of computer games. Yesterday you were about six months and a day away from launch. Today you're about ready to launch your lunch ”or join that cult. Redundancy is the key to building an effective team.

Lies to the Stakeholders

Another characteristic of development teams is that they can and will lie to stakeholders up the chain of command. They lie for a number of reasons, but most typically for the two reasons any executive would or should expect: The project is going to slip the ship date and/or run over budget.

The wizard/guru effect makes lying easy to do, both before and during a project. For example, it should not surprise anyone that project leads and design teams often understand up-front that they can't possibly turn out a game in the time they say they can. It has become relatively standard practice to estimate a development timeline and budget that executives want to hear and are likely to approve, and then later come up with a variety of excuses as to why the ship date has to slip or go under unless the project spends more money. This is not to say that it happens every time or that there aren't legitimate reasons for some slippage in any project. However, it happens with computer games quite a bit more than it does in other software sectors, and under the leadership of people who should know better.

Also, we should note that the lying is not done maliciously; teams have a way of rationalizing the deception by convincing themselves it is for the good of the game and the art, or by convincing themselves after the fact that it wasn't really a lie ”it was a best-case scenario that had a series of encounters with the typical world. Who could possibly anticipate everything? We gave it our best shot, really.

If senior management educates themselves, such deception is harder to achieve. On the technical side, the managers will know a little more and will be more likely to detect unrealistic assumptions and/or projections. On the human side, if managers really care enough to go to the trouble of learning more about game theory and the technology behind the magic, it becomes more difficult for the developers to rationalize deceiving them. The message to teams is simple: Executives aren't scared of three-year projects and large budgets if you can make a case that the ROI will be there at the end of the day. Executives are scared of being saddled with yet another team that goes over budget, delivers less than the milestones, and lies about delivery timelines .

Don't Pinch Your Product to Death

It is the nature of every business to pinch pennies because every penny spent comes off the profit margin. This seems to be especially true of large online game projects. In the main, this is because of a general misunderstanding of the true nature of the full costs of development and launch. The knowledge of the true costs is spreading slowly and will probably become general knowledge within the next three to five years .

In the meantime, it is important to understand that you need to go into such a project with a full commitment to spend what is necessary for success. As noted more than once in this chapter and throughout the book, understand thoroughly that an online game is both a product and a service and plan to act accordingly . Most managers underestimate or completely forget the budget for the launch phase until well into the test phase and have to play catch-up for months, often until well after the launch phase is completed.

In short, you have a major breakpoint on cost control and spending: the planning you do before development begins, which, if done correctly, should give you a number plus or minus 10 “15% of your actual costs right up through launch.

Crunch Time

Online games tend to have many more milestone deliverables than other computer/video game projects, due to the extended development timelines and levels of detailed work that are required. As with any other software project, work tends to lag a bit early into a milestone as delays set in. As the delivery date for the milestone approaches, teams go into "crunch mode," working longer and longer hours to ensure the milestone is delivered on time. Depending on when the decision is made to go into crunch mode, features tend to get pushed back to the next milestone, creating a cascade effect until the team can end up in perpetual crunch mode for the last few months of a project.

Considering that currently almost all milestones in every project tend to lag, this means the team will probably be spending a significant amount of time in crunch mode almost from the start of the project, with serious and predictable effects on burnout and morale. Both of these are high-risk factors for losing personnel mid-project.

There is probably no way to completely eliminate the need for crunch mode because there is just no way to fully eliminate unexpected delays. The best you can do is to make sure the design phase is completely finished before coding begins and be flexible about trimming features earlier in the process, rather than later. You'd also be wise to actually work a number of replacements and their training time into the budget.

Morale Builders and Perks

As previously discussed, two of the recurring problems you'll face over a three-year development cycle are employee burnout and sinking morale. These result in delays and people leaving the project before completion.

If you're smart, you'll budget morale perks into the mix from the start. Most companies do try to have something in the mix, but these rarely go beyond the standards of having meals catered in during crunch time and setting aside a small budget for occasionally buying cheap gifts or dinners for selected team members . On a project as long and stressful as an online game or PW, these aren't nearly enough. Thinking outside the box on this can be a major benefit because a relatively small amount of money spent creatively in this area can save you an enormous sum over the life of the project.

Granting the entire team a four-day weekend for successfully achieving a milestone feature-complete might seem like a wasteful expense of hundreds of person-hours, but it rests and revitalizes the team after a stressful period, rewards success, and gives them an incentive to do it again. Or, you could have a "milestone dinner" and hand out a few $500 bonus checks to people who went above and beyond expectations during the milestone.

Perks are only one part of it. Actively working to build and maintain morale over time is a necessity. Anything (well, almost anything) that breaks the stress and allows people to concentrate again on the tasks at hand is worth exploring. After noticing that the stress in the office was building to high levels where she worked in the mid-1990s, one of the authors stopped at a Toys 'R' Us, bought 20 cans of Silly String, arrived early at the office, and left a can on the desk of each team member. By mid-morning, after a series of battles that are still commented on from time to time, every surface in the office was covered with Silly String and every face was plastered with a silly grin. You can imagine the effect it had on team morale and the leveraged value of the money spent.

The lesson to be learned here: The producer and project manager are in charge of team morale. They need to pay attention to what is happening and should step in before things hit the boiling point for the team or individuals. All too many leaders forget this and pay the price.