How to Estimate Software Development Project

Software development project estimation is the calculation of the cost and the time that its completion will take. This practice helps the client determine the feasibility of the whole process. It helps to prevent overruns and establishes the scope of the work. It ultimately aids clients with their decision of whether or not to commit with their idea.

Why Do We Need Project Estimation?

A McKinsey report states that 66% of all software development projects have overruns. There can be many factors for that but it is clear that it is a crucial part of the job. The obvious benefit of utilizing this practice is avoiding late deliveries and going over the budget. Using only past experiences may be counterproductive.

Estimation also helps project managers plan future products. It provides experience for empirical assessment later down the line. If you miscalculated an estimate once, the next will be more solid. In this way it provides the means for testing various models.

How to Estimate a Software Project

Project cost estimation has two established methods:

• Fixed price
• Time and materials

The former provides the whole estimate upfront and is geared to Waterfall-type development. The latter is more suitable for Agile methodologies. It gives the client separate forecasts for every step of development and is more flexible. While different in many respects, the core evaluation process consists of four main objectives:

• Evaluate the scope of work
• Determine its complexity
• Divide it into smaller manageable tasks
• Estimate each of them independently

But this is just the basic framework. The practice is customizable. There are many approaches you can borrow from including:

• Comparison to similar products from your portfolio. If you have already developed something with comparable functionality, take the past experiences into account.
• External expertise. You can always hire a team who will provide you with a detailed plan. Also, there is no shame in asking for help from your partners. If they have experience in a particular type of development, it will be helpful to learn about it.
• Planning poker is another popular approach. First, each developer estimates the project privately. After that, the team compares and discusses the results before making a collective decision.
• Bottom up & top down method entails the comparison of the independent evaluations of separate parts with one as a whole. If the difference between the two is drastic then you need to find the reason.

Why Perfect Estimation Is So Difficult?

The availability of different methods indicates that there is no one-size-fits-all solution. Making a perfect forecast that covers all of the possible issues is extremely challenging. Software development is a fluid process and the programmers often learn new technologies and make new discoveries while working. This often impacts the estimate.

Another common problem is the so-called Parkinson’s law. It states that “work expands so as to fill the time available for its completion”. This means that too much time can be just as counterproductive as not enough of it. People start stretching tasks out, which affects productivity.

That same can also be said about teams that have more people than they need. This creates too many communication links and information can get lost. Also, if the developers are working on several projects at the same time it can be taxing on their abilities. Allocate some extra hours, if that is the case.

Tips for Software Project Estimation

• Examine the statistics. According to the book Manage the Unmanageable, project team only spends 55% of the time actively coding. Talking with the PMs and colleagues, reviewing the code, and research take up the remaining 45%.

• Account for the risks. It’s crucial to add an additional 15-20% on top of your forecast. Unclear and more complex tasks deserve special attention.

• Remember that an estimate can be flexible. When adhering to Agile methodologies, it is important to evaluate every sprint. The clients are encouraged to suggest new features and expand upon their initial idea. When this happens always update your estimate.

• Part-time resources is a method that assumes that you have just 80% of your workforce at any point. This eliminates the problem of sick leaves since they are already accounted for.

• Consider the immersion time. Don’t forget to add an additional 8-16 hours for the team to familiarize themselves with the requirements and do some initial research.

• The individual work speed also matters. Often the people who make an estimation aren’t a part of the team who will develop the product. This results in misjudgments. The best course of action is basing the estimate on the average speed of your mid-level developer.

• If you provide two or more forecasts - for example, optimistic and pessimistic - the difference between them should be less than 20%.

• Always admit your discrepancies as soon as possible. The sooner you realize that you’ve made a mistake, the sooner you can adjust.

Estimation in Other Industries

While we have talked about how estimating works in software development, it is a widely used practice in other industries as well. Let’s take construction as an example.

Construction requires large amounts of planning so cost evaluation is crucial. This evaluation has two categories. The first one covers the construction process itself, equipment, labor, and materials. The second includes maintenance, utilities, land rent, and other recurring payments. It also has to be flexible. There are contingencies that have to be accounted for, such as environmental changes, labor cost fluctuations, and much more.

The industries may be different, but the core process is quite similar. Nobody wants overruns, and everybody actively tries to eliminate them through accurate planning.

Estimation Tools

There are a number of software solutions used for estimation. While they won’t do the entire work for you, they will make it easier:

• GitLab, Jira, and other Agile task management services can be used for this purpose. Time tracking functionality can record the man-hours spent on each task. This gives you a reference for the future. Here's a comparison of two most popular ones.
• Redmine with a cost estimation add-on provides easy calculations. It allows you to assign an hourly rate for each task and displays the final sum.
• EcoSys can track changes and correlate man-hours with cost. It provides a complete estimate in a comprehensive table.
• Google Sheets and MS Excel are also widely used. They have calculation features and are more familiar to users.

Conclusion

Software development project estimation is often laborious and time-consuming. If done poorly, it may result in a client’s disappointment. However, if it is done right, it becomes a framework for the evaluation of future products. Regardless of how you approach this practice, there are plenty of tips and tools that make it easier.

Comments

[Nick Holmes]

You say Project cost estimation has two established methods: Fixed price or Time and materials

These are not cost estimation methods, they are forms of commercial contract that can exist between a buyer and seller. The latter does not really require any cost estimation. For the former, the accuracy of your cost estimation will determine how long you stay in business.

In my opinion, there actually are only two established costing methods;

• Rigorous application of calibrated costing model,
• Everything else, for which the technical term is "Guessing".

Cost estimation (of any worthwhile accuracy) is only possible where an agreed and sufficiently detailed specification exists. This is common sense - if you don't know what you have to develop, you can't possibly say how much it will cost. Never-the-less, people attempt to estimate the unknown regularly. This is still guessing - albeit that you are guessing what the specs will be.

When you do know what you are supposed to be delivering, then you need to break this down into quantifiable activities for which you already have a known costing. If the project your are estimating is completely novel with respect to team experiences, then you will be reduced to - you guessed it - guessing.

So this means that accurate estimation is some how based on repeatability. Models for doing this have been around for literally decades (e.g. COCOMO). My own experiences had led me to an approach based around software architectures - a given software architecture being the set of patterns (used in a broad sense) that the solution will be composed from. If you're built applications before with the same architecture, and you bothered to keep metrics, you can estimate accurately. If your team is well experienced with an architecture, they will also execute more consistently too.

Now, this calls for a degree of technological conservatism - if you are chasing the latest and greatest stack with every new project, you'll struggle with getting any accuracy.

So if accurate cost estimation is important to you (and it probably should be), stick to what you know, and only change you approach in controlled steps.

[Artem Kobilinskiy]

Hi Andy,

The number is mostly based on personal experience and reports from other people. If the optimistic and pessimistic estimates are too different it paints too vague of a picture and they become less useful.