"Scope: Choose A Target! Focus! Shoot!"

Introduction

A comprehensive guide on how to manage scope, not to scope creep, and finish your game... probably.

What is Scope, why is it important?

The Scope is a term widely used throughout the video game development community to refer to the sum of all features and content chosen to be developed at a given time. It’s the focus of your creative and development endeavors at any given time.

Managing Scope in game development projects is extremely important because what happens with Scope during the development process either makes your game or breaks it. Too many developers, broadly speaking, suffer greatly because they poorly manage the Scope and end up in a very sticky situation leading to severe execution problems, a decrease of morale, anxiety, loss of product vision, and other problems.

Frankly speaking, I categorize the problems in the following way:

• Static, or Nominal: The Scope was chosen incorrectly in the first place.
• Dynamic: The chosen Scope isn’t enforced in one or many ways.

Both sets of problems are very dangerous, but I tend to believe that the latter is more important and I’ll tell you why. Throughout my career, I’ve had many instances of scope mismanagement, but the most severe consequences I had came from the dynamic scope mismanagement. To clarify, the scope was chosen correctly, but I let it out of my control and it started to shift and swell, ultimately making the nominal choice of scope irrelevant. Also, don’t take my word on it, I have a quote from a book widely regarded in many creative industries as the Bible of creative team management. The book is called: "Creativity, Inc." by Ed Catmull.

“If you give a good idea to a mediocre team, they will screw it up. If you give a mediocre idea to a brilliant team, they will either fix it or throw it away and come up with something better.” ― Ed Catmull, Creativity, Inc.

Let’s suppose you’ve chosen the scope incorrectly, and started the development. In most circumstances, you can always shift it towards the correct direction, or in this case, the correct scale, and come out as a victor. There are circumstances where you can’t*, for example, if you shot a trailer where you show a given primary game element - you can’t get rid of it without substantially giving explanations. You can always be a naughty dog, but you better know the cost. Let’s just assume you can always shift. And you have to.

Some of the sticky situations or problems you can end up with, in case you mismanage Scope:

• On completion, your game missed its core premise, unique features that compose a meaningful interactive experience, and/or had too many unnecessary features on top of broken core mechanics and elements.
• The development process becomes overwhelming and it becomes extremely difficult to hit a deadline and/or demands substantial crunch to hit it.
• Missed deadlines
• The game never gets released because it consumes too much time, too many resources, and ultimately, loses the vision and becomes a mess.

And, the question of the day is...

How do we (possibly) avoid these problems?

In the following articles (coming very soon), I'm going to try to convey three points that are very helpful and cover my vision of the sufficient framework to battle scope mismanagement.

"Choose the target": It is important to cast yourself and/or your team into a bordered region that you don't have to cross by any means*. There are a lot of points in this phase that we're going to cover to help you understand some of the mechanisms producers and/or game makers generally use for this matter. Setting yourselves on the correct rails right off the bat saves you a lot of time and saves you from the necessity to steer the "ship" in the right direction.

"Focus": It is more important in my opinion not to get off the rails. There are a lot of temptations along the way, that most certainly will lead you and/or your team to perish. But there are a couple of concepts and methods that you can and have to use to counter those temptations and presumably land in the projected point in the projected amounts of time.

"Shoot": There are cases where for whatever reasons you weren't able to put yourselves or keep yourselves on the correct rails. This is a very difficult situation, but I regard this as an important point to provide you with some gambit moves, where you might be able to save some portion(s) of the project.