5 Things About Planning

Being tagged for five reasons why I blog reminded me that I was tagged for five things you don’t know about me, before my flashdrive ate my post. Rather than rewrite that, I am going to tell you about what I do for a living and the perspective it gives me on game development.

I am firmly of the belief that many gaming projects fail or are executed badly not because of any problem in design but because of poor processes. Some really creative and dedicated people do excellent and inspired work, but they have no interest in the various meta skills that keep organizations functioning and keep things organized over a multi-year project. It still works for some small teams, but coordinating operations is a separate skill set from game development, just as coding is a separate skill set from graphic design. Even people who can do it all do not have the time to do it all themselves, and it shows in games that have brilliant features but poor overall coherence or ones that consistently fail to fulfill promises or meet deadlines.

What do I do? I’m a civil servant. My graduate degree is in public policy, which is the extended version of public administration, and my concentration was management. My undergrad was in politics, philosophy, and economics, which should not surprise you given some of my posts. I think of things in processes, systems that will work in the long run despite having weak links in the chain.

Okay, “civil servant” is not terribly specific, what do I actually do? I do planning, evaluation, and statistics for a state highway safety office. We coordinate activities between state, local, and federal units of government along with a variety of private sector and non-profit partners.

The planning is what most guides my perspective here. I was originally hired into the office to coordinate our big project for each year. Our staff would work with several hundred assorted grantees, contractors, partners, funders, and evaluators, and I was the hub of the wheel passing information around. If anyone wanted to know how any other part of the plan was going, they called me. If anything was falling behind schedule, it was my job to know about it and figure out what we needed to do to get that piece back in the puzzle. Now my planning function is a similar thing one level up.

I look at companies where the right hand does not know what the left hand is doing and it baffles me. Wait no, I understand it perfectly because I work with dozens of agencies where that is the norm, including other parts of the State. Still, it makes no sense to have poor internal communication policies, which usually means no policies at all. Don’t you have an overall plan for where things are going, touch base with one another, and tell people when your work affects theirs? How can you do your job if someone else is working against it three cubicles down?

The players notice when things are missing from the patch notes, for example. It means that your documentation process does not work. We know it is hard to keep straight which things are live, on the test server, being tested internally, being discussed internally, part of a build that was scrapped, was live but has now been changed, etc. You should know that it is hard too and have a way to deal with that.

We see developers posting not that they forgot but that they had no way of knowing which version of a change was live. What? We see developers posting that they never updated their internal test server for a change that went live six months ago. Oops? I recall several cases where decisions for a live game were made based on conditions on an internal test server, where the live game would not be getting those new conditions for several months after the changes. Does anyone have a timeline here?

The timeline is another big thing for me. Big projects have multiple interdependencies, so you need to make sure that A and B are in place so that you can do C. Sometimes E cannot even begin until we have a final implementation for D. It’s a big project: start with the end and plan ahead. Leave time for critical steps and plan for the inevitable emergency.

Again, I have no idea how your internal processes are going, but we are seeing problems from the outside. Release dates are being set with no apparent relationship to realistic coding times. You have press releases being written advertising features that were canceled and a manual bearing only a loose relationship to the game. You have design decisions that are constrained because you coded half the game before you finished the design documents, and now you either work around it or spend months re-writing half the game. We see functions and systems that cannot be updated or improved because things that should have been flexible were instead hard-coded.

There are several stages in the lifecycle of the game, and we can see when planning forgot about one. Did you fail to plan for the transition from initial development to ongoing, or shift too much staff from the original game to its expansion pack before initial development was done? Did you include tools for customer service and an events team, or were you coding as if this were a single-player game?

Are you keeping your community management folks informed? If they mock a conspiracy theory on the boards that turns out to be true, that will not be a good day for them. I will spare them the examples of cases where a post was dripping with sarcasm just days before a change in the game or code of conduct.

