How to Make Accurate Project Estimations

Can software project estimation be as realistic as possible? In this article, we share some hands-on techniques and useful tips on making the estimating process more accurate and robust.

August 12, 2021

11 min read

Project management

Why Estimation Is an Essential Stage of Any Software Project?

Many outsourcing software projects fail because their estimate is not reliable. Failure means the developer did not meet the deadline, overran the budget, or did not deliver what was expected. A study conducted by McKinsey found that 66% of software projects have cost overruns. A third of them go beyond the estimated schedule, and almost 20% of them fall short of promised benefits.

Sometimes it seems that the project estimation process can significantly increase the cost of the pre-development phase. But it is crucial to realize: the resources spent at the initial stage of the project are a good investment in the outcome. The more accurate the estimation, the more customer-satisfying the result will be. That is why a correct estimate is a crucial part of project management procedures, and it is really worth it.

What Is Project Estimation?

Project estimation is the process of calculating and predicting the costs necessary for its successful realization. It is usually handled during the project discovery stage. In software development, estimations imply making predictions regarding the most realistic scale of efforts that should be put into developing a software product. This information allows to determine the amount of money that needs to be invested in the project, the number of specialists who would work on the latter, and, finally, the time required for all that.

Accurate Estimating: A Complicated but Crucial Task

As estimating in software development is based upon incomplete, imperfect knowledge and assumptions about the future, they all have uncertainty. There is no such thing as a precise, single-value estimate.

How to do the estimation for a software project properly? If we take software development models into account, the more traditional ‘waterfall’ approach implies that all the software specifications must be provided upfront before the project estimation process starts. But now, everyone is going agile.

Stakeholders want to begin immediately after preparing brief requirements and then add new features literally on-the-go. MVPs (Minimum Viable Products) are released quickly, feedback is obtained, and improvements are made iteratively. In those conditions, planning and estimating can be rather challenging.

So the question we want to answer is, ‘How can we cover all those uncertainties and make the estimation as realistic as possible?’ This article will walk you through how we approach the software project estimation process at Upsilon and share some tips that help us make it more accurate and robust.

Estimation Process: How We Run It at Upsilon?

Let’s look at the whole process of project analysis and estimations at Upsilon: from the moment of figuring out the client’s expectations to giving the final project calculation. 


Creating reliable estimates for software development is a multistage task. At Upsilon, we always start by digging into the client’s main challenges to paint a clear picture of their business and development goals. It’s important to gather as much information on the future project as possible.

There are two main sources where we get it:

  • Online video calls via Skype, Zoom, or Hangouts: we discuss the project in general by asking questions and getting answers;
  • Documents and data provided by the client: specifications, mockups, wireframes, use cases, user stories, software specifications, etc.

All of this helps us estimate the cost of building the client’s product more precisely. The more information we get our hands on at this stage, the more accurate our project estimation will be. Here is a list of things we usually try to clarify at the very beginning: 

  • What is the pain that you are solving for your customers?
  • What are the main features of the product?
  • What platforms will the product be based on (web, mobile, back-end)?
  • What existing components or parts of the system do you already have?
  • Can you describe the main use cases of the new application? 
  • Can you prioritize the functions of the future product?  
  • Do you have a specific tech stack that needs to be used for this project?
  • What is your expected timeframe for the project?
  • What is your expected budget for this project?

Once we are sure that nothing is missing and that we’re in line with the client’s expectations, we go to the next phase: assembling the team. 

How to do estimation for a software project?

At Upsilon, we use plenty of methods for estimating software development efforts. Depending on your project specifics, our experts will provide you with a robust estimation taking into account all tech aspects of your future software product.

Get the estimation

Assembling the Right Team

After collecting all the information, we gather professionals who have the most extensive competence in the respective domain. The team responsible for the project estimation is usually composed of senior-level specialists and includes:

  • CTO;
  • Senior back-end developer;
  • Senior front-end developer;
  • Other specialists upon request: a project manager, UX/UI designer, QA specialist, technical writer, and others.

In the vast majority of cases, specialists who make the estimation subsequently become a part of a project's web development team. The key criteria for selecting that team’s members are:

  • Professional expertise: the relevant experience of working with specific technologies and similar projects;
  • Ability to start the project as soon as possible;
  • Other factors: presence in the client’s timezone, full- or part-time employment, language proficiency, etc.

Pro Tip: Assembling the right team is one of the most sensitive questions in software outsourcing. A customer wants to be ensured that the most skilled specialists with relevant expertise will be assigned to the project. That will guarantee the expected quality and hassle-free delivery of the final product. Also, customers want to see ‘real faces’ not just abstract ‘senior front-end developers’ in the estimations, in order to understand further whom they are speaking to on the conference call. That is why every estimate made by Upsilon is accompanied by a document of the CV format with key information about each team member, including his or her:

  • Expertise
  • Skill matrix
  • Project history 
  • Personal info
Example: Team member’s professional profile

Research and Analysis

