Ins & Outs of Estimating Software Projects

What Is Software Development Estimation?

The success of a project largely depends on its accurate assessment. Estimating a software project is challenging as it requires an understanding of all stages of the project, experience in solving similar tasks, and a good command of software tools.

Each development company works on a project in its own way, so we are going to tell you how a software development project is evaluated here at Integra Sources. 

When a customer comes to us with an idea for a software product, he or she, at the outset, wants to know the development duration and cost.

First, the customer receives a rough estimate. It may differ from the final cost, but the customer immediately gets an idea of how long the development will take and how much it will cost.

Then, specialists delve into the development details and create a detailed table, which displays the minimum and maximum estimated hours for each project stage.

The estimate always contains a range of minimum and maximum estimated hours. The range can be small if we’re dealing with a routine project and significant if the project is complicated.

The minimum number of hours can be spent in the ideal course of the process when everything goes like clockwork, which rarely happens in real life. The maximum number of hours includes the time needed for correcting bugs, searching for optimal solutions, etc.

In addition to the project duration and cost, customers often want to know what software tools will be used to create the program: programming languages, libraries, and frameworks.

A software app project estimate may have a portfolio with apps created by the team and app screenshots so that a client could evaluate the team’s UI/UX design skills.

Project estimates may also include team size if the client needs to meet strict deadlines or wants the work to be done as quickly as possible.

Software project evaluation depends on many factors. Let's list just a few of them.

• Project development specification

The team should clearly understand the objective and scope of the project to make accurate software development estimates. The more details the client provides about the future software solution, the more precisely the development team can estimate the project duration. 

All customer’s ideas and requirements regarding the software product are set out in the project development specification. The customer can prepare a requirement document in-house or entrust it to an outsourcing development team.

Some project categories, such as medical software and electronics development, require the customer to carry out a lot of preparatory work. The client prepares a discovery phase report that contains a detailed product description, a proof-of-concept, software UI/UX design, and many other details. The team uses such a report first to evaluate the project and then throughout development.

• Project size and complexity

The larger the project and the more tasks it contains, the more difficult it is to estimate its duration. Complex project evaluation is usually carried out by all the team members involved in the development.

• Experience in developing similar software products

Evaluating a typical project (for example, Windows audio and video drivers) will not take much time or cause any difficulties. A rough estimate will practically correspond to the final development cost.

Estimating the development of a completely unfamiliar software product is much more challenging because the team has no experience with similar solutions.

• Software team skills

If software developers are fluent in all the tools necessary for a given project (programming languages, libraries, frameworks, and development environments), then it is much easier for them to estimate the duration of each project stage since they clearly understand all the tasks and can foresee possible issues.

What Does a Project Estimate Consist of?

The hours allocated for a project can be divided into two parts:

• development hours;
• hours of additional activities.

Let's talk about the hours allocated for development. The team uses different criteria for software and hardware development estimates since the objects of evaluation are different. 

Software development can include application design, interface layout, database design, server software development, library creation, frontend and backend development, etc. 

Electronics development may include schematic and PCB design, PCB assembly, FPGA design, and embedded software development (very often, it goes without an interface, so the embedded software estimate will be different from the app estimate).

Development duration also includes the time required for electronic components (for hardware development) or the customer's device (for software development) to arrive.
Pauses caused by long component delivery and parallel development processes are clearly visible on a Gantt chart. It is a must-have for  IT project estimation as it shows the project schedule to the customer and helps distribute the workload between developers.

The additional hours estimate has the same components for both software and hardware projects. It includes testing, debugging, preparing documents, project management, communication, and handover. Additional activities take up half the project time, or even more, and grow with the project size. The larger the project, the more time is spent on it. 

PCB and electronics testing can be carried out in special laboratories if necessary, which increases the number of testing hours. 

The project budget can also include pre-certification activities.

When developing an electronic device and its embedded software, we first estimate the hardware development hours since the software part will depend on what electronic components we will use. If the task is to design a device and a mobile application for communicating with it, then the evaluations of the hardware and software parts can proceed in parallel.

Please note that changes in electronic component selection will invariably affect embedded software, meaning development hours can increase significantly.

Estimation Techniques

There are many approaches to effectively estimating a software project and its critical parameters such as cost, scope, and time.

Analogous estimating is based on comparing the effort needed to complete a project with a similar project finished in the past. It is suitable for typical projects or stages where experts are confident in every development step. Analogous estimating helps save time and resources as the team does not evaluate each task from scratch.
Top-down estimating is a form of analogous estimating and is based on expert opinions.

Bottom-up estimating covers the entire scope of a project and implies calculating the cost and time for each task. This detailed approach involves all team members and focuses on the smallest details.

The bottom-up approach is suitable for non-standard projects or stages, especially if the team has no history of running similar tasks. By working through all the development steps, programmers can find ingenious ways to complete a task in a shorter time without losing quality. 

Three-point estimating uses optimistic, pessimistic, and most likely scenarios to find an accurate project estimate.

There are two calculation formulas.

1. The triangular distribution is a weighted average of the optimistic estimate (o), the pessimistic estimate (p), and the most likely estimate (m).

2. The Beta distribution (or PERT) is a weighted average, with the most likely scenario given four times more weight than the optimistic and pessimistic estimates.

Generally, the PERT distribution results in a more accurate estimate than the triangle method.

