The Playdough report from Project Horseshoe suggested that using the Stage-Gate Model would allow the game industry to improve its hit rate. According to the report, 20% of the games released actually make a profit. This rate is much higher than the 5% achieved by the cheap-to-produce product out of the music and book publishing industries. This rate is only a quarter of the 80% profitability rate that the movie industry manages.
The stage gate system was developed in the 1980s by Dr. Robert G. Cooper, and is detailed in his book on new product development. It is used in a diverse set of industries by “almost 70% of leading U.S. product developers”, according to the Product Development Institute website. It involves taking a new product idea through a well defined set of stages, each of which is followed by a gate that kills off the weak products. The idea is that if you can kill off an unprofitable product earlier in the development process, you will save your company money.
The stages used in the stage gate model are as follows:
- Scoping — The rough idea is assessed for it’s technical merits and market prospects. This is an inexpensive check that can be performed on a given idea quickly.
- Build Business Case — This is where all the planning for the product happens. The product is defined and scheduled. An estimate of return on investment is made based on estimated revues and the product plan.
- Development — The product is developed, operations plans are written, and the staff required for launch are hired and trained. Everything required to launch the product is developed in this stage.
- Testing and Validation – All of the products of development are evaluated. The development process is evaluated against the plans. The economic fitness of the product is evaluated.
- Launch — Full commercial launch of the product.
So the question is, how can this model be applied to game development? Here is a pass at how that might work:
- Scoping — The game idea is evaluated for feasibility. The basics of setting and gameplay are described.
- Build Business Case — A budget and schedule for the development of the game are developed. The entire game is designed, top to bottom. Concept art is developed for the assets that the game will require. A technical plan for the game is assembled, including which middle-ware to use, what platforms to launch on, etc.
- Development — The programmers, artists, and level designers go to work building the game. They build the entire game top to bottom. The game is 100% playable by the end of this stage. The game box is designed, the marketing campaign is planned, and the customer support people are trained. If appropriate operations centers are staffed and trained. The server hardware required for testing is installed and configured.
- Testing and Validation – The game is put through its paces by the QA department and focus tested like crazy by the marketing department. After making whatever minor adjustments are required as an outcome of the testing, the game moves to the next stage.
- Launch — The game launches.
Here’s the problem: This won’t work. The Stage-Gate process is the classic waterfall model zoomed out to look at product development from the business perspective. The waterfall model looks something like this:
This model works really well for a defined process, which is any process that you can define well enough to make it repeatable. This is highly desirable for manufacturing processes, and is probably applicable to almost all of the Fortune 500 companies using the Stage-Gate model. Unfortunately this is not the situation with software development in general, and may be even less true of games.
For game development to be a defined process, we would need to have the same goals for a game that we had for the game immediately before it. We would have to staff the teams exactly the same way, with at least the same levels of experience and training if not exactly the same people. We would have to want the same game to come out the other end of the process.
That’s not what we want out of game development. What we want are fresh games, and fresh ideas. We almost never start a game with an equivalent staff to the game we developed before, and given how hard it is to find good people, that’s not realistic anyway. What we need is an empirical process; one that lets us take measurements along the way and apply them to our ongoing development effort. An example of an empirical process is the Iterative or Evolutionary model:
This is exactly the model being pushed by the big-A Agile community. They go to extreme measures to drive the cost of this iterative cycle as low as possible. Some of them even go so far as to flip the whole model and perform the tests before they actually do the development.
While I’m not really an adherent of the Agile school of thought it does seem pretty clear to me that the Waterfall method is broken for our industry. How many times have you seen a feature take many times its original estimate because once the work was underway it was clear that it was actually more difficult that it appeared from the outside? How many times have you seen part of a design be thrown out of changed substantially based on how it actually played? These happen all the time and aren’t the fault of the programmer who made the estimate or the designer whose work is being revamped. Each game explores new territory using the experience of its developers as its foundation.
So if Stage-Gate isn’t going to help us, what can? Well that’s a big topic that belongs in a post all its own. What do you think? Are there any business-level models from other industries that actually can help ours? How can we develop through hundreds or thousands of iterative loops and still be able to budget and schedule in any kind of reasonable way? I’m very interested to hear your thoughts on the subject.