During this phase, the team members set up a number of meetings to discuss project requirements, exchange their opinions, and brainstorm ideas. If some details need more clarification, the discussions may alternate with the research sessions. At the end of the Research & Analysis phase, our team provides potential clients with the following deliverables:

  • High-level architecture & infrastructure design;
  • Recommended tech stack;
  • Mockups and wireframes (if not provided by a client);
  • Desired breakdown of the team;
  • Rough timelines.
Example: Wireframes developed at the Research & Analysis phase

Defining Scope and Size of the Project

The next step of our estimation process is feature prioritization and building the scope of work that covers software requirements. At Upsilon, we use the Work Breakdown Structure (WBS), which visualizes each software development stage with related tasks.

To achieve the project's goal, we split it into milestones, which are broken down into tasks, subtasks, etc. We define a milestone as a marker that indicates an achievement or a deliverable, for example, the completion of a large task or reaching a phase in a project. For most of the projects, we figure out the following milestones:

  • Discovery phase: documentation analysis, choice of 3rd party software tools, decisions on possible integrations, preparation of wireframes (if not provided by a client), etc.
  • Design phase: collaborative work with a product owner that can include design theme workshops, brand identity design, UX and UI design, prototyping, etc.
  • Project setup phase: setting up of infrastructure, deployment of environments, configuring of security, etc.
  • Development phase: development of functionality based on user stories (and also tasks grouped into milestones). It can include user authentication, messaging, integrating payment gateways like Stripe, PayPal, or Braintree, mapping, video streaming, reporting, etc.
  • Testing phase: functional QA testing, usability testing, user acceptance testing (UAT).
  • Delivery phase: transfer of documentation and intellectual property, deployment, and implementation of the solution, including publishing on marketplaces, training, presentation of the product, if necessary, and more.

How does it work in practice? Here you can see an example of how we broke down into milestones and user stories the structure of a health & wellness digital platform.

Example: breaking a project down into milestones and user stories - Health & Wellness Digital Platform

Another significant question is to decide whether to build a turnkey solution or start from the Minimum Viable Product (MVP). About 80% of startups and SMEs we worked with had an MVP first. This may also be a factor to consider when choosing between outsourcing models. From our experience, we recommend to ignore non-primary functions by creating an MVP before the finished product, especially if:

  • Project requirements are unspecified;
  • You're still trying to find product-market fit and validate it;
  • Features must be added and tested quickly;
  • Budget is limited.

Pro Tip: When defining the scope of the project, it can be very helpful to visualize everything needed to be accomplished, organize tasks into multiple levels, and display these elements graphically. For that purpose, we use the Miro platform. With Miro's help, we develop the project's hierarchical structure that makes it easier to oversee a complex project and make sure every task gets done.

Example: a fragment of the hierarchical project structure (prepared in Miro)

When creating a WBS for a future project, we follow four fundamental principles:

  • Hierarchy: every ‘child’ on the graph has a hierarchical relationship with its parent task.
  • 100% rule: every level of the graph must make up 100% of the ‘parent’ level, and it must have at least two ‘child’ elements.
  • Mutually exclusive elements: every element at each level has to be mutually exclusive - there can’t be any overlap between deliverables or work.
  • Outcome-oriented: graphic depiction must focus on the outcomes rather than the activities required to produce them.

Project Estimate by PERT Method

After conducting a detailed scope breakdown, we start to create a more accurate estimate using a PERT (Program Evaluation and Review Technique) method. We calculate a realistic cost estimation using an optimistic case estimate, a pessimistic case estimate, and a most likely case estimate within this approach. There are different ways of interpreting the numbers depending on how we want to weight potential risks, but in most cases, we use the formula:

(optimistic + pessimistic + (4 x most likely))/6 = expected estimate

Let us consider an example to see how these formulas work. Let us assume we have to calculate the expected travel time it takes to deliver a shipment from point ‘A’ to point ‘B’. There could be 3 different scenarios:

  • Optimistic scenario: roads would be free of traffic congestion, and there will be no stopping at traffic signals.
  • Pessimistic scenario: there would be severe traffic bottlenecks (may be due to a major accident), or there will be some unscheduled stops (may be due to vehicle breakdown).
  • Most likely scenario: there would be normal traffic conditions.

Let us assume that our 3 estimates (optimistic, pessimistic & most likely) were 450 minutes, 2250 minutes, and 900 minutes respectively. Putting these values in the formulas, we get:

Expected travel time = (450 + 2250 + 4 x 900))/6 = 1050 minutes

It essentially means that, in most cases, the expected travel time will take 1050 minutes.

How can it look in a real project estimate? Let us explain how we estimated the task ‘Credits (Bank) & Prize claim’ by PERT method for a social sports application.

Example: Estimation by PERT method - Social Sports Application (fragment)
  • Optimistic scenario: 7 days (including 7 days for back-end and 6 days for front-end development. Both teams work simultaneously).
  • Pessimistic scenario: 14 days (including 14 days for back-end and 12 days for front-end development).
  • Most likely scenario: 11 days (including 11 days for back-end and 10 days for front-end development).
  • Expected estimate: (7 + 14 + (4 x 11))/6 = 10.83 days

