Why Projects Fail: Extreme Game Development Edition

In thinking about Scott’s entry on shitty post-layoff rituals and the ensuing discussion about who really owns the blame for the bad decision-making and subsequent layoffs, I thought it might be a good exercise to try to enumerate common reasons cited for why game projects failed.  As they say, success has many fathers but failure is an orphan.

I break these down into the following categories:

• Failures of ideas / design
• Failures of execution
• Failures of management (including HR, strategy, marketing, and sales) 

Failures of ideas / failures of design

Despite having a solid team and unfailing support from management, the game just never “clicked”.  

1. The game just wasn’t fun.
2. The game didn’t differentiate itself or bring anything new to the market.
3. The game was not something consumers could relate to.
4. The game was too difficult for the majority of the target audience.
5. The game simply failed to find its audience.

Failures of execution

You had smart people, a good idea, a solid plan, and plenty of resources.  So what happened?

1. The team lacked cohesiveness and failed to “get on the same page”. 
2. A significant portion of the team were just underachieving.
3. The technology requirements didn’t match the demographics of the target audience.
4. The team was unable to reach an acceptable level of production values and/or lacked the engineering skill to implement the game systems.
5. The team made poor technology architecture and/or art direction choices.
6. The game neglected end-user usability.

Failures of management

The bogeyman of failed projects.   It’s always easier to blame management, but hey, most of the time we/they deserve it.  That said, the items on this list are often the gaming equivalent of postmortem wounds.   They would have killed the victim… if the victim hadn’t already been dead.

1. The game was shipped too soon (lack of polish, or too buggy).
2. The game was scheduled for release at the wrong time.
3. The wrong people were selected for the project team.
4. The project was not given sufficient resources to achieve its stated goals.
5. Wait, I didn’t know we had stated goals!
6. The plan was unrealistic and/or didn’t account for risk.
7. Development costs were out of line with audience demographics and/or sales projections.
8. Marketing / PR was “phoned in” and never really helped sell the product.

 

“The game just wasn’t fun”

Probably the scariest of all failure cases, because fun is so subjective and there are no easy fixes to this problem.   Fun is like smut.   It can be described to a rough degree of precision but there will probably never be clinically definable standard for what it is.   However, “you always know it when you see it”.    So how do we prevent this failure case?   Iterate early and often.    You may not be able to permanently dodge the gremlin of a boring game with this tactic, but at least you find out quicker and cheaper that the game idea you were pursuing just wouldn’t work.

The game didn’t differentiate itself

This happens most often when a competent but unimaginitive team sets out to make a derivative or clone product because an opportunity is seen in a particular space, as opposed to working on something they all have a burning passion to do.    It should be mentioned, however, that this can be a perfectly viable approach if everyone involved knows that this is the goal upfront. 

The game was not something consumers could relate to

Sort of the exact opposite of #2 — here your unique snowflake of a game was perhaps too different.  Human beings need to be able to classify and pigeonhole things to make sense of the world, and there’s a reason some types of genre formulas endure so well.   Another offshoot of this failure case is the failure to tap into player fantasy.   While not a 100% universal rule, this is a pretty good litmus test for killing an idea for a game.  “What’s the fantasy I get to live out here?   Is that really an escape others aspire to?  Who do I expect is going to go for this?  Are the fantasy and the audience expectations aligned?”

The game was too difficult for the majority of the target audience

Two words: SHELF MOMENT.  You don’t see this that much anymore, mercifully, but there are still a lot of games whose designers forgot that I play games because I like to have fun.  One of Sid’s great maxims is that the player should be having the fun, not the computer.   I’d like to add to this that the role of AI should be to challenge me, and yes — maybe even let me win — rather than crush me under its unstoppable binary bootheel.   

“The game simply failed to find its audience.”

It’s hard for me to believe that this isn’t just a catch-all for a failure case or combination of failure cases that haven’t been identified yet.  But, this happens enough that it seems to warrant consideration for inclusion onto the list.

The team lacked cohesiveness

This could just as easily live in the management section but communication is a 50/50 proposition and too often people don’t want to go digging for answers they aren’t getting, because they’re afraid they’ll be rewarded with more work.   Regardless, this is just a classic manifestation of a team that has no idea what they are supposed to be doing.   

The team underachieved

