Response to The Escapist - Extra Creditz: The Pre-Production Problem

Hey there everybody! Joey here, back for another round of riveting Full Sail UXL Internship blog posts. The topic this week? Pre-production.

On 7/28 one of my production partners in crime passed along a recent video from Extra Credit on The Escapist highlighting some of the benefits that the gaming industry might glean from employing strong production planning practices. As those who know me well will agree, I'm a big fan of planning things (especially game projects) ahead of time. You know, so the development team can avoid all those nasty things like over-scoping, requirements gaps, and crunch time. That Extra Credit video really struck home for me as prospective producer in the gaming industry. As it played, all I could do was nod and wonder to myself how in all the world so many gaming companies have managed to turn a blind eye on the benefits of proper project scheduling. Let's talk about over-scoping and how it can lead into crunch first:

A project that is over-scoped is one in which the project team's capacity for work (in man-hours) falls short of the time actually required to complete the team's assigned tasks. Let's say for simplicity's sake that the project team is made up of just one person and that that person is schedule to work eight (8) hours a day, five (5) days a week. This means that in one (1) week the project team's capacity is 8 X 5 = 40 man-hours. Now let's say that the project is estimated to require 50 hours of work. This means that, given the work hours scheduled for the project team and the task estimation for the project, it will take a minimum of 50/8 or 6.25 days (6 days 2 hours) for the project to be completed. Now let's add a time constraint. Let's say that the client wants the project to be completed in five (5) days. With all of the above stipulations held constant, a five (5) day time constraint places this project over scope (total five-day capacity [40] is not equal to the estimated duration of the project [50]). Assuming (and this is a relatively large assumption) that the task duration estimations are accurate, this project cannot be completed by the date specified by the client.

There are five possible solutions to this problem: 1.) add more capacity to the project by bringing on additional workers 2.) increase the efficiency of the workers present through better facilitation, training, or encouragement* 3.) increase the number of hours worked by the workers present** 4.) approach the client to cut the scope of the deliverable down to something that can be reasonably handled at the capacity of the project team 5.) approach the client for a time extension.

*In this case, encouragement can mean either carrot, stick, or some combination of the two.

**Effectively, crunch them.

As game project managers, our job is make use of one or all of the five in order to meet the needs of the client, be the client a production house, a studio that has outsourced work to us, or even our own senior production staff and executives. The important thing to realize is that not all of these re-scoping "tools" are appropriate for all situations. In fact, some of them, if used in excess (such as increasing work hours [crunching] and using the stick [not facilitation, training, or the carrot] to increase efficiency) can have some nasty repurcussions. This is why it's always important to plan ahead, know your team's production capacity, build a solid schedule, and manage the expectations of your clients and other key stakeholders.

The other reason that making a plan before starting a big game project is extremely helpful is requirements gaps. A requirement gap is a genre-defining feature that other, similar games have that yours does not. The theory is that games that enter the market with strong similarities to other recent games but without features that are currently in vogue will not sell as well - sort of like wearing white after Labor Day. The game will still be perfectly functional, but critics and would-be buyers will talk about the game behind its back and give it a wide berth on the dance floor.

*cough*

The classic example is third person shooters (3PSs) that came out after Gears of War in 2006 without a cover system. Gears did for cover what Twilight did for vampires: mainstream. Now even 3PS RPGs have a cover system.

Point being that planning out your project will serve additional purposes beyond those that have already been mentioned - you can make sure that you've identified all of the features that will make your game fun and profitable and then you can develop safeguarding processes to make sure that none of these key features get lost in the chaos of full-blown production.

So that's all well and good if you've got a few months to spare planning things out, but what happens if you're just getting your studio up and running and your production contract needs to start seeing builds now? What if you've just been hired on as a producer/project manager mid development to firefight a wayward project? My approach would be to identify clients, identify objectives and project requirements, get task etimations, calculate production capacity, and start cutting the fat. But every case is unique and it's up to the management to determine which of the five scope management tools to employ and to what extent to employ them.

The reality is that once a contract has been signed and a client is dedicated to collecting deliverables on a specific date, it's really, really easy to slide into crunch mode when things get down to the wire. This is why it's very important to get things planned out early on and to make sure that you can meet your client's expecations before committing.

While this video was geared toward large studio, AAA development, even indie companies can benefit. In 2010 Team Meat ran into issues when their scope jumped as a result of a switch from the Wii Market to XBLA. They pushed through to release after several months of heavy crunch and succeeded in grand form, but stories like that make producers cringe. Part of the pre-production process involves risk management. While such a change in clients mid-production might not have been forseen per se, I at least like to think that the consequences could have been mitigated through effective planning.

But there's a trade-off: It's very easy to let helpful documentation snowball into a big, ugly pile of red tape. The United States military is notorious for writing volumes of standard operating procedure made up of IF/THEN scenarios. This helps the military make big, important decisions correctly, but not quickly. That's not to say that planning a game project is like running a naval blockade (although some might say that it is), but there are some common bonds in there somewhere.

That having been said, with game projects we can afford to play some things by ear. The trick, as always, is striking that balance between flying by the seat of your pants and creating such a huge production rulebook that nobody bothers to read it.