At the output, we get an estimate which takes into account some uncertainty and risk in tasks. The PERT method can be quite time-consuming, but it can provide a high degree of accuracy.

Need more project cost estimation examples?

Our managers are always happy to share their best practices in calculating project costs. If you want to learn more about PERT and other methods of software project estimation, just drop us a line.

Contact us

Building a Timeline Chart

After determining the total time needed for each task and milestone, we build the project timeline. We line tasks end-to-end, adjust their lengths to reflect the amount of time allotted, and then add milestones. We turn that all into a solid timeline chart with expected delivery dates provided. It is especially helpful to have such visualization on projects where several teams work simultaneously on several milestones.

Example: Timeline Chart - Social Sports Application

Such a timeline chart shapes the entire project, indicating which tasks are to be completed at which stage and which resources need to be involved along the way. It also allows us to quickly see the proportion of time allocated to each project task or milestone and provides a visual interpretation of how the project will run phase by phase.

Calculating Costs

After estimating the number of hours of work required to complete the defined scope, it's time to price the project. We calculate the total project cost by multiplying the number of man-hours (estimated using the PERT method) by the applicable rates. For ease of calculation, let's make the following assumptions:

  • One man-hour = work completed in an hour of uninterrupted effort by a specialist
  • One day = a standard 8-hour working day

In IT projects, hourly rates range depending on the specialist's professional category, which is defined by his or her job functionality, level of seniority, uniqueness of skills, etc. Of course, it will not cost the same for one hour of a junior programmer as a senior one. Therefore, when calculating the cost of the project, we take into account that the multiplication of the cost must be factorized by the hourly rate of each professional category:

Total cost = (RH1 x H1) + … + (RHn x Hn)

In this formula, RH1 is equal to the hourly rate of the professional category #1, and H1 is the total number of hours estimated by the professional category #1.

How does it work in practice? For example, we estimated a software project and got the following numbers:

Example: Calculating the cost of the project

The total cost of the project will be: 50x180 + 40x150 + 30x60 = $16800

What’s Next?

Having put all things together and made our calculations, we share it with the client in person, explaining our estimation instead of just sending over a number without context. We schedule a meeting and go over the document with them, row by row. It allows us to discuss any questions that may have come up along the way. If it becomes clear that the project isn’t doable within the client’s limitations, we can also help to prioritize the functionality and start by developing a minimum viable product (MVP) or even a proof of concept (POC). We try to include this kind of out-of-the-box thinking in our estimates whenever possible, to add value at every step of our collaboration.

Keep Reading: POC vs Prototype vs MVP: Explaining the Difference


Estimating is prone to error. The overall complexity becomes fully visible only at the point of execution. In the conditions of uncertainty and lack of information, there is a temptation to provide lower numbers to outbid the competition. But that doesn’t mean that the final price for your product will be lower. It may just mean more stress, more unforeseen costs along the way, and as a result, your dissatisfaction. And this is definitely not how great products are built.

Our goal is to predict as closely as possible. Of course, some things can change, especially if a project evolves unexpectedly or if a client comes up with new ideas during development. But in most cases, when we give an estimate, we stick to it.

The best way to find this out is to partner with us. You can follow our processes, share your thoughts with our developers, and enjoy our transparent communication and quality approach firsthand. So, don't hesitate to contact us, we will be happy to do our best to make your ideas happen.

Get an accurate project estimation from the top IT company

In software development, raw numbers are almost nothing. At Upsilon, we try to delve into project requirements, assumptions and limitations as deep as possible. This helps us deliver estimations that work.

Contact us

Frequently asked questions:

1. How can the estimation influence the software project?

Estimating is a key contributor to ensuring project success, and something that all project managers should learn. Project cost estimating is linked to so many other aspects of the project, including but not limited to, scheduling, resource planning, procurement, and stakeholder expectation management.

2. Who should create the software project estimate?

A person with sufficient experience and expertise in the required technology stack should create an estimate of the project’s costs. Under most scenarios, the lead estimator must also have a background in project management.

3. How to make the project estimation more accurate?

Making estimation more accurate can be achieved through defining the project scope and splitting it into components be it specific features or tasks. By breaking down the work into smaller tasks, you’ll get a clearer picture.

4. What can underestimating a software project lead to?

Underestimating a project can lead to understaffing, underscoping, and setting a too short schedule. This can result in missed deadlines and loss of credibility.

5. What is overestimating dangerous as well?

If you give a project more resources than it really needs without sufficient scope controls it will use them. The project is then likely to cost more than it should, take longer to deliver than necessary (resulting in lost opportunities), and delay the use of resources on the next project.

6. Why to use the PERT calculations for estimating software projects?

The advantage of the PERT method is that it reduces risks - by taking into account best, worst case and most likely outcomes, you get a project estimation that takes into account some of the uncertainty and risk in a task.

Project management

Join the newsletter to receive the latest updates in your inbox.


Now you will definitely not miss anything.
Oops! Something went wrong while submitting the form.

Join the newsletter to receive the latest updates in your inbox.


Now you will definitely not miss anything.
Oops! Something went wrong while submitting the form.
Featured posts
to top