Blog / Tech / app estimation

How do Companies Estimate Software Projects

  • Rating — 4.9 (18 votes)
  • by Tony
  • Updated on April 05, 2021
  • Read —
    16-17 minutes

When it comes to software development, the question that many clients tend to ask right away “How much will my solution development cost?” Unfortunately, software development is a service, not a product, and you can’t give a price tag instantly. And although it is possible to provide some kind of its estimation, it is not as easy as it seems. 

You may think that this is an easy equation in which time = money. So if you define time needed for the development, you’ll get the price you need to pay. But, unfortunately it’s hard to estimate the exact time needed to complete something as big as software, especially if it is a business intelligence tool. This means that the specialist should sit down and write a huge list of tasks, TO-DOs, risks, required tech takes and time needed for them to complete the development. So as you can imagine some major miscalculations are possible. 

That’s why when someone gives you a quote immediately or claims that it has 90% accuracy and there will be no major price changes, don’t buy it!

Estimation is a complex process. Moreover, final accuracy of the quote is largely dependent on you and how well you understand the development goal and objectives. Therefore in this article we would like to discuss the estimation topic in detail. We will explain how the projects are estimated, what factors are taken into account and how we perform estimation in our company. 

lamp
Have your own project in mind?
We can provide you with a free consultation and suggest further actions.

Inputs required for Estimation

estimation inputs

There are several basic ingredients required to complete any kind of estimation. They are the overall scope of work, story points, development risks, and technology stack. The accuracy of any quote depends greatly on them, so to understand what each of those components imply, let’s take a closer look at them. 

Scope of work

This is a first and foremost factor influencing every software development estimation. Here is how everything starts – you contact us, share your app idea and together we shape it into a project plan. The stage on which everything is performed is called the Discovery. It helps to discover all the unknowns, formulate high-level project description and requirements, plan the development itself and write specifications document. 

No one knows your business better than you do, that is why the result of the Discovery stage and determination of the scope of work depends on our mutual efforts. Your input on this stage is irreplaceable and it influences the accuracy of the quote.

But do not worry, as we won’t ask anything that goes beyond your competence. We’ll help you to crystallize the idea without getting into technological debris. We have Personal Client Managers, Business Analysts, and Software Architects for figuring out everything related to the tech side of your project. They will tweak and adapt your idea to technological standards and industry requirements. So your main task is to let us know your idea, the challenges you would like to resolve with the software and expectation you put on it. 

So what we may ask you about is some basic use cases you may need, the functions and features you require and the list of currently used solutions (if there are any). 

Upon getting those answers we’ll make work breakdown structure, which divides the project into separate tasks.

E.g. You Project = Function A + Function B + Feature C (module 1 + module 2).

The more detail we can get the better estimate we provide. On average, we have three detail levels, depending on the amount of information provided by the client:


Rough estimation
This particular type offers up to 40% accuracy. It is mainly based on your defined project goals, challenges you want to solve with the software, and rough use cases you may have implemented. By receiving a rough estimation you can get an understanding of how much your project may cost and how long it may take to build it.
Detailed estimation
This type of estimation if more precise and has up to 70% accuracy. It is provided based on detailed description of use cases and features you want to have in your app. Detailed estimation also takes into account possible risks we may face during development.
Pre-development estimation
This is the most accurate type that has above 90% accuracy. While creating this type of estimation we take into account the specifications of the project, which include thorough description of each use case, function, and third-party integration or service that will be implemented.
 

Keep in mind that small projects or those with detailed inputs and design allow us to provide Detailed Estimation from the very beginning. Which is very advantageous and lets us proceed to the development itself a bit faster, and this in turn reduces your time to market and overall development time. 

📃
Suggested post
We’ve mentioned that it is crucial to take good care of all technical documentation to receive the most accurate estimate and to be able to mitigate development risks in the future. In case you are wondering what peculiarities tech documentation has, check out the post we’ve written about it.

Development Risks

Risk is a general naming for all assumptions and constraints that may or may not affect the project. As we proceed from stage to stage, those assumptions convert into details and constraints are solved.

There are two kinds of risks we account during estimation: internal, and external.  Let’s describe them in detail so that you can get a clear understanding of each kind.


Internal risks
They are associated with previous experience, uniqueness of technologies, and software solutions we’re going to integrate. The more experience in particular field we have, the more accurate we can estimate the project. Let’s make it clear: having risks does not mean that we can’t create something. Risks just indicate the difficulty in accurate estimation (up to 70%) of particular tasks.
External risks
They cannot be predicted based on previous experience of our team. Usually, those risks are unique for every project. External risks are related to third-party API, legal issues, industry requirements, etc. For example, our client wanted to make mass payments via PayPal and get in-detail breakdown on every transaction inside this particular mass payment. PayPal’s API by default refuses to provide a breakdown, thus, we had to dedicate an additional time to overcome this constraint.

Organizational risks
In addition to the external and internal, there are organizational risks that may occur during your project development. Such risks are solved through transparent and professional communication with Project Manager. They are much easier to avoid if the team uses Agile methodology like we do.

