When you are working on a game it is often difficult to choose which problems to fix and features to add. Whenever you play your game you'll get new ideas and when you give other people a chance to play they won't only give you feedback, they will give you feature requests as well. Sometimes it might feel that adding as many cool features to your game as possible is the right way to go. It's cool if the hero can jump and run, but isn't it cooler if multiple heroes can fly and sprint as well? It might be, but it's more likely that you'll end up with a low quality game with a lot of unnecessary features.
The quality of a game is always directly related to three things : scope, time & budget.
This won't be news to you, but it's important to know the relation between these three.
In project management we call them the triple constraints and understanding them can be a basic tool to work towards higher quality products.
Scope answers the question of what you will spend your time and money on. This can be features, bug fixes, polish, marketing, ...
Time answers the question of how long you have to finish the game. This isn't work time but the actual time between today and the release date of your game.
Budget is the amount of money and resources you can spend on the game. Work time is part of your budget as it can be bought by hiring more people.
The general rule is that if one of the constraints changes in size, at least one of the other two will have to change as well in order to maintain quality. Here's an example :
Play tests have shown that one of your features needs a better introduction level.
This means an increase of scope so either time or budget (or both) will have to grow as well.
If your milestones are set and time can't be changed, then you can increase budget and pay someone to help on the level design.
If the entirety of your budget has been allocated perhaps the only thing you can do is push back the release date another month in order to get this level done.
Of course, a third approach could be to analyse the feature and figure out if it's core to your game.
What would happen if you cut it, making scope smaller instead of bigger and perhaps freeing up some time or budget.
In each project you'll have fixed constraints and loose constraints.
I encourage you to think about the constraints and figure out what can and can't be changed in your project.
Is your budget fixed?
Is your time limit fixed?
Is the scope of your project fixed? This last one is rarely the case except if you're already building a minimum viable product.
Of those things that can change, which one is easiest to change for you?
You also have to understand the specific relations between the constraints as they exist in your project.
It is possible to conceive situations where increasing development time will increase budget and situations where it will free up budget. You have to factor in your own unique situation.
Lastly, know that triple constraints is only one of the tools in your tool belt and that sometimes results will be different than what you intended. You might add marketing budget but get no results or hiring an additional team member might slow down develoment instead of speeding it up.
Understanding triple constraints is however a great tool to analyse your available resources. If you have a good sense of them, you will be able to think more strategicaly and realisticaly about the size, cost and deadlines of your game project.
If you want to talk about your situation and how the relations between your constraints might be, feel free to contact me.