The budgets and timetables for some games from game development companies are notoriously off the mark, but there are some professionals in the business who believe it doesn’t have to be that way. Keith Fuller is a veteran at guiding companies to the point they can ship a title and how to accomplish that within budget and on time. Keith elaborates on the thought processes behind production efficiency, which will be featured in his session, When Is It OK To Make A $50MM Game For $100MM?, at LOGIN 2011.
PAUL PHILLEO: Keith, please tell the LOGIN News readers a little bit about your background experience in the game industry before you created your own practice dedicated to project management.
KEITH FULLER: Making video games was the only career I ever seriously entertained. I wrote my first “game” on an Atari 800XL when I was 12, and the eventual completion of a programming degree got me in the door at a small game company in 1997. I subsequently moved to Raven Software as a junior programmer working on the first Soldier of Fortune. Over the course of 12 years at that studio, I contributed to a dozen titles as a programmer, manager of level designers, project lead, and producer. In each of those roles I sought to understand the challenges of every discipline and resolve conflicts in ways that not only addressed the needs of the project, but also respected the developers. That respect for the people making the games is what eventually drove me to address problem-solving on a broader scale as a production consultant.
What were some of the most important lessons you learned from the years invested in shipping product in a timely and efficient manner that compelled you to create your own practice dedicated to the craft?
One thing I’ve learned about the status of a project was highlighted in a quote from the Wall Street Journal, which Mike Cohn paraphrased in a tweet: “Employees on a project often know six weeks ahead of time it will fail, but management often doesn’t know when to abandon efforts.” You could boil that down to saying that the best advance indicators of a project’s status are found with the folks in the trenches. That having been said, one of the things I’ve learned about management is that they like to hear solutions, not just problems. So, developers … don’t frustrate your bosses: Give them solutions, not complaints. Leaders, don’t lapse into thinking you know more than the dozens of people working for you just because you have a larger office. Many of the project missteps that lead to crunch time, low quality, and missed deadlines stem from the inability for these two sides of the operation to communicate with one another. That’s where an objective third party with experience in project management can come in and help, which is what I seek to do as a consultant. Maybe it’s something easy, like training a team in Agile practices. Or maybe it’s something more difficult, like diagnosing and addressing dysfunctional social dynamics. Either way, I want to see as many of those problems fixed as possible.
What are the differences in the types of schedule-crippling production delays that can affect a large studio versus a one-man development project?
In a large studio you have the sorts of problems that stem from multiple moving parts — communication breakdown, managerial issues, dependencies, and the like. And when you have larger teams you also contend with larger external forces, like marketing deadlines, movie or product tie-ins, licensors imposing creative constraints, and stock price-sensitive directors. With a one-person team, though, you don’t have anyone else dropping the ball or failing to communicate. There are still external forces to deal with, like first-party certification, but you always know who the person is who’s going to do the work.
Could you separate the difference between situational and absolute efficiency, as it applies to the project management of a game title?
The simplest description of what I term situational efficiency is using your more abundant resources inefficiently simply because it translates to an overall gain for the efficiency of the project. So you’re asking the question, “When is it in the best interest of the project to do a particular thing inefficiently?” What I describe as absolute efficiency can best be described by asking the question, “When is it always right to do a particular thing efficiently?” What I think makes that clearer is the more general contrapositive, “Can you name something that’s always wrong if you don’t do it?”
Aside from the end game, a timely release of a game, what internal benefits can adopting an efficient development process offer a developer?
Depending on the process changes in question, you can look forward to benefits such as reducing uncertainty, reducing wasted work, improved quality, improved estimation, more accurate scheduling, less overtime, more engaged employees, and improved work/life balance. And I should point out these aren’t just pie-in-the-sky notions. I mean, hey … who wouldn’t want all of the above, right? These are the actual upsides of process improvements that I’ve recommended for various teams.
Many AAA developers stand firmly by the slogan that a game is “done when it’s done,” avoiding commitments to a release schedule. Do you feel that is a necessary step for some developers to take? If so, why?
I think being able to take a “when it’s done” stance is great work if you can get it, but very few companies ever find themselves in that position. And I don’t believe it’s necessarily a good thing to take all the time in the world even if you’re given it. There’s the impact on team morale to consider, the opportunity cost of the other games you could be working on if you shipped this one, and the contribution your game isn’t making to the industry for every quarter it’s not released. To be sure, you can argue that all of the above is worth it if you can boost the quality from 9 to 9.5, but since no AAA game is ever truly finished at release anymore, I think it’s difficult to justify an unduly lengthy development cycle these days.
The soon-to-be launched Duke Nukem Forever game is legendary for its years-long delays. Was what went wrong in development something that could have been remedied by any form of efficient process?
I’m perhaps one of the few developers in the industry that wasn’t involved in the development of DNF in any way, so I can’t comment authoritatively on the delays. From what I’ve read (taken with several grains of salt, I should add), it appears as though this title’s production was driven by the creative direction on the project more so than by a desire to stick to any dates. When you have creative freedom unconstrained by budget or schedule you tend to see discipline issues that make serious delays commonplace. If the studio management wants quality at any expense, though, maybe taking over a decade to ship the game is the right thing to do. However, if those are the priorities, then there really isn’t a production framework in existence that can reduce your development time to something reasonable. The best you can hope for is to create an environment in which you learn as quickly as possible what you don’t want to ship.
What insights do you hope attendees will take away from your session at LOGIN this year?
Every game’s development is different in some way from what’s gone before, so understanding situational efficiency is key. Doing the Right Thing for your project isn’t always something you can judge ahead of time on an absolute scale. But you need to have a clear set of priorities and leadership that will make decisions to act on those priorities; else you leave yourself with a much greater chance of not doing the Right Thing. I believe there are some issues that can be considered absolutely efficient, though, and I hope my discussion of that topic will spur meaningful improvements when the attendees of this session return to their studios.
