Manager In A Strange Land: Most Projects Suck

Let me get out my crystal ball. You're working on a project. You think it could be managed better. Am I good, or what?

No, I don't have magic powers. The fact is, almost all projects suck in one way or another, even high-profile ones. The Sims? Came in late. Half-Life? Came in late. Most high-profile Nintendo titles? Came in late. Spider-Man, the last game I helped ship? Was on time, but went over our original budget and we cut content. This problem isn't limited to game development either: anyone seen Lost in La Mancha? It's a documentary about a movie project that got hopelessly creamed. And a friend of mine hired a contractor last year to do some work on his house. It's still not done. The horror. And when projects go wrong, management is held responsible. (Side note: I was talking to someone who works at Fox the other day, and she said that movie projects almost never get cancelled. So don't get me wrong; games get bungled a lot more often than movies.)

Here's the part where I'm supposed to say, "You've come to the right place. If you read my column, you'll learn everything you need to know to ship a product on time, on budget, without compromising quality."

But I'm not going to. Because I've never seen an original title achieve that. You can do it with ports; you can sometimes do it with games where you just create new levels without changing the underlying engine much; but if you want to make an original title with new features and new content, you can expect chaos. Your plan will not survive contact with the enemy.

What I will say is this: I've seen a lot of projects, and most of them ran even less smoothly than ones I've been a lead on. So unless you're on one of those rare projects where you never have to cut features and you still ship on time and on budget, you might have something to learn here. Because I'm going to present the techniques we use on my team to manage projects. These techniques have been used to ship games. These techniques, applied judiciously to your own project, can make a difference. You'll cut fewer features, or you'll slip by less time, or you'll go less over budget.

This column is not about making the greatest game ever. All it can provide is some techniques that should help you do better than the industry norm.

Maybe you're a grunt in the pixel mines on a doomed project. Maybe, like me, you're a manager who got promoted from the coding trenches, and now, with no formal training, you're expected to run a team of several people. Or maybe you're a producer working on the biggest project you've ever had to run yet. This column should be useful for all of you. What I don't want to hear you saying is, "I'm just such-and-such. My boss wouldn't go for this. My hands are tied." I say to you: "A hobbit can contend with the will of Sauron." If you recognize a way to help your project, whether it's something from this column or elsewhere, try running it by your boss, or your teammates. If it's really important to you, follow up on it. Some people call this "whining." Others call it "disrespecting authority." I call it "doing your job." Chances are, you're in a better position than your boss to recognize certain problems. (An obvious example is whether you're going to finish the work you're doing on time or not.)

At the very least your boss is going to want to address your concerns. They know the big picture, and they have the wisdom from experience, so if they consider your idea and then shut it down you may have to face the possibility that it was a stupid idea.

If you're sure that it was an important idea, volunteer to do whatever it takes to make that idea a reality. A friend of mine who does IT for the phone company has an expression: "You pet the kitty, you own the kitty." That philosophy is a decent way to separate the ideas people really care about from the ideas they wouldn't lift a finger for. If you're willing to own the kitty, you've crossed over the line from 'whining' to 'doing.' Even still, your boss will probably say, "That's great, but what I really need you working on is this, because it's our highest priority right now." At which point you can either put in overtime to do it, or ask if you can do it later, when things aren't so crazy.

Now, speaking as somebody who's been on both sides of the "I've got a great idea, boss" equation, I know that it can be exhausting to have people under you managing up. They've got all these suggestions; you could spend your entire day following up on people's suggestions and never get any work done; you do something to make person A's job easier and you end up making person B's job harder; you do something to make life easier now and end up making life harder later; and so on. My advice here is to recognize that the guys managing up are your most valuable teammates, but be firm.

Almost all the ideas that come your way are going to take the form of: "We can invest some time now to save time later." Each time you're going to have to decide if risking your near-term commitments is going to be worth the eventual payoff. When it isn't, you'll have to risk hurting someone's feelings. Such is life.

So, now that you're all set to make some changes at work, what changes should you make? I'll get into that next column. If you can't wait that long, you could read my previous article, Production Testing and Bug Tracking, because one of the best ways to desuckify a project is to fix bugs early rather than saving them for later.

______________________________________________________