Comment & Opinion

"Even at NASA deadlines aren't always respected"

Gismart's Andrey Mikhlin discusses the planning process, creating estimates and executing on a product

"Even at NASA deadlines aren't always respected"

Andrey Mikhlin is head of gaming at Gismart.

Every mobile app or game project is an amalgamation of hundreds and thousands of ideas and assets interacting with each other. Each of them needs to be clearly defined and then evaluated.

The challenge is having to do all of this together while simultaneously coordinating the production order. For example, making sure that the art department will deliver their creatives on schedule to allow the engineers to start the next stage of the production process on time.

Based on my experience, deadlines get delayed in about 90 per cent of cases, regardless of the company. Even at NASA, deadlines aren't always respected, as there is no point in chasing a deadline at the risk of sacrificing your staff’s well-being or the project itself.

We have invested heavily in our planning processes to coordinate work across departments and to understand cost estimates effectively.

At Gismart, we begin planning with a Gantt chart that describes essential assets and the interactions between them. We share this document with the entire team so that everyone involved can instantly contribute with their suggestions.

Following this, we meet to assess the sprint. All employees participate in this, along with PMs and team leaders. This is critical to the process.

Since our teams are already familiar with the scope of the work, it is easier for them to give an honest assessment. Each task, for example a character's jump, is viewed from different angles - the game designers, the artists and the developers.

In general, it takes a minimum of two hours to realise this, and, because everyone is a fan of the project with their vision for it, arguments in these meets can be frequent.

At Gismart, we begin planning with a Gantt chart that describes essential assets and the interactions between them.

We break tasks down into story points (SPs). 13 SPs are a lot for a task and even eight SPs can mean that a developer won't know how to implement a task effectively.

A task should be broken down so that it can be completed in a day or two. If a developer shoots for the sky and says that the task will require eight SPs, it's a red light for us, indicating that we need to work on the task and break it down into smaller, more manageable parts.

We evaluate tasks by three vectors: optimistic, pessimistic and realistic. From here, and with the help of a simple formula, we calculate a figure closer to the truth.

Artists tend to be more precise when evaluating a task, in about 90 per cent of cases, because they, as a rule, are already experienced in implementing similar works.

It's more challenging with developers. If we make a product with new mechanics, then it's most likely that they won't have prior experience implementing them. So, first, they need to explore the topic and we need to reserve time for their research within our evaluation.

An increase in evaluation time occurs when we face an unknown task, or multiple people become involved with the task.

We usually employ a 'pure' evaluation and a 'safe' evaluation that includes extra time for risks - at least 20 per cent additional time to total project time. If development is scheduled to take a month, we add a week as a reserve. We also take into account the availability of our resources (vacations, holidays), employee experience, individual work speed, etcetera.

With simple tasks, the risk decreases, on complex ones it increases. People are always overly optimistic, especially junior specialists. The more experienced a specialist is, the more balanced their approach and the more realistic their evaluation.

People are always overly optimistic, especially junior specialists. The more experienced a specialist is, the more balanced their approach and the more realistic their evaluation.

If someone says that they need two days to implement a feature, and you understand that they are young, less experienced and underestimating the task, then the evaluation of their risk should be multiplied several times.

What it comes down to is being flexible in your approach. If your goals aren't achievable in time, then you can sacrifice features or simplify functionality to ensure prompt delivery.

A software product is not a car that needs to contain all of its parts. However, even when considering a vehicle, lots of details can be removed, even the doors, while still maintaining functionality - it can still get you to your destination.

Thus, you need to understand what the user needs clearly. It's evident that users love beautiful things but it's still essential that the vehicle moves. Therefore, we have to choose which features will be released first and which ones can wait.

At the same time, you need to build towards what you want to achieve. If you launch a product that will make money, then it must release with a specific set of functionalities to allow it to do so.

There are a large number of companies that say: "We have to release the project now because we are running out of money."

When this is the case, you risk releasing a raw product that will not make any money. For instance, any well-known company like Supercell or Blizzard won't release a product if it believes that it isn't ready.

They refine them - not infinitely, of course, but for a very long time.


  1. If you want to meet a deadline, you need to run the most risk-free and straightforward product while aiming at a set average.
  2. For young teams - don't strive to do something overly complicated, because it's better to pay more attention to delivering quality. Don't try to overload a project with a massive number of features. Further to this, you should also participate in hackathons! These are an excellent way to bolster your teamwork skills while learning how to create an MVP. We have our very own Gismart Summer Hack to help aspiring teams build their first products.
  3. The sooner the product is launched, the sooner you can understand whether someone needs it or not. However, earlier doesn't always mean better. Do not meet deadlines at the expense of quality. Think of the three components: speed, quality and cost. One or more will always work out, but the real task is finding the golden mean between them.
Tags: regularly posts content from a variety of guest writers across the games industry. These encompass a wide range of topics and people from different backgrounds and diversities, sharing their opinion on the hottest trending topics, undiscovered gems and what the future of the business holds.