The Scope/Complexity Vision Matrix of Software Development

By | 04/28/2019
GameOverThirty

I’ve spent much of my professional life in project management, particularly in IT. I’ve seen projects run the full spectrum of success & failure, from perfect execution & delivery through complete disaster. It’s important to remember that most projects, particularly software and games, usually don’t hit the extreme ends of the spectrum. It’s a simple fact of life that the initial release of software is almost always a case of uncertainty, with success (or failure) being measured by how effective the product was in the hands of the target audience.

Through all my professional experience & education, there is ONE thing that has stuck more than anything else – a clear vision is one of the most critical factors in ultimate success. This is especially important when the product is malleable and there is no strict definition of success. A civil engineer leading a team knows exactly what a bridge does and how it should work. That’s not how software development, particularly video games, work. Game producers and developers aren’t building a bridge. They are creating a game that is the literal product of imagination. To help illustrate my point, I’ve created the Scope/Complexity Vision Matrix (SCVM).
[MUSIC INTENSIFIES]

The Scope/Complexity Vision Matrix – GameOverThirty

At this point, you may be asking yourself, “What is this pile of color coded tiles?”

The Y-AXIS (vertical) defines complexity and/or scope of the project. The bottom of the Y-AXIS would be a game that is very small in scope and/or is extremely simplistic. A game of extremely high scope and/or complexity would be at the top of the Y-AXIS. Most games fall somewhere within the spectrum and rarely fall on the exact top or bottom.

The X-AXIS (horizontal) defines the vision of the project. A project on the far left of the horizontal axis has absolutely no one making decisions or trying to define the ultimate vision of the game. A project on the far right of the horizontal axis has extremely active decision-making and a vision that is perfectly defined and accepted by the entire team. Like the Y-AXIS, most games fall somewhere within the spectrum.

And now you might ask, “OK, that’s great, but why is it a square with four different colors?”

Each quadrant (1, 2, 3, & 4) defines a different GENERALIZED result of game development. (Remember, the chart is a spectrum. In order to have a conversation, I am simplifying the chart into four major categories.)

Quadrant 1 (No Man’s Land)
This is the quadrant that represents a small scope, less complex game, but success is hindered by lack of vision.

Quadrant 2 (Indie / AA Target Zone)
This is the quadrant that represents a small scope, less complex game, that has the benefit of being led by a strong vision. The team is tightly coordinated and decisions are completed reasonably quickly.

Quadrant 3 (The Star Citizen Zone)
This quadrant represents a game with large scope/complexity but the project management suffers from lack of vision, direction, and decision making. Scope creep is rampant and systems are worked on without a definition of WHY. Money is being spent on…everything.

Quadrant 4 (AAA Target Zone)
This quadrant represents a game with large scope/complexity and a very well defined vision. This quadrant also represents a decision making system that doesn’t allow questions (or problems) to flounder. A process exists to make sure that anything undefined becomes defined (or removed).

“It makes more sense now, but what do I take from all this?”

There are lot of different “lessons” in the chart above but for the sake of time, I’ll try to hit the big ones. It’s important to note that nothing is set in stone and these are general tips for managing a project.

Tip #1: If you find yourself and your project team in quadrants 1 or 3, the best way to improve the overall chance of success is ramp up on vision. Make sure the end state of your product has some kind of definition (it doesn’t have to be perfect). What does the player literally do in the game and what drives them to keep playing? Install a decision making process that ends with someone making an executive decision. E.g. Team A & team B can’t decide on a way forward so the decision is sent to person XYZ and that decision is respected. Lastly, empower decision-making in the team so that people have freedom to make small decisions and know they won’t be reprimanded for doing so.

Tip #2: Avoid moving from quadrant 1 to quadrant 3. Quadrant 1 is not a death sentence for a game, due to game’s small scope. There is probably a good argument to be made that a lot of games sit in quadrant 1 and get by without a strict definition. That is why quadrant 1 is less risk than quadrant 3. A typical mistake in software & game dev is to try and “solve” problems in quadrant 1 by ramping up on scope/complexity. This is a mistake without the vision to support it! Ramping up on scope MUST be accompanied by increased vision. Remember, going UP on the Y-AXIS means increased cost as well. There is a reason budgets keep going up – project teams keep trying to solve problems by increasing scope.

Tip #3: The vision does not have to be rigid or concrete, but it should have boundaries. The vision isn’t impossible to modify, nor should it be, but it has to have some type of limitation. Modifying the vision is easier earlier in the project but remember, every time that is done, something has to be reworked. At some point, someone may have to say “no” or “not right now” to keep things moving. If you have someone on the team who wants to lead that vision, let them. They may save the entire thing.

That brings me to the end of this short, but hopefully interesting & effective explanation of why vision is so important to project management, especially game development. This summary does not include an analysis of quality and is without consideration of external factors. If you have any questions, agree, or disagree with something on here, please let us know here or on Twitter!

This matrix is the IP of GameOverThirty. Use of this tool is free as long as the use is educational and credit is given to the source (this website, this author).