Internal coordination issues are not sexy but they are necessary. Just like you need accountants, lawyers, and secretaries, you need people who can facilitate efficient meetings, keep track of project timelines, develop documentation and policies, and keep your CEO from looking like an arse who promises revolutionary new features that won’t actually be in the game until six months after release.

I used to assume that people with “producer” titles were responsible for all those meta and management issues, but it seems as though, at some companies, no one is, or at least no one is doing the job well. We see entire companies fold because they forgot to think of themselves as businesses, not just a bunch of guys who got together to make their dream game.

With no evidence, I suspect that we have a problem with everyone wanting to be a developer. Everyone has his finger in the pot. Who wants to work for a game company where your job is developing a team rather than developing a game? After all, they hired you because you make great games, right? So maybe your intended responsibilities were 80% management and 20% development, but that 20% is so much more interesting to you… and the team could use some help working out issues… and we really don’t have enough manpower involved in making the game… and yes we could hire someone new for this, but it would take you as long to train him as to do just this one thing yourself… and now you are spending 80% of your time on the game, with no one picking up those coordination issues, but everything seems to be working itself out for now, right?

I would love to hear from developers about whether I am off-base here. Some companies seem to be doing a great job with this, or at least do not have problems big enough to be seen from the outside. Some companies never manage to release a game.

: Zubon

5 thoughts on “5 Things About Planning”

  1. This issue seems to be extremely pervasive in a lot of software companies. I know that it exists outside of software companies, but it really seems to be the rule rather than exception when it comes to software. Entertainment software seems to be the biggest culprit. I would be interested to see what SOE’s documentation process was like as well as Blizzard’s. I would love to know what sort of processes are in place, just how many project managers there are and how they operate in an industry that seems to be inherently anti-organization.

    I picked up the job of project manager in mid-stride. Developers hated to give me hard fast deadlines, I couldn’t get Operations to even give me a reasonable time line and I couldn’t even start on end-user docs, release notes, or marketing until I knew when other things would be getting done. Status meetings became a nightmare because trying to get people to nail down deadlines and actually stick with them because the equivilant of pulling blood from stone I personally don’t understand it. It doesn’t make any sense to me and ended up causing me hours of stress. We did end up releasing, 2 months late, but we released and I only had a few death threats.

    Part of the issue is if those in manager positions don’t show a respect to those who are doing project management, it’s handed down. A project manager isn’t a glorified secretary, they are a coordinator, organizer, task driver, bad guy, cheerleader, meeting planner, and communicator.

    The more I hear about what happened with Sigil the more frustrated I become because it was something that was so preventable. It was something that never had to happen if there were strong minded and vocal project managers on staff to keep things moving.

    Oh yes, they also need to be able to say no to upper management. They need to be able to defend their reasonings and they need to stand by their guns.

  2. I’m the guy in charge of the company that runs The Kingdom of Loathing. I can’t really speak to the practices of big commercial houses, but being involved in something that went from a single-man garage project to an actual company with an actual development staff, the points in this article really hit home.

    The discussion of the 80% manager, 20% developer problem wouldn’t look at all out of place in my autobiography, only my version would have more agonized whining in it. It’s like a lot of other jobs, I guess — you work your way up until you’re not doing much of the thing that drew you to the job in the first place. And once “making video games” goes from being a “holy crap, how did I get this awesome job” thing to a “yeah, this is my job” thing, everything sort of changes.

    We’re lucky, because as a free web-based game, we’re pretty much expected to be fast, loose, and chaotic with releases and fixes. But I can definitely see how easy it’d be to run into this kind of thing if we decided we wanted to try to develop a commercial project, where the end-user has a legitimate sense of entitlement.

    I think people in this industry are often smart people who come from jobs where poor management engendered poor morale, and they know that people work more and better when they’re happy. And I think that makes it hard to crack the whip, and to have the whip cracked on you. I’m guessing the mere utterance of the word “meeting” has a higher cringe-factor among game developers than among the population at large.

Comments are closed.