7.14 hot potato projects
When you find yourself in a position to take on a project like this, there is usually something inherent in the project that is too compelling to walk away from. Often, these titles have had so much public exposure that the publisher or license holder is too embarrassed to just let them die. Perhaps (better still) there is someone high up in a publisher’s organization somewhere who just really believes that this game can be great, if only it sees the light of day. Your best bet is to first dig deep to determine why this project is still alive. Who needs it to ship? Whose egos are wrapped up in the matter? Is there a genuine product champion somewhere at a high level who is a true believer? Make it your first mission to find out why this geriatric beast refuses to lie down and die, and it’ll help your chances to succeed where other teams have failed. Second, dig into the case history to understand why it hasn’t shipped yet. What went wrong for the other teams that worked on the project? Is there something inherently difficult about the material? Is there an unreasonable license holder who keeps scuttling the deal? Has the history of this game really just been the proverbial sequence of unfortunate events or is there more to the story? (There usually is.) It’s tempting for people to just declare that the previous team was a bunch of idiots and dive right in. Look twice; a project that has been around awhile has likely had plenty of smart people involved in it. Avoid arrogance and really strive to understand why they failed to succeed. Next, take a good look at the technology, code, and content that is being handed down. One common cause of serious overages and miserable development cycles is the problem of the “cursed inheritance.” It may well be that working with an inherited code base, design, or set of content is making this project far more difficult to complete than it should be. It can often be the case that trying to understand, retrofit, and patch up poorly written code, or code that is unsuitable for a particular problem, can be much more time-consuming than starting fresh with more suitable technology. Is this a possibility here? Finally, take a serious look at the schedule and the list of product specifications. Ideally, you’ll do this before committing one or more teams to building the project. Try to apply a sharp and ruthless razor here to carve out the truly critical from those features that are just interesting or whose value is in doubt. Any game that has been around awhile usually carries a lot of old baggage with it, from the days when it was young and everyone involved still dreamed big, perhaps even so big that the promise of what the game might be ended up choking it to death. For a project like this, until you’ve understood the four aspects described previously and redesigned your approach accordingly, there’s little value in bringing on distributed teams to help. Shrink the number of key decision makers until you’ve turned this beast from a nightmare project that keeps getting passed around into a sober and manageable set of specifications and technologies. Once you’ve gotten buy-in from everyone who matters that the new, streamlined version of the software you propose building is something that the organization can live with, then you can start thinking about bringing in additional outside help to do the production work.
207