Your supervisor gave you a project and said: Start.
One of the first and most important steps will be the estimation of the project. After all, all interested parties want to know: how long will it take to implement this project. How much money will it cost to create it, how many people will be involved and what technical resources are needed.
In the end, you and the team need to understand what tasks will have to be performed in the process of creating this game, application or site.
To all these questions, a special procedure is called for, under the general title “Project Estimation .”
A fast recap
My friends, the articles from the “Way of PM” series are intended for those of you who are just starting out as Project Manager in the gaming industry or IT sphere.
That’s why in the last article I told you about how to draw the Mind-Map of your projects and do not miss anything.
And even earlier, in the previous nineteen lessons, I talked about where you need to start and what awaits you ahead.
And today I will describe to you a procedure that you will have to do dozens of times when creating a new game or application. In addition, the accuracy of the assessment is very important and can make the customer, your management and your team happy. Or very upset and angry.
Want to know how? It’s very simple.
If you have evaluated the team, submitted calculations and completed the project ahead of time, the customer will save his money, nerves and time. So it will be in an excellent mood and this joy will be transmitted further along the chain to your leader, your team and you
But if you go wrong with the estimation in the other direction, you will make the game longer and tell the customer that you need more money, then the mood will very quickly start to deteriorate among all those around you, and the atmosphere will be permeated with electricity and malice.
How to do it?
In one of the previous articles, I wrote that you need to write down the project’s vision of the customer as accurately as possible and get a Technical Task from it, and, ideally, also User Stories.
Next, you must build a team that is supposed to be working on this project. To supplement it, at least for the estimation time, with the most technically savvy and experienced developers who will help to form and describe the architecture of the project and its style.
And start splitting it all into pieces.
Before the beginning of the meeting clearly state its purpose and set a time limit. All that you did not have time to transfer to the next meeting. Sitting more than two hours at a time is not productive.
How to split the scope?
First, divide everything into the largest pieces, the directions of work. Even if you are technically poorly prepared, you should logically understand that drawing game characters and writing a combat balance sheet is a completely different direction of work. If the project vision mentions multi-user game modes or the ability to download your content, then you understand that somewhere there will be a server and will have to establish a client-server connection.
Honestly, I do not think that anyone is able to learn all the technologies and paint the whole volume of tasks, but it’s not required.
You, as the leader and moderator of the meeting dedicated to the estimation of the project, create an Excel spreadsheet in which tasks will be written vertically, and above, horizontally, will be written which of the specialists will work on creating the project.
And then start writing big chunks: Art, Server, Client, Localization and so on.
As soon as the work begins, the team will cheer up and begin to break up each piece into smaller tasks.
Of course it will be a very big plus if you thoroughly know the technologies that will be used in the process of creating the game and will be able to point the team yourself to the problem areas.
Sometimes you want to be a Techno-priest from Warhammer 40k, and know all the technical details. But more often we are just a Servo-skull and can only help developers to schedule the project for the components of the task:
Split, split, split
At the stage of splitting the project into tasks, you will need a large board in order to draw architecture diagrams, user interface outline and various ideas.
A good, detailed list of tasks is one in which each task takes half a working day of one person or less.
Often the scope of the project estimation is very large and takes a lot of time.
You must have a solid character and repeatedly collect the developers for estimation and planning. Until then, until everything is painted.
The second side, which will rush you and say: “Start the development faster!”, This is your leader.
You must explain to him the importance of competent planning and insist on its full implementation.
And now – estiamtion.
When all the tasks are scheduled, it’s time to move on to the estimation of the project. It is considered that at this stage all developers should be present.
Sometimes you will be told the following: “I’m a designer, why should I attend the estimation of creating a server?”.
And this is done later so that the whole team knows how long it takes the work of their colleague and could adjust their speed in accordance with this specialist.
Once again, I repeat that all tasks should be recorded in the table, and from there they will get into the task manager that you use. For example, in Jira or Trello.
The table should look like this:
On the left, in the first column, the task “Draw the coat of arms of the Guild of Archers” is written. You find a column above which “Illustrator” is written and together with it you put forward a hypothesis for how long it will cope with this task.
When all tasks are estimated, you summarize the time for each specialist, see which direction will take the most time and learn the cost of the whole project, as well as its duration.
And at this point you need to make know what?
Stop and show professionalism.
First, go through the tasks that take the most time and ask the developers to explain why this should be done for so long and whether this time can be shortened.
Then look at the calendar and add to the date of the deadline all the holidays of all team members.
If the project takes more than two months, you can safely add a few days to sick leave and days off. And do not forget about the holidays and vacations.
Think about what projects there are risks and in a separate document write down how much each of them can take time in case it is realized.
Also remember how many of the last time each of the developers made a mistake in their hypothetical assessments of the tasks and add these percentages to its estimation. Most often this is from 30 to 50 percent, although there are developers who are very accurate in their estimates.
And now there will be a part about which you do not need to tell the team. Take all the time for the project and add 10% to it. This time is guaranteed to go into unaccounted risks.
Not so fast!
But it is still too early for you to go with these calculations to the management and the customer.
Immediately break the entire volume into work stages and plan a presentation at the end of each stage. Estimate what will go into the MVP (minimum viable product), that in the first version, that in the second and when all functionality will be implemented.
When talking with customers, focus on how soon they will receive MVP.
Next you need to decide which blocks you can throw out of the project and how much time and money it will save. Mark these sections of work and now you can go to the supervisor.
Most likely, he will want to make adjustments to your work plan and estimation. It will require that you reduce the number of working days and work overtime.
Be firm and show what functionality you can not do, and also tell how long it will save.
You do not have to agree in advance to overtime, because they will be anyway.
In addition, your director can make adjustments to the assessment that will be sent to the customer.
When you approve the work plan and terms with the management and the customer, you can divide all the work into sprints and record all the tasks in the tracking systems.
Try it on the small!
I tried to write this article so that it was interesting and you could immediately start planning and estimation of work.
Try to estimate a small project, which lasts two or three days, and then go on to more complex and larger projects.
I wish you multimillion-dollar sales of your game and easy to communicate customers.
With you was Einar and the online school of the company “Take Games”!
Develop the gamedev industry, effectively advertise your companies and order games development outsourcing from us.
Share this article to your friends, read our blog and join friends. It’s very important for me and helps to understand how interesting you are!
P.S. The list of articles in this series:
- The Way of PM
- How to walk this path – self motivation
- “Time Lords” time-management for PM
- Where to start your Way of Project Manager?
- The Way of PM: Employment in practice. Your resume.
- The Way of PM: In a new place!
- The Way of PM – Let’s become rich!
- The Way of PM – Let’s become rich! Part 2
- The Way of PM: Papers and teams. Be a leader
- The Way of PM: Different people working in the same studio.
- The Way of PM: Workplace and business processes
- The Way of PM: Special, mental magic! Mind map
- The Way of PM: Estimation of the project. How not to fail.
- 4 falling graphics. Only one is good Burndown Chart.
Even more useful info here: