Sunday, March 2, 2014

Cancelling Projects

So if you've been paying attention this week I've scaled down the amount of work I needed to get done for Mage's Tower down to a rather reasonable 12 hours of work.

Closing in on the weekend I had gotten zero done but still a fair amount of time, then I got a call for another job and I realized Mage's Tower had to be cancelled.

While I definitely do not like cancelling projects, projects do get cancelled.  They do so in the games industry as well.  And yes it's even happened at BioWare.  So this brings up a good point.

How do you know when to cut a project?

To be perfect honest, I've asked around, I've searched books, and I cannot find a good answer.  It's a hard question.  I'm still struggling with it myself.  Here's my guidelines.  Hopefully they'll help.

  • Run out of Money
  • Poor Validation
  • Project Languishing
  • Cut Early

Run out of Money of the time this comes down to insufficient project management.  And when I say insufficient, it usually doesn't mean someone was terrible or lazy.  It's just that project management can be that difficult.  (Especially if you are doing waterfall.)  You should normally know when a project is due to be released, factor in money and time and have enough for both.  The other times it's due to having a shaky sponsor.  Either way, for most professional projects, when the funds run out.  The project has to be cancelled.

Poor Validation is when a project SHOULD be cancelled early but often isn't.  This is what 95% of new game developers run into.  It's a project that really love.  Maybe their friends are involved too.  But either they never bothered to ask anyone if they would play it.  Or they did, didn't get a great answer, but instead of refining the idea, they simply pushed on.   This is dangerous territory.  While you should be passionate about what you work on. If you are creating it with the intention of it making back enough money to pay you a minimum wage for the time you spent on it, I'd advise you consider cancelling it early.  At least refine the idea if you wish to continue. 

If you don't, it's often a lot of time, effort and heartache realizing that the rest of the world doesn't look upon this idea as fondly as you do.

So when do you cut for poor validation?  As soon realize you can't refine an idea well enough to get the broad appeal you need.

Project Languishing

 Duke Nukem MemeThis is the one most outsiders are familiar with.  This is Duke Nukem forever.  This is a really tough call, as even Dragon Age Origins had a pretty insanely long development cycle.  Normally you should realize you aren't making your deadlines and cut your losses here.  What makes it hard is some games have succeeded doing this a well.  But for them it seemed to happen on a wing and a prayer.   If interest is lost, and attempts to rekindle have failed.  Even if the project is fairly far along, it's often a good idea to cut your losses here.  

This has to end up going by gut feeling.  And that in turn ends up being the brutal and ongoing persistence of the team involved.  If they are determined enough, nearly any long cycle game can be completed.  But the better to ask:  Is it worth it?

Cut Early

If you are going to cut, the best time to cut is AS EARLY AS POSSIBLE.  This is why I stress that sanity test in the beginning.  The amount of time, effort, resources, and possibly heartache increases on a logarithmic scale, the longer you wait.  Finding the best ways to figure out when to cut early has been one of my #1 goals.   And that sanity test is a big part of it.

Heck even robot chicken sanity tests their stuff.  You can afford to do it too.

I feel lucky I've only had to cancel less than 10 projects.  Only 2 of which were very serious.  The others were more hobby projects and they were cancelled early.  Which looking back now, was certainly the right thing to do.

So for now technically Mage Tower is mothballed.  But what about you?  When do you usually cut projects?

No comments:

Post a Comment

Please no spam, and no links unless they directly relate to the content of the page.