A brutal failure case but the most straightforward in terms of how to fix.  That said, actually doing the fixing is another matter entirely.  “Performance improvement plans” (or if you prefer, the “Come to Jesus” meeting) are well-intentioned, but inspire the kind of dramatic turnaround one would hope for.   Firing is difficult, not only from a legal and CYA perspective but also from a personal perspective.  Or at least it has been in my experience; YMMV. 

The technology requirements didn’t match the demographics of the target audience

One of my all-time favorites!  We pretty much nailed this one on Railroads, actually.   This one should be common sense but it’s surprisingly easy to convince yourself that “everyone” has a dual core box with a GeForce GTX.   Not every game needs to have massively detailed models that look like they’ve been dipped in super-saturated, wet shiny paint.     If your game does, that’s OK, just make sure you’re doing it for the right reasons.  Namely: your target audience expects and demands it.

The team was unable to reach an acceptable level of production values and/or lacked the engineering skill to implement the game systems.

This is sort of a cousin of the underachieving team case, and probably a variant of the management failure case of assembling the wrong team.    But sometimes you just end up with goals that are too ambitious to be realized with the team and/or resources you have.   To put it another way, a team must know its limits.  It’s okay to reach high, in fact it’s a great thing.  But doing so is a risk.  You need to have a fallback position.

The team made poor technology architecture and/or art direction choices.

Here’s a case that’s possible when you have the right people and you’re not even necessarily being overly ambitious.  You had a number of ways you could go when determining fundamental architecture of the game server, or you needed to decide between two different art styles each with compelling positives and some risks.   You pays your money and you makes your choice.  Yeah, sometimes you can make the wrong choice and it can be catastrophic, but this is another case that can be mitigated somewhat through iteration and “failing early”. 

The crazy thing about this one is that fear of this is probably the single biggest driver of bad hiring practices (looking for “experienced” people at the expense of green but passionate young developers, ignoring your gut, etc) even though I suspect the majority of failed game projects didn’t die at the hands of this case.

The game neglected end-user usability

I almost left this one out, thinking instinctively that it was probably a variant of the failure to polish, but then I thought about the number of games that epic failed the new user test and decided to include it on its own.   This is really just inexcusable in today’s day and age, but for some reason, we in the games industry treat usability like a crazy third world automobile manufacturer who thinks seatbelts should be a customer option rather than standard equipment. 

I mean, think about this — we spend multiple millions of dollars developing products and don’t bother to make sure people can actually figure out how to use them properly!  And the worst part is, it’s relatively CHEAP and EASY to do the testing!     The good news is, if you actually do care about usability, you’re probably going to beat the snot out of the optional seat belt guys you’re competing against.

The game shipped too soon

Probably the single most casually dropped reason for a game failing; everyone thinks their game shipped too soon.   Tabula Rasa was in development longer than my two children combined, and the majority of NCsoft Austin said they felt the game should be held back a few more months in a now-infamous survey that was conducted right before the game went live.   Thing is, few games actually fail because of this alone. 

What people think they mean when they say the game shipped too soon is that  it needs more polish.   You’re talking 4-8 weeks — maybe a little more — but mostly, time to get rid of what’s likely a tsunami of B- and C-bugs, to polish and spit-shine that game as much as possible, but not to fundamentally change the game.   Most games in this situation are not going to suffer failure in the market because of a few weeks of polish, unless they are competing with products that are noticeably more polished — and that’s a scary small margin of error for any project to operate in.  

The far other end of the spectrum is where games who fall victim to this actually fail — games that need another 12 months.   I’d argue that any game that’s coming up on its initial projected ship date and only then realizes it’s actually a year behind schedule has already suffered through a litany of other failure cases that just haven’t been diagnosed yet.

The game was scheduled for release at the wrong time.

Here’s one that I wish more press and pundits would call execs on because this is something that can be controlled, isn’t black magic like so much of the rest of game development, and yet continues to sink games every year.    It’s time once and for all to do away with the “help us, Kris Kringle, Christmas is our only hope” myth.    

No other time of the year is more jammed for retailers, buyers, platform certification gatekeepers, and marketing folk, yet the herd mentality prevails because we believe that increased holiday shoppers will lead to more impulse buys … which will somehow… more than make up for the fact that TEN TIMES the freaking number of SKUs are vying for those impulse buyers?!  

And let’s be honest here — shooting for Christmas means you have NO FAITH in your product to stand alone and sell because it’s a great product.  We’re implying that we can’t sell without the help of people accidentally putting our box in the cart.   Perfectly logical for the makers of the Pedi Egg or ShamWow, but I’m not sure it makes sense on a $50 video game.    

