For those of you who have been living under a rock for the past two weeks, the infamous and always entertaining Derek Smart has been engaging in a sustained attack on the credibility and viability of the Star Citizen project, Chris Roberts’ record-setting, crowdfunded space combat game.   One of Derek’s Facebook posts on the subject linked to a post by Ben Lesnick on the SC forums, ostensibly in response to the increased media and fan scrutiny, that went like this:

‘Feature creep!’

I don’t have much to say to this, beyond that it’s not accurate. At this point, we are not adding additional features to the plan, we’re building out the ones we’ve already scheduled. I’ve seen some recent posts about how Chris’ “first person universe” is at odds with the original Kickstarter-era plan… and that’s again not the case. It’s a more recent way of describing what he wants to accomplish, but everything we’re working on is still what was pitched back then: Privateer-style persistent universe, Squadron 42 single player game, first person boarding and so on. (A desire to avoid feature creep is exactly why we stopped doing stretch goals, despite being aware that they drive revenue.)

I don’t know Derek, Ben, or Chris Roberts personally, though I’m Facebook friendly with Derek due to our number of common industry acquaintances (and I did cut my teeth as a young ‘Net jockey arguing with the man on USENET in the 90’s, much to my eternal embarrassment), so I don’t have much of a dog in this fight.  But my Producer Spidey Sense was going off like a four alarm fire upon reading Mr. Lesnick’s post because of the firm insistence that feature creep was absolutely not a problem on the Star Citizen project, and that got me to thinking about a metaphor that I thought was really quite apt.  Here’s what I wrote at the time:

Any producer who has ever shipped anything knows that feature creep is like mold: it may not be visible, but that doesn’t mean it isn’t there, and controlling it requires an ongoing commitment, not a one-time treatment.

mold_remediation-533x371[1]The more I thought about this, the more I thought this was really a potent and powerful metaphor for all PM’s and producers, because scope creep absolutely has to be one of, if not THE, top project killers out there, and so often we as project management professionals are in complete denial about it.  Like mold, scope creep is often unseen, hiding just out of our daily visibility.  But like mold, just because you can’t see it doesn’t mean it can’t hurt you.

The first key to fighting scope creep, as with mold, is to remain vigilant and create an environment that is inhospitable for its formation and growth.  For technology projects, this means a development process that is as transparent as possible, with tight, iterative feedback loops and high visibility into development priorities and deliverables.  It means a culture where anyone can ask “why are we doing this again?” as well as one where no one is afraid to kill something that has outlived its usefulness, regardless of the sunk costs or political capital invested in it.  And most of all, it means being able to raise your hand and say “we were wrong!”

Rigid, formal project management methodologies like the PMP rely on Change Control Boards and formal processes that aren’t likely to exist in a classically agile work environment, or even a chaotically informal team with ad-hoc, organically grown processes and culture.  But this alone doesn’t signal a surrender to toxic project mold — instead, empower your team to ask “how does this serve the customer?” and “Is this really something we need in this iteration?” — and encourage them to be brutal.  The perfect is the enemy of the good.

Second, I believe we need to stop pretending we wield such a masterful control over projects, especially interactive digital projects, such that Nothing Could Possibly Be Going Wrong.  In short, we need to accept that just because we can’t see mold, it doesn’t exist.  This is a major pet peeve of mine on a larger scale; there’s a desire in our field to produce charts that create the illusion of control we often really don’t have.  Perpetuating this myth leads to a culture where it’s simply not acceptable to admit that we have allowed scope creep to set in, or to admit we allowed our teams to get complacent, or that we simply picked poorly when planning.  So often, the tool of choice in dealing with these scenarios is a denial with a side of willful ignorance, and it doesn’t help anybody to engage in this kind of posturing.   We don’t blame ourselves when we discover mold in our showers, and pretend it doesn’t exist to avoid the shame.  And neither should we tolerate such a mindset on our projects.

the-vanishing-of-ethan-carter-screenshot-01[1]Instead, I humbly submit the following truism: Making Great Interactive Products Is Really Freaking Hard.  Even with incredibly awesome people, bottomless resources, a killer idea and a great plan, it’s way hard.  Some guys who made a really awesome game I enjoyed recently remarked on the difficulty of completing the game in their allotted budget and schedule that they were extremely cognizant of Hofstader’s Law, yet still struggled to hit their targets.  Which, of course, is what Hofstader’s Law predicts:

Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.

Douglas Hofstadter, Gödel, Escher, Bach: An Eternal Golden Braid [1]

Finally, seek out constraints, and use them.
  Scope creep multiplies exponentially.  The more complexity, the larger the scale, the more surface area you introduce into your project, the more of your project you’re potentially exposing to toxic scope creep.

For some projects, there simply may no choice; Red Dead Redemption would not have been a successful product had it constrained you to a single location. But often, we fail to see constraints as the gift they are.  When we have constraints, we are forced to devise creative, often elegant solutions to them.

Remember, the saying isn’t “Unfettered Resources Are the Mother of Invention”  Do “more with less” early on, and you’ll have less mess to deal with if and when your project scope does start to balloon.  Chances are, your project already has more constraints than you know what to do with; that’s good!  Use them, don’t fight them!  For those who have the luxury/curse of not being saddled with a lot of constraints, my advice is to construct some and treat them like they’re the Word of God.

Given the fact that people who are probably way better than you at making amazing digital experiences still struggle with scope management even after compensating for it, what makes you think that scope creep isn’t killing your project?  Because you can’t see any signs of it?  Because you think you’re Just That Good?

Chances are, your project is already being affected by toxic creep.  The real question is: are you prepared to clean it up, or are you simply hoping your customers won’t notice?