Game Career Guide is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Get the latest Education e-news
 
  • Scope: Maintaining Focus

    [10.01.20]
    - Levon Demurchyan

  • But, why?

    So, all of us have encountered this if we've made at least one project. But, it's not obvious what brings us there, what undermines the benevolent force that pushes the projects forward and prevents us from finishing them on time, on budget, what triggers Scope Creep. In the previous episode, I've talked about what you can do to set up the project's scope so that it has better chances of being delivered and is best fortified against Scope Creep. But it's more important not to drift away from that, as you may set a scope properly, and ruin it during the development. So, what powers Scope Creep?

    • Poorly Defined Scope - What to do, and NOT to do

      • Poorly Defined Feature Set

      • Poorly Defined Development Plan

    • Disruption - Market Changes, etc.

    • Lack of Scope Change Management

    Poorly Defined Scope is what I've talked about and shared some insight on how to counter that in the previous episode. It's important to start from a proper point with a clear scope. You can always come back to this stage if you have the time and the budget to do so. Redefining Scope is an extremely risky and responsible action. Sometimes it's something that saves the project from certain doom, and most of the time - it's something that brings it there.

    As I've said, it's important to understand what is in the scope, but it's more important to understand what is NOT. This is more important as it gives you explicit red flags for what's an unacceptable development of events. If you have defined the scope of the game not to have an X feature, whenever you try to add something X or resembling X, you and your team members have better chances to identify a trap. If you don't have this set up before going into development, nobody can stop you from adding something that doesn't belong, because you have no agreements on what belongs and what doesn't.

    The features themselves have to be defined to the best of your ability and knowledge. Ideally, you've developed a prototype with the given features, and now you know exactly what it is going to be for your next iteration. You need to know what's the feature you're working on.

    When a feature is abstract and not defined, you can't tell if you've made it or not when you assume you've finished the work. Besides, you might not be able to have a clear idea of where to start in the first place. This already means you couldn't define a schedule and a budget for it, most certainly. But not defining a feature, and not defining it well enough are different situations. The latter is when you've most probably been tricked into assuming that you've measured, budgeted and estimated a feature, and most importantly, delivered it. That's why pre-production is very important as you have more chances to precisely define a feature and then make the plan for the development of that feature.

    Ok, so the Development Plan is the plan for how you are going to implement a feature. It is the path between point A & point B. A development plan is much like wandering in a forest; you need reference points to triangulate your location to understand if you're going in the right direction. Whenever you don't know what you're going to find during the journey, it's much more probable you won't get to your destination.

    The Development Plan is also very important because when you have a decent one, you are much more effective in protecting yourself from mediation along the way. Whenever you feel lost you can always go back to the previous checkpoint and debug what went wrong and what to do next. When you don't have one, or it's severely weak, you wander around in search of the golden fleece, even though you might know exactly what it looks like. Investing enough time into planning the development in pre-production has a great impact on the final deadline, also. Wandering around generates uncertainty, even towards things that are truthful and well-defined, so it's very dangerous to walk around without a map. Any action that doesn't belong to the plan is easier to identify when you have a guide, and it is easier to seize unnecessary deviation.

    Professional game development is a business, and involves money, one way or another. And inevitably we are in the same Market, maybe in a sub-market, but it's all interwoven. One industry impacts the other, and creates a chain reaction, or a "butterfly effect", if it's a more convenient term. The modern market is extremely rapid, and changes occur on a daily basis. An immense amount of competition rages for the love of the crowd, and we are in the midst of it all. Whenever a big change occurs, the environment changes, and the market adapts accordingly. Adaptation demands mobility, quick wit and vision.

    But not all have the chance to adapt, as we, most probably, already utilize all of our potential, energy, focus, and attention. Deep analysis and a business acumen might provide a better chance of predicting market change, but it's not a guarantee by any means. Even though you might have an idea where things go, you might not have the confidence, the resources, and energy to outmaneuver the change. This is one of the things that are in some way beyond our control, as big sharks create the biggest waves in the aquarium. This is when we all start to waver, and panic fills our minds and impacts our decision-making process. The only remedy in these kinds of situations is to have a clear vision of your product/game. That's important because then you understand what's the target you aim for, and in case the target moves, you know what it looks like.

    Before we get to the solutions, I want to talk about a very important topic - Scope Change Management. I don't want to convey a wrong point of view that any change is bad. Some of the biggest and best hits involved big changes at some point. It's not about not making a change, it's about managing change. It's all about responsibly dealing with change and adapting accordingly, be it changing scope, delaying a deadline, or any other change to the initial plan. What is important is that this is an advanced topic, and you should pay immense amounts of attention and a responsible attitude towards this.

    Turning any change down is also destructive: any action that is directed towards you and/or your team reaching the goal, or following the vision, is a correct action. It's not about being firm with the means to reach a goal, it's about being firm in adherence to reaching the goal.

    Scope Change Management is a toolset that you have to have to handle change. This has to generate a process that enables flexible decision-making on the basis of pre-defined, or continuously defined metrics that serve to assess if the change is necessary to reach the end goal. This is a funnel that tests if the proposed change is worthwhile and optimal. These metrics are different, depending on a game project and are aligned with the vision and the business goals. These goals have to be enforced, but the path to them has to be flexible.

    Having a protocol on what to do in many different situations is what constitutes Scope Change Management, this is what keeps the creative storm at bay, and provides you with a better chance to reach the set goals. Learn to agree & disagree on change, debate on change with visible and independent metrics, learn to request change approval from a higher manager, learn to propagate that decision so that the team doesn't feel swamped.

    Ok, let's face the endboss.

Comments

comments powered by Disqus