Here’s an idea: go look at when Valve and Blizzard have released their last several super-successful products.  Amazingly, because they make killer games with incredible long tail shelf life, they can have their cake and eat it too by releasing new products pretty much whenever they please and gold packs and GoTY editions during the holidays.

The wrong people were selected for the project team

Could be ability, could be motivation, could be two awesome people who just become intolerable whiners when they get within 50 feet of one another.  Regardless, you had the wrong people for the job.  The only thing I can offer here is to try to identify this early, either through one-on-ones or through “in situ” postmorts, and try to offer to move people around, shuffle tasks, or otherwise try to be sympathetic.  But at the end of the day, this is a job.  We’re professionals.  We get paid to make games.  Anyone who can’t get on that train probably has bigger issues.  And your team only has so much carrying capacity for issues.  You want to waste some of it on *that* problem?

The project was not given sufficient resources to achieve its stated goals.

When developers refer vaguely to “management failure”, they’re often thinking of this one.  Simply put, the producer or project lead never had the necessary and oh-so-pleasant discussion with the stakeholders to say “what you guys are asking for is completely out of scope for the time/budget/quality you’re letting me spend”.   Or, the producer DID have that talk, and management said something like, “I don’t want excuses, I want results!” and that was that.   Often teams are bribed, goaded, begged, threatened and cajoled into sacrificing huge portions of their personal lives to try and bridge the gap between What Is Expected and What Can Reasonably Achieved.  We call this sacrifice a “Death March” (not to be confused with Crunch).  

Unfortunately, the best answers to how to deal with this failure case often start with the word “Quit.”.  I don’t think that’s a particularly effective strategy, though.  Just as games can get out of hand when scope creep sets in, one way of dealing with this kind of scenario is to begin implementing cut creep — start cutting things early, small bits at a time, starting with the most expendable, trivial things.   Unfortunately this strategy is likely to just shift your failure rather than avoid one entirely, but hey, at least you avoided a Death March, right?

Wait, I didn’t know we had stated goals!

A personal pet peeve of mine.   And the reason it’s so maddening is that I’m actually Quite Okay with the idea that I’m not working on the flagship project.  I just want to know what the parameters are so I can meet them.   Some people have the belief that whatever they’re working on Must Be The Best Game Ever — they’re the game developer equivalent of Reggie Jackson and figure they’re going to go deep or strike out.  Me, I don’t mind a base hit.  Hell, I can live with a sac fly.  I’ll even bunt if it makes sense.   But you don’t put Reggie in and tell him to swing for the fences when the bases are loaded with one out and you’re only down one run.   For the sports metaphor-impaired: not every title is going to be AAA.  Some titles serve a different strategic role in a product portfolio and must be treated differently.  But the team has to know what their mission is in order to fulfill it.  

The plan was unrealistic and/or didn’t account for risk.

Basically: you suck at estimating.   Don’t feel bad, pretty much everyone sucks at estimating.  You probably failed to give yourself a realistic scheduling reserve, or you were challenged about that reserve by your boss and you caved.     A lot of projects also seem to think that ignoring risk is a viable mitigation strategy.    I’d like to point out how well that’s worked for our financial institutions here recently…

Development costs were out of line with audience demographics and/or sales projections

I really believe that one of the great things about today’s gaming market is that there is a market for almost any kind of game.   You want a hardcore wargame where you get to be Great Britain fighting Argentina in the 1980′s?  You got it.  Want to make a game about h4x0ring computers, stealing information and industrial espionage?  Thank you, drive through.  No matter what game you’re making, there are probably people who want to pay you for the right to play your games.    Statistically, though, it’s just very unlikely that there are one million of them.   So don’t spend yo development cash like it, fool!

Marketing / PR was “phoned in” and never really helped sell the product.

I’m not going to sit here and say this doesn’t happen.  It does.   In EA’s case it’s a famously self -fulfilling prophecy — marketing team isn’t sure a game is going to be a hit, so they allocate less advertising spend and the salespeople don’t push it as hard as they could with the buyers, so the game tends to sell less.  

I will say this, though:  developers have the right and the responsibility to push back.  An enthusiastic and communicative development team that owns the PR process and constantly pushes back for what their product needs can be the most effective campaign you run.    Too many developers think their responsibility ends at making the game, but there is no better advocate or evangelist than a dev who believes in their product.