Why the initial estimates are inaccurate

If you’re familiar with mobile/web software development, you know that estimates are pretty important in the process. Especially for the Client. One of the first questions before the development is: How much will it cost? In most cases people won’t be willing to start a project without knowing how much they will pay and how long it will take. In case you don’t know a thing about it, you can go back to How to proceed with mobile app development to dig into the topic. So by explaining why are the initial estimates inaccurate, this article will show you that:

1. Predicting the time (and therefore the cost) that a particular project will take is very important but really not easy
2. Common understanding is key to avoid trouble - the client wants to know as much as possible and the agency needs to understand client’s business needs first
3. Estimates usually change during the project and it's nobody’s fault. It’s a natural process during development.

How important are the project estimates

Some reasons why the estimates are essential in mobile and web app development process:

• They help to align workflow with available resources by giving an overview of the whole process
• They are useful for the development process and project management. Estimates generate a detailed list of schedules and deliverables that can be put into a project roadmap
• A detailed estimating process helps reduce risk of what a client can call a “hidden cost”
• You can plan your budget flexibly in order to allow for future development 
• They help to build better relationships. Clients who understand what is the scope under every cost trust the agency more and are more willing to cooperate as they feel involved in the project. 

Some problems cannot be foreseen 

Making project estimates can be pretty challenging. It’s actually like calculating time for any other task apart from development. Just imagine trying to predict how much time it will take to complete every task you take. It is also not easy to assess one's own capabilities. Some people have too high self-esteem, others are too critical of themselves. But it is almost impossible for anyone to be able to evaluate their own abilities perfectly. They vary according to experience, so a senior developer won't help a junior much in this regard. 

No matter if it's the developer's or anyone’s task, it involves a certain level of risk of unforeseen complications. Some of these risks can be predicted, and some cannot.

Classic examples of complications that can be expected:

→ When the task requires the use of another off-the-shelf solution and it may not provide us with the capabilities we need to complete the task 

• Example: we use an existing library for drawing graphs and it doesn’t provide the ability to add a legend in a clear way. 

→ When the task is to edit existing code, which may be written in such a way that making a specific modification would be cumbersome

• Example: we want to divide a list of items into sections, but the whole code is written so that it assumes continuity of items and will stop working if we add sections.

→ The assumptions made in the task do not take into account all scenarios 

• Example: a draft list of items is created and it’s not predicted what will happen if the list turns out to be empty. Although such an oversight may seem unlikely, it does happen. It is easier to imagine, for example, that the design takes into account small and large screens, but looks inaccurate on medium-sized screens. 

Why analysis isn’t enough

One of the most important things in app creation is analyzing. It’s also partly a solution to make accurate estimates. The more the team knows, the better are the estimates. Lack of good analyses is one of the most frequent mistakes in the process. You can read more about analyses and their importance in Common mistakes while creating MVP and how to avoid them. 

The occurrence of the above risks can theoretically be expected during the estimation, but they cannot be eliminated from the outset. The time developers spend on analysis is not enough to determine whether all features are possible to implement. Actually, there is never enough time to foresee everything as things included in the project are often very complex. 

Conclusion

Some things can only be seen during development, only by making an attempt to implement a given feature. 

There are also problems and bugs that are impossible to foresee. An example from FiveDotTwleve’s life is when a grey screen appeared in one of the mobile apps we created, but interestingly only on iPhone 12 Pro Max. On every other device everything worked fine. How could we know this might happen? We could only take the risk of an unexpected error into account, because it turned out that we had to fix this particular problem on this particular device. 

Story points estimates

Also because of the above, there’s a better way to make project estimates. Story points are basically units of measure for estimation purposes. Story points express the effort required to implement any piece of work. It means that software developers can estimate their tasks not only based on one factor (which is time needed to finish the task) but many more, like complexity, amount of work and risk of uncertainty. The whole article about Story Points written by our project manager here. 

Estimate with historical data

Another improvement is to take historical data into account when making estimates. It is always helpful to predict things based on similar tasks done in the past. When it’s time to estimate and determine project cost, project managers always ask developers if they’ve done particular things before. And if so, to take it into account and try estimating on this basis. 

You want to do all at once

It’s essential that as a client you have your priorities assigned. If you aren't sure about your needs regarding the project scope it’s impossible for it to be successful. The team will spend way too much time on doing unnecessary things. This is also important at the end of the project, just before the release because you might have to choose between two options. 

This is both for clients and developers: decomposing tasks is essential to make accurate estimates. So as a client you have to understand that prioritising tasks is crucial to make it possible for developers to estimate accordingly. And as a developer you should require this from the client, then decompose all tasks into smaller ones. This way you’ll be able to calculate more accurately. Sometimes when you think about a particular job to do, you imagine it's a maximum of one day of work. When you divide the whole concept into small activities it turns out that each of them can take a couple of hours. This way you’ll know better how much time it might take.

You’ll probably change your mind 

It’s not like you’re being judged. But it happens very often that clients are not sure about the solution until they see it. So don't worry, the team can always change the design, add or remove a screen etc. But remember this will also change the estimates and it’s a natural part of the project. 

Remember that you’re working with a team of experienced specialists. Don’t decline their suggestions and advice. The software development company does the research regarding your business and the similar ones. This research can be carried out together with the client. It helps the team understand the insights of your business and determine whether a certain feature or solution would be valuable and if they should spend time on it. 

Summing up

• Remember that you can’t treat estimates as a final result. It’s almost impossible to make perfectly accurate estimates at the beginning of the project. And it’s nobody’s fault, it’s just the way it is 
• Making estimates is a flexible process running throughout the project, not only at the start 
• The more specifics you deliver (regarding your requirements) the more accurate are the estimates.

If you have any further questions or you'd like to get an estimate for your project, don’t hesitate to contact us here.

Want to learn about hourly estimates and story points? We’ve got the whole article written by our Project Manager about it here. 

Models in mobile app development pricing might also interest you. See how we manage pricing at FiveDotTwelve and which method would work best for your project.