Can software project estimation be as realistic as possible? This article will walk you through how we, at UpsilonIT, approach the estimating process. We will also share some hands-on techniques and useful tips on making it more accurate and robust.

Introduction

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 process of estimation 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 a process of calculating and predicting the costs necessary for its successful realization. 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 suggesting 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: Complicated but Crucial Task

As estimates are 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.

A more traditional ‘waterfall’ approach implies that all the software project specifications must be provided upfront before the 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 UpsilonIT and share some tips that help us make it more accurate and robust.

Estimation Process: How We Run It at UpsilonIT

1. Preparation

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: software specifications, mockups, wireframes, use cases, user stories, 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 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 or mobile, native or hybrid)?
• 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 technical 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.

2. Assembling the Right Time

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 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, including in order to understand further whom they are speaking to on the conference call. That is why every estimate made by UpsilonIT 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

3. Research & 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

4. Defining Scope & Size of the Project

The next step of our estimation process is building the scope of work that covers software requirements. At UpsilonIT, 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. At UpsilonIT, 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, payment integration, mapping, video streaming, reporting, etc.
• Testing phase: functional 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.

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. From our experience, we recommend to ignore non-primary functions by creating an MVP before the finished product, especially if:

• Project requirements are unspecified
• Product market fit is not validated yet
• 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.

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.

5. 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.

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.

6. 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.

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.

7. 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:

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

8. 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.

Conclusion

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. We will be happy to do our best to make your ideas happen.

Liked the article? Follow UpsilonIT on dev.to for the latest tech know-hows, best software development practices, and insightful case studies from industry experts! Remember: your likes and comments are fuel for our future posts!