At the end of the day, you should not be worried because the most of the risks are solved during specification stage by our Software Architect and Business Analysts. This work is included in specifications price, as well as the search for suitable technologies. Also if you choose a team that has an extensive experience in building solutions for your particular business niche, then the chances are that you’ll face less risks on your way to app release.

🧐
Good to know
Some of the development risks can be easy to mitigate, however others can become a real challenge. So what should you do? The best thing is to examine them all and pay attention to helpful actions. We have described them all in our article.

Tech stack

Each tool has its purpose. Some tools are better suited for solving specific problems. Some technologies require more expensive specialists. That’s the reason why one technology stack can be cheaper than another. Frameworks, for instance, can save you a lot of time coding. Ready-made code solution does this trick too.

In most cases, the decision whether to choose certain technologies is made by the development team. All you need to define is tech stack, programming language and specify if there are any must-have integrations. After you’ve done it the team will do its job. Business Analysts will let you know how many tech takes and of what specialty will be required, the number of development hours each specialist will need to complete your app, and the hourly rate of each programmer, etc. The hourly rate depends on the qualification of the developer.

For example, the work of middle one will cost you less than the work of senior. But the selection of the specialists depends on your project complexity and feature set that should be incorporated. Sometimes the job can be done only by the professionals of the high level. 

lamp
Need a quote?
GBKSOFT team can help your with your project estimation and development! Get a solution that fits your budget and meets your key business goals.

Software Development Effort Estimation

estimating costs

Talking about efforts we need to answer three questions:

  • How long each task is going to take?
  • Who do we need to deliver each task?
  • How much will it cost?

So as you’ve probably understood from those questions – it’s all about Time, People, and Money. Some people tend to think that if you hire more developers but of less qualification, then you’ll get your project done faster. But it is not really true. Let’s speak about some interesting cases to understand how everything really works.

System we use to grade developers

The hardest question to provide an answer to is “How much time will it take to build my app?”. That’s where you go for experience of the developers. You probably heard of junior/ middle/ senior qualifications of programmers by their experience level. But this grading system is too rough to give accurate assumption about time. The error chance can be up to 50%.

For example, one middle-leveled programmer may require 5 hours and another one 10 hours to complete the exact same task. Of course, you can make time-limits and force people to stick to them. But this leads to the loss of quality, and you definitely do not need that.

That’s why we use our own qualification system for developer’s skills assessment. It’s based on:

  • historical performance data,
  • types of projects he has worked on,
  • his overall skill set and expertise,
  • regular proficiency tests.

Thus, depending on a developer’s grade, we can say more accurately how fast can the certain task be solved without any loss in quality. That is why on the stage when we write specifications and select tech stack, we think about the developers. We carefully select who would do the job, take into account their average productivity rate to get the most accurate estimation and calculate how many hours they may spend developing your particular solution. 

How we estimate the time

Once we’ve got all required project ingredients like tech stack, necessary developers, list of involved specialists, well-written specifications document, our Software Architect and Business Analyst can estimate the time required for your solutions  development. This task is performed by using several approaches:


Group estimation
This type is based on judgments of a group of specific developers. This is by far the most undesirable way to make estimation because developers tend to overestimate the time needed for certain tasks. That is why we never base the final numbers on it.
Judgmental combination
This one is based on estimates received from a group of experts, senior programmers, team leads, and Project Managers. The number of hours we get is more accurate and realistic than the one received after the group estimation.
Analogy-based estimation
Our developers and other involved experts provide the number of required development hours based on previous experience and time logged for specific tasks. This works perfectly for projects if they are built for the similar business industries.
Expert estimation
This approach is used in 99% of quotes we make in our company. “Expert” means made by Software Architect and Business Analyst. During such estimation we utilize statistics from project management software. Plus, we use company-specific activity templates designed by our team.

Should you hire a second developer?

There is a joke between Project Managers: two women won’t make you a baby in 4,5 months. Meaning no matter how hard you want it, you won’t speed up a project by 50% by adding one more developer.

Based on our experience we can state that one extra developer on the task gives no more than 30% speed boost. Yes, that’s better than nothing, but it is definitely not what you expect from such a “team extension”.

You may be wondering why exactly it is how it is. Well, to start, one needs to understand that we do not clone people but put a new individual. A man with unique brains, coding, and problem-solving approach and skills. Add to this the simple fact that you can’t put two pairs of hands on one keyboard and the answer is clear.

Putting a second developer means dividing tasks on the project between several team members. But development pace won’t become faster inside a single task. That’s why the budget often increases disproportionately to the number of specialists added to the project. If you want to speed up development works by 50%, you should get ready for ~70% budget rise.

To back up or not to back up middles?

Luckily, there is a way to help middle developers if you hired ones and now struggle to speed up the development process. That’s exactly why you sometimes need to add a Team Lead or Senior Developer in addition to Project Manager. Senior Developer is a problem solver who is meant to mitigate risks and help middles with the most difficult tasks.