The Wideband Delphi method is based on a peer assessment of the time required to complete a task. The technique involves conducting several rounds of task assessments made anonymously. Team members discuss results between rounds and can revise their estimates. Eventually, the team should reach the most accurate estimate.

IT project estimation techniques can be associated with a particular project management approach. Agile project management (APM) is based on the ability of the team to quickly adapt to changing development requirements. APM uses flexible approaches to project evaluation.

T-shirt sizing is a method that considers project task sizes as if they were T-shirt sizes, such as XS, S, M, L, and XL. Everyone knows approximately the difference between T-shirts in XS and XL sizes. Likewise, the developers are well versed in the task sizes without the need to measure each of them.

The T-shirt size technique implies that the development team does not estimate the time required to complete a task or predict a specific deadline but compares the size of one part to the size of another.

Planning poker (or Scrum poker) is an estimation technique used in the Scrum management methodology. Projects are estimated with the help of poker cards. This technique minimizes the anchoring effect: when participants' estimations are influenced by a judgment previously expressed by another team member (especially a reputable one).

Each technique has pros and cons, so you can use holistic project estimation methods to reach a high level of certainty and improve the reliability of the estimates. Thus, the PERT estimating method is often used with analogous estimating or with top-down technique.

You can mix methods for different stages of the project. For example, the poker planning method can be used at the beginning when there is still uncertainty and insufficient information, and the three-point estimation technology can be used later when all the necessary information has been collected.

Techniques Our Experts Use

The Integra Sources team uses holistic project estimation approaches when evaluating software development. When getting started on a project, we rely on estimates of similar past projects and consider the expert opinions of the developers. We also use a three-point technique to provide a detailed project duration and cost estimate.

If a project is complex or contains challenging tasks, we apply the bottom-up technique, breaking down the project into smaller tasks and estimating how much time and effort each task will take.

Sometimes, but not as often, our team uses scrum methods, like T-shirt sizing, Planning poker, etc., to understand how quickly we can move through development stages and how we can optimize processes.

Who Makes Software Project Budgeting?

The project manager is responsible for software project planning. The PM adds all the necessary additional activity hours to the project estimate. Different specialists may be responsible for estimating development hours, depending on the IT project estimation technique chosen. 

At Integra Sources, the project is evaluated by technical leads and developers. Furthermore, the CTO always validates the final project estimate before sending it to the customer.

Software Project Estimate Issues

First, the effort spent on estimation depends on the project itself. Large, complex, and unique projects make estimation more difficult and errors more likely to occur.

According to statistics, poor estimates during project planning are one of the most common causes of project failure.

What does underestimating a project lead to?

• The project goes far beyond the budget in terms of time and cost, which cannot but affect its results and further cooperation. Exceeding the budget rates leads to misunderstandings and disputes. The team and the customer spend even more time trying to figure out what went wrong. 

• Software product quality may suffer due to haste caused by deviations from the schedule. As a result, the customer either receives a solution with many shortcomings or has to wait longer until the developers fix the bugs caused by the rush.

The better safe than sorry principle is not always true when it comes to project evaluation. Yes, the final estimate includes additional time to resolve possible difficulties and unexpected situations since there are no ideal projects. However, an overestimated project can scare away the customer, whose natural desire is to have software developed faster and for less money.

An incorrect assessment has ruined more than one project, and, unfortunately, we have had such an experience, too.

Our development team conducted a rough estimate of electronics and embedded software development. There were some doubts about whether we correctly understood the customer’s wishes and would be able to implement the project. We advised the client to conduct pre-project preparation and write a thorough requirement document.

Having carefully studied the specification document, our developers increased the estimate by 1.5 times since the project turned out to be more complicated than we expected and the customer added new requirements. The new cost appeared too high for the customer, and he stopped the project.

The biggest lesson we have taken from that unsuccessful project many years ago, at the very beginning of our activities, is that we should evaluate projects as carefully as possible, clarifying in advance all the unclear moments with the customer.

Another thing that can scare customers away is when estimates change too much.

Why Might the Estimate Change?

Fluctuations in project estimates can occur for many reasons. Here are the most common ones:

• Software developers misunderstood the customer's wishes. 

Most often, this happens due to a poorly drafted requirements document or when there is no document and all the requirements are explained verbally.

High-quality pre-project work and a thorough specification can minimize the risks of incorrect project estimates.

• The task took longer than planned.

Some development stages may turn out to be more difficult than initially expected, or there may be many nuances, for example, when developing medical solutions. Programmers may spend more time when they do not have enough expertise in a specific programming language or software tools.

Such moments are difficult to avoid or predict, and a competent estimate of software development should include additional hours for challenging tasks and unforeseen circumstances.

• The customer wanted to make changes to the electronics functionality or add new software features.

Most often, it happens to software projects (e.g., app development) since the client’s wishes are not limited by the hardware architecture's capabilities.

Keep in mind that even seemingly small changes in software design or functionality can result in a large number of additional development hours.

Conclusion

It is not that easy to accurately estimate software development duration and cost. There are many things to consider, including time for force majeure, logistical delays, and finding solutions to challenging tasks.

Incorrect project evaluation can cause the loss of a project and a client. That is why precisely estimating the time and effort put into development is so vital.
Diverse development experience and mastery of various project evaluation methods will help the outsourcing team achieve accurate budgeting. Tell us your ideas, and we will estimate how long it will take to put them into practice and how much it will cost.