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.

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.

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.

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?

Social media went postal on Tuesday as Microsoft officially revealed its next console (note that I didn’t call it a game console; more on that in a second), what they are calling the Xbox One. While not as roundly mocked as the Wii was when its name was unveiled, most game developers and casual gamers I know think the name is weak because so many of us refer to the original Xbox as “the first Xbox” and even as Xbox 1.

At a minimum, you certainly can’t deny the potential for awkwardness with the choice in name, and if I’m managing a multi-billion dollar product launch, I’m probably seeking to avoid awkward wherever possible, but that’s just me.

Yesterday, I checked an item off my personal “to-do” list that I initially put on that list nine years, three jobs and one state ago: I passed the certification exam and earned the title of Project Management Professional (PMP). Despite the fact that this probably set a personal record for most procrastinated task, I am both proud and relieved to have completed it, as few things feel as good as checking something off a list.

There were many reasons I had delayed this task for so long: its absence wasn’t really blocking my career success at the time; it was time-consuming to prepare for; I was too busy; I didn’t feel ready. I knew it was something I needed to do if I ever considered moving out of game development, but I didn’t make it a priority because I remained gainfully employed in game development and (let’s face it) the PMP is a much more formal approach to project management than most game companies would ever use, so there was a limited base of practical application.

Fast forward a decade, and a lot has changed in the game industry. Gaming has expanded in terms of total market size. Project sizes and budgets have increased in some segments of the market (primarily big-budget AAA console), while the others have continued to focus on small, agile approaches that are more about repeatability and portfolio management (mobile, F2P social, etc). In both cases, the bar seems to have risen in terms of what is expected out of a producer or team lead. More and more “outside” PM experience has been brought in, to the benefit of the industry as a whole. This bodes well for formal project management training and professional approaches to getting projects done.

In future blog updates, I will delve into this topic in greater detail, but today I wanted to mention some key concepts in the PMP that mapped neatly to career planning for game developers in today’s “challenging job market” (read: utter chaos! panic! uncertainty!).

I found John Maeda’s entry at LinkedIn yesterday fascinating, because it described two different models for leadership. The first model is the classical, authoritarian model most of us are familar with — warts and all — while the second model contained a number of attributes that I have personally always embraced (leading through doing rather than authority, etc), but have never really thought about in the context of a larger model.

An introduction.

Because management is such a black art and it can be so difficult to discern a person’s core beliefs and philosophy, I thought it might be useful to summarize my philosophy on leadership and discuss the principles I have relied on during my career. But first, one of my favorite quotes from a very, very smart man:

Management is the most noble of professions if it’s practiced well. No other occupation offers as many ways to help others learn and grow, take responsibility and be recognized for achievement, and contribute to the success of a team.