Why Production Slips Happen
If you've been reading this section
, you already know the reasons for most development time slips:
A feature set that was overreaching from the start and needed more time than budgeted to complete
Inexperienced management and senior management that doesn't have a firm grasp of what is possible and what isn't in these types of
, and consequently can't act as a brake on overreaching ambitions
An overly complex set of game mechanics that is tougher to balance than originally thought
but overly enthusiastic) developers who overestimated their ability to complete
in the time they forecasted
Developers who try to add features
, without following a change control process (CCP), which almost always breaks something else in the game or throws the balance out of whack, requiring even more time to fix
Each of these five issues, taken
, is pretty easy to avoid or fix. Combine them all into one project and the developers might be
a few sleepless nights and a lot of frustration. "Fix" the five points before development begins and you'll avoid most of the production slips that many online game projects have experienced.
Steps You Can Take to Avoid Common Problems
These steps, of course, require some changes, beginning at the top and working down throughout the entire organization.
Step One: Educate Senior Management
One reason so much money is
during development is that it's so darn easy for development
to mesmerize and buffalo senior management.
The wizard/guru effect is most definitely
and well at game companies. The wizard effect is the tendency for those with esoteric or hard-to-acquire knowledge to act like wizards and magicians of old, making tricks happen and counting on the
of the audience not to do enough of their own research to understand the illusion. The same thing happens today at publishing companies. Very few people at and above the vice president level have even a rudimentary understanding of how Linux, C++, distributed computing, game design, game mechanics, TCP/IP and UDP, and so forth work or what the tradeoffs are. They are held hostage to the knowledge of the wizards. They live and die by the opportunities the wizards present to them and by the choices they make. Without a basic understanding of how the magic really happens, management really has no choice but to approve the wizard's agenda, and that agenda does not
”or even mostly ”coincide with the good of the game.
This is easily
with a bit of personal, hands-on research. You don't have to be a UNIX guru to install it on a machine and walk through a book on working within the UNIX environment. Nor do you need to be a wizard to pick up a book or read online articles on game design theory to understand one or two designers' ideas about the tradeoffs between features and usability. If you are in management, you can probably get the company to pick up the tab if you then take some of your designers to
and get them to discuss their ideas. Their ideas may be in line with the ones you just read about, in which case your new understanding of game theory will be firmer. Their ideas may be
from the ones you just read about, in which case your understanding of game theory will be wider. In either case, you will know more than you did. Just having a basic knowledge of wizardly lore gives the senior executive a technical edge in this market. You are less mesmerizable. Going to the effort of learning a little, being able to discuss the basic issues, and getting people in the trenches to teach makes you better prepared to make key decisions more quickly and more likely to choose well. On the human side, this activity can
substantial respect from developers. By being less mesmerizable, interested in their work on a basic level, and willing to learn, the wizards may not invite you into their ranks, but they will be more likely to regard you as a worthwhile part of the overall process.
Another part of the education comes with knowing who the players are and what they want. In more traditional industries, senior management actually gets out of the office on a regular basis and mingles with the customers. Herb Kelleher, co-founder and former chief executive of Southwest Airlines, would regularly fly his own airline and speak to passengers about how they felt about the service. It worked; under his leadership, Southwest won the airline version of the Triple Crown (Best On-Time Record, Best Baggage Handling, and Fewest Customer Complaints in One Month) over 20 times. Being face-to-face with customers, talking with them, and experiencing what they experience about your product or service provides knowledge that is a key advantage.
In the online game world, that means senior management has to get down in the trenches with the players. It isn't enough to have your people hold focus groups and then watch the tapes; you have to play the game consistently and come to understand its strengths, weaknesses, and what needs to be fixed,
friendships in the game, participate in the action, and get to know just who these people are who are giving you money month in and month out. How else are you going to know what works and what doesn't the
time you have to make a decision on spending millions of dollars on an online game?
Step Two: Foster a Culture of Organization
Equally important as education is creating a culture among development teams that respects the concept of organization. Most development teams don't have that respect. They have just the
, in fact; they are cowboys and like to shoot from the hip when an idea occurs to them. They feel that trying to "overly" organize them simply limits their creativity and ability to add to the game and make it "better" during development or during the live phase.
This has to change industry-wide or we'll continue to suffer bad launches and subject players to on-the-fly
and cowboy programming. In this sense, "organization" means a culture that understands that the preparation phase must be fully completed, including the design, technical, and project plan documents and the CCP. Additionally, the culture must understand the need to follow those documents and concepts through to the end of the project.
Because development teams
regard this concept with antipathy, time must be invested to educate them on the benefits of detailed planning and change control. After seeing evidence that your developers appreciate the benefits of these important processes, you still need to build among (and with) them a consensus for actually using them.
Game developers tend to uphold a code of behavior,
among many early programmers (and not yet eradicated by management), that says that commenting/documenting code is
the station of the programmer/artist. There may be a strong correlation between the populations of professional programmers and students who were
at getting answers to math problems but hated to "show their work." When programmers are
, as they were for general business in the 1950s and 1960s, management is reluctant to insist on program documentation. Usually, the fact that the program or module works is more important to management than how or why it works. Because mystery adds to programmers' financial value and acts as a buffer against being
, programmers, being human, tend to resist showing their work. As programmers become more available, management can afford to demand to know the technology behind the wizardry. Getting your developers to embrace detailed planning and an organized CCP may be an evolutionary process, and you should be prepared to resell the benefits if old habits present
. You may need to
, or even remove, "stars" from your team if they do not
embrace your view of the necessary organizational culture,
if they consistently
senior management and fostering a culture of organization in your process will save you much
in the short and long terms.