Indie game projects easily miss their deadlines. Planned milestones pass, and patches don’t come on time. This article points out 15 reasons for missed deadlines this and gives a clear guidance on how to estimate your game projects duration. Getting better estimates will not lower costs but will help you estimate the time scale and costs related to the project.
#1 – Avoid Over Optimistic Estimations About Your Skills and Energy Level
It’s quite common for people to over estimate on what they are capable of. There might be times when your skills are simply not enough and you need either help from others or time to learn new skills. It’s also notable that your level of energy might change during the project – on some days your diligence and motivation could spike while on other days they might be really low. Estimating projects and believing that you will have 110% energy level every day is over optimistic way to approach.
#2 – Avoid Over Optimistic Estimations About Your Time
How much time you spend on chatting, emails, eating, breaks, phone calls, and organizing daily? You must notice that if your typical work day lasts for 8 hours, you propably use some time for general issues. You propably receive interruptions in different ways. It’s not realistic to assume that you could use 100% of your time for the project. Depending on your assignments it will propably be something like 60-80%.
#3 – Estimating Too Large and Abstract Components
This is propably the key reason why projects estimates miss their targets. If you try to estimate how much would a new multiplayer FPS game would make you would need to list the components/objects. The first list might contain only big components like:
1. “Network”
2. “Server”
3. “Client”
4. “Players”
5. “World”
There’s no way to estimate durations for these. You’ll have to break your big projects into hierarchical list of smaller tasks.
For example: “Players” could be divided into several tasks:
4.1. “Player Design”
4.2. “Player Graphics and Animation”
4.3. “Player Sounds”
4.4. “Player Network Code”
4.5. “Player Scores & Ranks”
Etc.
After you have listed these taskyou would need to divide them into smaller actions: “Player Sounds” for example could have actions like:
4.3.1.”Create death sound #1: ‘aaargh’” – 2 hours,
4.3.2. “Create mock sound #1: ‘you lose’” – 2 hours.
4.3.3. “Create footsteps sounds”, 3 hours
And so on.
Now you could total the hours for each task and you would have a much better idea on how much time your project could roughly take. Breaking large units into small manageable task is essential for you to make realistic estimations. It’s up to you how detailed plans you want to have. Sometimes 2 levels is enough, sometimes 3rd level is needed.
#4 – Fixing Errors & Bugs & Other Problems
Don’t assume everything will right in the first time. There will be always errors and bugs in your program. You will need to revise your code. Putting a 10-30% time buffer for “unknown bugs/problems” is a good way to make a better estimation.
#5 – Remember To Estimate Also the Integration of Different Modules
Besides bug fixes you must notice that integration of several modules will take time. If one programmer codes the server and another one the client then you must also estimate the integration – the time it will take for server and client to work together.
#6 – The Feature Creep
Game developers – whether they are artist or programmers want to make the game perfect. They want the textures to be perfect. The code must be perfectly optimized. The rendering must be perfect. The details must be perfect. It’s very hard to make a decision when something is considered finished, but there are times when you must make sure the project goes forward. Polishing over and over will eventually lead to a non-finished product. There are times when you must make a tough decision – and accept some level of quality. It doesn’t have to mean that there couldn’t be many areas where the perfection is done – it just means making a conscious decision about where polishing is really needed and where you can survive with lesser quality. To make better estimations, be sure to add ‘feature creep’ extra time for some parts of the game.
#7 – Producer Tasks Has to Be Noticed
Meetings, project planning, estimations, project management, design document updates all are tasks which aren’t usually noticed when making game project estimations. All these take time and should be somehow taken into account.
#8 – Unclear Goals and Task Objectives
This is another huge problem in project planning. If your goals or objectives are vague, there’s no way to estimate them. If your goal for making the graphical user interface is listed as “Make a better GUI” it’s not possible to estimate duration that. What does “better” mean anyway? Does the GUI mean also designing the graphical user interface? Does it mean coding it – or is it only making the pixel graphics for it? Make sure you state and write your goals and objectives clearly.
#9 – Wrong Person Is Doing the Estimations
If you are a coder and try to estimate hours for modeling without any relevant past experience there’s no way you can do it. If you don’t have any idea on what a making of MMORPG would take then you shouldn’t do the estimation. You should either find the people who can help you to estimate or learn more about the subject. Use designers and programmers to estimate – let your team participate in the process if necessary.
#10 – If You Cannot Find Answers From the Team Members, Ask Outside
Estimating a massive game project without previous experience is a difficult process. Consider asking other game developers. Go to some game development forum and ask what people would estimate about your project. You propably won’t find exact answers, but you’ll most likely will get some rough ideas about the duration. This might help you to make a better evaluation by yourself.
#11 – Estimations Are Not Updated When the Project Gets More Content
One quite strange phenomena is to create huge timetables and large estimations for the game project and then forget these estimations. If you are going to estimate your project then you should update the estimation when you add significant changes into it. Otherwise it’s no use.
#12 – Time is Not Tracked
Without tracking your time spent on different tasks you won’t learn. You’ll estimations will remain on the level they are now – and if you don’t track your time you propably will live in a dream house believing your estimations are always correct.
#13 � Nothing is Learnt From the Earlier Projects
If you have completed or progressed in some previous projects you should store the estimations and actual durations. If you have past experience about estimating a project it can come handy when doing new estimations.
#14 – Quick Estimations
One of the worst ways to estimate projects is to do it in haste. If estimating a project takes 30 seconds you can bet that person is not doing a good job. I’ve asked many people “How much time will that take?” and listened them to answer right away: “It’s 90% complete, will be finished in two weeks.” After two weeks the same person is in the same point giving exactly the same answer. If you make estimations – don’t make them quick.
#15 – Don’t be Afraid to Be Wrong
Bad estimation that is tracked and learned from is much better than no estimation at all. If you want to make better estimations, start tracking time and making your guesses. Note how much time it took, and what changed during the project. If you want to learn, you must accept to make mistakes. Start learning, and get better on making estimations.