Team Leader is like a curator, who increases the productivity of less experienced programmers.

One middle developer will battle task 1,5 times faster if he will be backed up by the senior programmer. This way we can decrease development time without extreme rise in development costs. Because you’ll pay only for 3-4 hours of “senior backup” instead of hiring him full-time.

How many senior back up hours will your project need? That’s where we need to define software risks, internal and external. The amount of time directly correlates to risks and uncertainties your project has. Most of these risks will be solved by Software Architects at the project planning stage. They will find software solutions, third-party modules and code samples that are familiar to lower specialists, thus decreasing the need for senior programmers.

Some popular approaches to estimation

While searching for your development partner and collecting the information about companies’ values, approach to work and many more, you may notice that the approaches to estimation will differ as well. This happens because companies can use different project management methodologies, handle the tasks and time frames differently, and be more open to emerging trends. So we offer you to take a look at the three most popular estimation approaches together and to compare their pros and cons.

Story Points 

This is an abstract type of estimation that is suitable for Agile methodology. In general it describes the complexity of work, its overall scope, and touches the elements of project backlog. Story points are used when you do not have a fixed budget and strict deadlines, but there are high-level project requirements. So the estimation is not detailed but rather an abstract.

Story point itself is the smallest abstract index describing efforts needed to complete the set task. Here are some parameters that are included in this type of estimation:

  • The amount of workforce needed to complete the task (it depends on how big the users stories are and how long it may take to complete the necessary job according to them);
  • The complexity of the work (how hard it will be to complete the task);
  • The risks and uncertainties that can influence the development according to user stories;
  • The knowledge of the team members (how much they know and how helpful that info is for the development).

If you estimate every element of backlog in story points, then you will be able to get overall project size. And here is the formula that will let you get a project timeframe:

Overall project size ÷ speed of team work = project development time 

Based on the time you get you can set deadlines, define scope of work per certain period and create a precise schedule. It seems like an easy and effective method, but yet it has its disadvantages.

  • The team often tends to overestimate required working hours;
  • The accuracy of the estimation is questionable and team may not understand the story points criteria;
  • Project velocity depends on knowledge and expertise of all team members. So any changes in team or replacement of the specialist will have its consequences influencing the speed.;
  • You will not know the exact development terms.

Man Hours

This approach is perfect when we have well-defined backlog, know all project details and are obliged to complete the job within a certain time frame. For the client everything is clear and transparent.  And the development company from its side should show the necessary development term in days and time that can be estimated and paid for.

And now as to the real numbers, for example, well qualified software engineer can work effectively 5-6 hours per day. So if a software engineer states that a certain task will take him up to 8 hours, we should understand that his effective work will take around 75%. So while defining his Capacity per Day we should re-estimate the task that should have taken 8 hours and set 10 hours for it.

Although such estimation approach is better than Story Points, it offers more exact dates and terms, it has its major cons as well:

  • The team members tend to underestimate the number of required working hours because thy take “Sunny day scenario”;
  • Only the person who is going to perform the task can provide a real estimation;
  • It requires a high competence and expertise level of the whole team;
  • You need to understand all requirements and and software architecture should be high-class.
This is a process when you calculate how many months, days and working hours your project development will take. These numbers allow the company to provide you with the final project price based on required effort and working hours spent of development of your solution.
There is an approach called no-estimate, however it does not imply the full absence of this process. It is about minimizing the time and effort spent on estimating the project and it has its metrics. They are Work in Progress and Idle Time (the delay time on each stage). Such approach is not suitable for projects with fixed scope of work, schedule and budget.

Bottom Line

An accurate estimate helps everyone. It helps stakeholders to have a confidence in their project. It helps a vendor partner to manage its own team. It gives our team members a reasonable development schedule, so they could work without a rush and deliver without loss in quality. And, of course, accurate quote reassures that you will get your product within a set budget and time.

lamp
Looking a reliable team to estimate and build your solution?
We have 9+ years of experience and many clients satisfied with our services. Contact us right away to discuss your idea and get a truthful quote.
Tony Tony Sol is the business development manager of GBKSOFT, overseeing the production of all writings for both internal blog and external platforms. He is technical-driven person always looking for new benefits of merging business and software.
Evgeniy Evgen is a key person that makes your project scalable and easy to maintain. Thanks to his advanced and deep knowledge of innovative technologies our team can produce project with high level of complexity and loading. And apart from being a great expert he's also a reliable team player ready to back you up.

Close

Leave a Reply

Categories

All articles Business Company News Marketing Tips Our Awards StartUp App Ideas Tech Tech News Review UI and Design
GBKSOFT Team photo
A-mazed to meet you!
We are GBKSOFT software company.
Thanks a lot for reading your blog
Since 2011 we create ambitious software projects from scratch.

How can we help you?

  • Indicating scope, timeframes, or business challenges would allow us to provide a better response
  • Our expert team will get back to you within 24h for free consultation
  • All information provided is kept confidential and under NDA

Looking forward to your message!

spinner