Something I feel doesn't get discussed enough in the world of gamedev, and something that in general we (more often than not) tend to be incredibly bad at, is project management. This isn't something I'm an expert at myself, I get it wrong plenty of times, but at least I'd like to stimulate a little thought on the subject.

One of the most crucial aspects of project management is the interplay between project scope, and timescales and scheduling. It doesn't matter whether you are managing an AAA game with a multimillion dollar budget, or a one man bedroom indy game or first game, this all affects you.

Scale & Duration

The first point is that as you increase the scale of a project, the time needed to complete it will increase. You would think that there would be some kind of linear relationship between the scale and the time needed, but in practice there can be a tendency for the time needed to increase almost exponentially with scale. 

Real life observations show that it can be incredibly difficult to predict the time taken to complete a complex task. If we were, for example, asking how long it would take a man to harvest a small field of potatoes by hand, we could find out how long it took him to do 1 metre squared, multiply it by the size of the field, leave some time for breaks etc and come up with some rough estimate.

Unfortunately developing software is not like harvesting a field. Some tasks can be made more like this (artwork production for instance), but things like programming are absolutely nothing like this model. You can add more artists but if you add more programmers expecting a productivity increase expect a shock (see the mythical man month).

Dunning-Kruger

Couple this difficulty in making time estimates with something called the Dunning-Kruger effect. This is (I quote wikipedia) :

Quote

'a cognitive bias in which people of low ability have illusory superiority and mistakenly assess their cognitive ability as greater than it is'.

This blog post is probably a great example of Dunning-Kruger!

Those people who have little knowledge of a task will tend to be very bad at estimating how long that task will take to complete. Unfortunately, the people typically responsible for making time estimates are exactly those people who tend to have little knowledge of the subject area. This is often management, and / or 'yes men'.

(Sycophants / Yes men (or people, they could be transgender) are those types that follow the strategy of agreeing with everything their boss says, or providing extremely optimistic estimates. This is a very widely used strategy for promotion, constantly reassuring the superior providing short term appreciation, then when things inevitably go wrong, it is usually easy to blame an external event or third party.)

Other types of people who often have little knowledge of a task are beginners, and those choosing to work on something they haven't done before (most of us). So essentially most of us are prone to this Dunning-Kruger effect.

With beginners this almost always shows itself in new posts to forums introducing themselves as knowing nothing about programming or artwork, but expecting to complete a game such as one requiring teams of 50+ experienced staff and years of work, in a couple of weeks. Presumably they expect there is some app for doing this, and they will just press a 'make game' button, after selecting the right parameters. It is easy to see the error in beginners, but this same thing tends to happen with all of us and we have to actively fight against the tendency.

Real World

So how long do things really take? Well, a wise man once told me, as a rule of thumb, if you are familiar with the subject area, it will on the whole take at least 3x as long as your estimated scenario.

What does this mean?

Well if you in charge of developing a typical 18 month commercial game, you should be aiming for something you believe you can complete in 6 months. No, that's not a prototype, that's the whole thing. Once all the things have gone wrong (and they will) it will easily expand to take the full allotted time. Best case if it is finished ahead, you have extra time for testing, and polish.

If you are an indy and you want to complete a game over a 6 month schedule, you should be aiming for something you can finish in 2 months. If you are a beginner and you are aiming for something you can finish in 2 weeks, you should be aiming for something you can finish in 1-2 days. Beginners are the worst at estimating, and are usually wildly out, and typically don't have the skills to complete what they thought, so often don't even have the skills to complete their original project until months or years after.

How can you battle this effect?

The best advice I have heard to battle these problems is to aim small. This applies to everyone but 100x more to beginners. There are a billion unfinished shelved projects out there in the world. Don't be one of those people.

Choose something you *can* realistically complete, something 10x to 3x smaller than your original vision (depending on your skill level).

If you are beginner this means start by making tic-tac-toe. Make pac man, make tower defence, gradually increase your skill set so you can make better games (and better doesn't always mean bigger).

If you are learning OpenGL / DirectX by all means learn to make your own engine but be under no illusions that you will make something that others will want to use. Commercial engines now tend to be made by small armies of experienced devs, and have to work under conditions of a huge variety of hardware, with testing and all kinds of considerations you haven't even thought of.

If you are an indy and you dream of making the next amazing rpg to rival the big companies, have a think, how much artwork, how much sound, how many voiceovers, how many scripts, how many levels do you need to create? Aside from the programming, creating the assets for such games is a major undertaking. Have a look at the credits list on a game you would wish to emulate.

If you are a company, you have possible funding, be very realistic about what you can create in your allotted 18 months. Aim to be leveraging and reusing your own and others' technology because to create everything from scratch everytime is just not possible. Aim for that 6 month timescale, and get estimates from all the tech people especially not just from 'yes men', and use them all to make a balanced decision on what you think is realistic.